Has anyone else got a Fibaro dimmer (211 model) connected to ST and working quickly/smoothly?
I’ve had this as a test device for quite some time. I’m now testing it out on ST and have tried the default device handler and a custom handler (with config options). Both are unreliable, sometime not responding at all to on/off commands and both have lag anywhere from 1-2 seconds to 15-20seconds.
Anyone else seems this and is the newer 212 model any better?
I’m sure that’s very frustrating! These are both very popular devices in the community, I haven’t heard anything in particular about lag being a problem. So it’s more likely to be something local.
You may have already checked all of this, but just to be sure… The first step is to make sure that the device has a good signal path to your hub. This can be affected by the distance to the closest repeater, the physical material surrounding the device, and/Or if your network address tables are up-to-date.
Distance matters. In a typical residential home, classic Z wave signal will travel about 40 feet (12 meters). So if the Fibaro is more than that distance from the hub, it will need to have its messages “repeated” by another mains-powered Z wave device. This is typically an in wall relay, a pocket socket, or a plug-in motion sensor. Battery powered devices do not repeat. Zwave repeats only for Z wave and zigbee repeats only for zigbee. The devices broadcast omnidirectionally, meaning 360°, so it’s fine if signal goes down to one floor to a repeating device and then up again to the hub.
Material matters. Some materials are easier to get signal through than others. This is exactly the same issue as for Wi-Fi. Common materials in a Home that might degrade signal include brick, concrete, plaster over metal mesh, water pipes, tinted glass, foil backed insulation, metallic wallpaper, large metal items from refrigerators to automobiles, etc. For an in wall device like the fibaro, if it is installed inside a Pattress box, plastic will let through much more signal than metal.
routing information. In order for message routing to take place efficiently, every device’s network neighbor tables must be up-to-date. These do not get automatically updated just because you add a new device.
Instead, every time you either add a new device to the network or physically move the location of the device, you need to run a “network repair” Utility to get each device to update its own neighbor tables.
The Utility itself may take only 15 or 20 minutes to run, but you may not see the full improvements until the next day. Just running this utility can significantly increase transmission speed.
Another issue that can slow down and network is excessive polling. Ideally polling messages should be no more than 5% of network traffic. Otherwise some execution request messages may be delayed or even lost because devices are busy answering polling questions. As it comes out of the box, SmartThings does pretty minimal polling. But if you have added custom code to do things like query battery status or other wellness checks you may have inadvertently introduced excess Polling. So it’s just something to be aware of.
the strength of the mesh
All three of these factors affect what is called the “mesh strength” of your network. That is, how quickly a message can move from the hub to a device and back again. These can vary a great deal from one house to another, so when you have issues with lag on an individual device, you typically just have to start doing your detective work and check each of the three: distance, materials, and routing information.
If you’ve already checked all of these and everything looks good and you are still seeing 10 second lag even with an official feature like routines or smart lighting, then I would definitely report it to support in case they can see something on their side.
Of Course it could always be a physically bad device. It can happen.
What code are you using to operate the dimmer when you see the lag?
I wonder if it is possibly related to something with SmartThings services? The last couple of days for whatever reason I am getting ridiculous slow response to IDE on simple things that typically take less than a couple seconds to load like My SmartApss is now taking about 30 seconds. I also noticed slow response times for my SmartAlarm app
That’s brilliant. Very good info thanks.
I’ll try all of this. The device is just on my coffee table at the moment for testing in the lounge next to a few other plug in devices. I do have a Fibaro HC2, Vera Plus, ST, Hue etc running. Would they all participate in the same network or do they run their own individual networks?
Basically, they all want to run their own network.
The Hue bridge is a special case. It is a zigbee controller for lights using the ZLL profile Which also has an open API allowing other controllers to talk to it and pass along commands to the bulbs that belong to the Hue bridge. So it is very happy working hand-in-hand with other controllers, hence the “bridge” name.
All of the others are Z wave or multiplatform controllers. A Z wave device like a sensor or a lightswitch can only have one primary controller. All the other devices that you listed would like to be that primary.
Under the official Z wave standard, it is possible for primary to add an additional controller as a “secondary” but exactly what happens then can get complicated. And comes down to what the individual manufacturer has supported.
For example, A Vera controller acting as the primary can add another vera controller as a secondary and everything will work pretty much the way people would expect it to – – both hubs can see all the devices, the statuses are kept in sync, you can write code that runs across both controllers, etc.
Smartthings, on the other hand, cannot be added as a secondary if another smart things hub is the primary. The cloud account gets confused.
It’s possible to add a SmartThings hub as a secondary zwave controller to a vera primary, or a vera hub as a secondary zwave controller to a SmartThings primary, but in either case, you get less functionality then you do with the vera – vera set up. The hubs might not see all the combined devices, or the statuses might get out of sync, or other issues.
So I can’t say you can’t do it, but I can’t say it will be an awful lot of work if you do. And SmartThings, in particular, really doesn’t expect you to do this and doesn’t support some controller commands like controller shift and controller replicate.
All of which is a long answer to just say that you probably won’t be happy with the results if you try to add a secondary Z wave controller to a SmartThings primary. For the other brands, you just have to check the details of what features are available.
Also, we should note that if you have all those z wave networks running at the same time in the same house you may get some interference. Just like if you have a house with three bedrooms and everybody is playing music at the same time. They aren’t directly interfering with what’s coming over your speakers, but because you can hear the noise at the same time it may obscure the sound in your room.
I’ve seen people successfully run two zwave networks in the same house without too much trouble, but I wouldn’t go to three unless you’ve really planned your layout very carefully. And keep your hubs as far apart as possible.
Good news - I moved the device closer to the ST hub and also ran the repair - communication is now instant and seems to be working OK. So I can now take it back to the original location and see if there are still issues - if there are, i guess it’s down to signal strength issues.
I’m moving to a new house in July, so need to carefully plan the positions of the hubs. Too used to having an 8Km Cat5e network and hard wired C-Bus lighting in my old house. The new joys of wireless HA!
On a related note, is there a method for doing a site survey with Z-Wave devices that doesn’t involve buying specialist kit?