I've tried everything I can possibly think of an I still can't get my light switches to send when they are physically turned on. I've even added a motion to attempt to refresh the devices, but they still don't consistently report physical on. Does anyone have suggestions?
What switches are these?
4 - GE zwave Dimmer (I don't remember the model)
2 - Leviton Decora smart Dimers
I have a few Leviton DZ15S-1BZ switches and while they sometimes show as inactive, they are always online. And the always show physical vs digital events just fine.
What version do you have?
Some older models of GE Z-Wave switches simply don't report physical events. For those, you have to poll (and you could certainly poll the Leviton ones, too).
DZ6HD
Maybe you should start your own thread on this. It's kind of a specific issue not related to mine.
Sorry, it was based on the fact that this post was on physical events not being reported and kind of dives deeper into this issue as not being just switches but other devices as well.
A standard way to poll switches on Hubitat is to setup a Rule Machine rule that runs periodically and calls the refresh command on the switches of interest. The rule can fire pretty quickly, depending on the number of switches; maybe every 10 seconds. That means you'll have up to a 10 second lag (or however frequently you poll) between when a switch changes state and Hubitat notices, but it's sufficient for many use cases.
Tried refresh, but the problem is the switches never show physical push within hubitat even with refresh.
So if a switch shows in Hubitat as 'off' and you physically turn it 'on' and hit refresh in Hubitat, it's state doesn't change to 'on'?
No it does not
Hmmm...that seems like a more significant issue. What driver are you using for the GE switch? Assuming it's Generic Z-Wave Dimmer, have you run the configure command?
Yes that is what I am using. I did push the configuration button. It didn’t appear to do anything.
Agree. More significant. The "problem" polling (refresh) is intended to mitigate is where the switch/dimmer/bulb/device knows IT'S own state, just doesn't tell anyone. Thus sending a refresh command to a specific individual device is expected to return the true and correct state of the device.
Either the command isn't making it to the device, the device is ignoring it, the device is lying, the response is getting lost, or finally, the hub misinterprets the reply.
Given the Refresh command is (in a ZWave network sense) identical to an On or Off command, and those work, if I read this right, then that eliminates 1 and 3. Live Logs should indicate similar to this (from when I clicked Refresh in the UI for this device):
Closet Light is off [digital]
That is indeed the correct and true state of the switch... off. For me, since I can't duplicate, I can't give examples of "wrong" results.
I'd suggest a test by focusing on only one of your 6 "reluctant" devices and:
open a live log tab and then:
Verify both the debug options are ON
Click Config
Click Refresh
Click On (or Off)
Go physically toggle the switch to the other state.
Click Refresh
Back on the live log page, click the name of the device we're testing and paste all that log here.
I also have to configure several devices with RM to have a refresh. Personally, I think there should be something simpler and integrate. I read that in Smartthings he got around the problem by constantly polling devices. I believe that a solution other than RM should be considered if we want the platform to become more accessible for NOOBS.
@tjeannot44 I have a contrary opinion 
Bruce said elsewhere that ST solved this by "throwing a bus at it" and I believe that is the wrong answer too. We're burdened by the decisions Manufacturers made in the development of their products. It's GE/Jasco's fault their devices don't provide status. They chose to not pay the royalty when the patent was alive and did not offer OTA updates for US to deploy using the new methods (as outlined by @JDRoberts in his post.) I'm going to guess that they didn't even build in an OTA 'feature.'
Therefore, it falls to each of us to identify the devices that a) don't supply status and b) we wish they did. Putting that small number into a RM triggered rule seems exceptionally easy. For me, I have two. For me, I poll (refresh) 3 times an hour (every 20 mins).
Ok, so what can we do to simplify this for the NOOBs? One of us can create an App that does that and only that. It's a very narrow App, but the result would be rather similar because the burden is detecting and identifying the devices that are silent. The human part, be it RM or dedicated App is the same.. identifying the devices. I guess a dedicated app could benefit by having the "throw the bus" option (select all devices.) Of course that just shifts the NOOB complaint to "why is this so slow?" 
1 Like
My devices z-wave Linear, my switch Cooper 5 button. Switch indicators. And I did not finish my migration. It seems that I have chosen the devices not supported. I have 25 devices that require refreshments. Many of them will need a very frequent refresh to make it functional. Do you have an idea of the maximum capacity of hubitat. Number of refreshments maximum before feeling a slowdown of Hubitat. Me too I find RM very easy. I suggested this to help users less familiar with all this manipulation.
Digital vs physical information may be lost if the message goes through a repeater, and that depends on the specific model of the repeater.
Also, second try attempts when the first attempt fails are reported by many models as digital rather than physical.
Since both of these are unpredictable, they can be responsible for either variable results or one person getting different results than another even with the same device model.
That is, if the message just happens to go directly to the hub, it will be reported his physical. But if it has to bounce around the network a little bit first, it may then be reported as digital.
And, by the way, the more polling and/or refreshing as you do, the more likely it is that the message will fail on its first attempt. Just Sayin'...
So the first thing is to make sure that the device driver that you are using knows what to do with both physical and digital reports, because you might get either one.
The second thing to do would be to run a Z wave repair just to make sure that you have enough routes available.
The third thing to do if you want to do serious trouble shooting is to move the problematic Device to the same room as the hub, run A zwave repair, wait until the next day, and then see if the status synch problem goes away for that device. If it does, then you know it likely has to do with how the physical message report is being affected by the route that it takes.
Just a thought, everybody troubleshoots a little differently. 
(BTW, I have seen a couple of smartthings device type handlers written by people who didn't understand Zwave protocol who implemented anti-bounce protocols which were throwing away messages being caused by a second attempt at a failed transmission. That's pretty technical, but I just mention it as it's another thing to look for in the driver.)
1 Like
