I've been slowly converting my house over from ST to HE, and I'm mostly done with everything that is compatible. Over the last few days, I've noticed that an automation will turn on a light, and the light does turn on, but the change isn't reflected in the console or dashboards. It also seems that some automations fail as a result of this because the lights appear in an 'off' state when they're actually on (or the other way around).
Is there something I can do to fix this? It doesn't seem specific to one device. In all but one case, I can hit the 'Refresh' button on the device page and the status is updated. I'm tempted to loop through every 10 minutes and 'refresh' every device with an automation, but that seems like something that should be built in.
I'd want to suspect the most recent firmware update on the hub is when the issue started, but I'm changing stuff multiple times a day as I transition from ST, so this could easily be something I did to break it.
You need to either use the polling app for normal zwave non plus switches , or replace them with zwave plus switches which i recommend as polling too many can bog the hub down.
st had polling built in.. for hubitat they have the polling app. but it is very inefficient.. lutron had the patent on status updates for zwave protocol switches and most companies refused to pay the royalties so they don't report status updates.
Depending how what you are using for your automations you may be able to either tell the automation to send the command regardless of the reported state, or add a device refresh before checking the state (and possibly after rule execution).
Ultimate solution is to replace your Z-Wave devices with Z-Wave+, but until then the polling app may be your best alternative if you configure it with some thought as to the load on your hub/mesh vs. the status latency.
This also appears to apply to zigbee devices. Both of you have me wondering: Can I repeat this issue on virtual devices? I'll work on testing that at some point.
This is something that I did, and then found that the 'refresh' on one bulb causes the entire z-wave radio to stop working (all z-wave devices go offline). It didn't happen consistently, but when it did, I had to shutdown + unplug power the hub to restore operation.
Oh, so I reinvented the wheel last night. I run a routine that loops through a list of devices (except for the bulb mentioned above) and hits the 'refresh' on all of them. I only run the routine every 10 minutes, and delay 20 seconds between each refresh.
So, if I only use the controller to control some z-wave switches, they'd still require a 'refresh' to update the status?
EDIT: just confirmed - all my z-wave devices are z-wave plus.
If you have all Z-Wave plus then you shouldn’t need the polling app. The statement about your mesh shutting down, however, leads me to believe that either your mesh needs additional repeaters, or that you have one or more ghost devices or devices that are spamming the mesh.
The zigbee network might be a little weak, but I don't think the zwave network should have any issues. I've got mostly zooz plug-in modules, and 2 Inovelli bulbs on z-wave. The mesh should be pretty solid, and I've got a small place anyway.
What would you suggest be done to find a device acting up? Just unplug one to see if the issue resolves itself?
I took my own advice and removed that bulb that I thought was causing the issues, and unscrewed it from the socket. So far, things seem better, but I'm also running my refresh automation on a loop. I'll go stop that now and see if stuff breaks.
As long as there is something in clusters you're fine. If possible it might be worth pairing those motion sensors without security. S0 is about 3 times the traffic and with them being motion sensors they could cause a lot.
It's configured at the time of pairing. If you don't get a popup option when you pair it then you'll need a secondary controller to pair it unsecurely using PC Controller v5 bundled in Simplicity Studio. You can pickup a UZB7 from mouser for about 19 bucks.
With the exception of a pair of zigbee bulbs not reporting their state, things are much better after pulling the inovelli bulb out. Hubitat support emailed me a few hours ago and said they pulled that bulb from compatibility list for the C7. I'd suspect a secondary controller might resolve this issue as well. It just doesn't seem like something that I should have to purchace for a brand new hub. I'll probably hold off for now, since it's gotten better.
They have to support S0 for certification reasons but I wouldn't want S0 on my mesh if I could help it and for 19 bucks its a small price to not have that crap on there.
Just a quick note - my guide is about using a UZB stick w/PC Controller to remove ghosts from the hub. It doesn't really talk about using the UZB stick w/PC Controller to join devices to Hubitat. The guide will give you some familiarity w/how the PC Controller works w/a UZB stick, but doesn't detail the steps to use it to join devices to your hub.
After you get the PC Controller software installed and the device recognized you pair it to your hub by starting a new zwave device pairing on the hub and then going to pc controller, clicking on learn mode and then nwi.
After the stick is joined as a secondary controller you can use nwi to add devices and they will join to the hub mesh.
Actually, on the zigbee side, it appears to be only a single device type (and it's using the generic driver). It's only the wemo bulbs that are having the issue. With the other issues I had, I assumed it was more widespread initially. The DH in ST shows 4 states for power (on, off, turningOn, turningOff). I wonder if the "Generic Zibee bulb" driver that I'm using in Hubitat doesn't understand the 'turningOff' state and just reports the bulb as the last known state, or if there is a different driver I could switch to that is close enough.
