Yes - probably best to get a new log to avoid confusion. I have a feeling the device was using the BASIC class for ON/OFF - this should work though I think, but let’s see the log.
If I understand this, you have a second switch that is associated to this switch. If you change the state of this switch, it changes the state ok, but OH doesn’t update? If so, I don’t think there’s any way around this - as far as I know, if you switch a device from another device, the switched device will not send out status changes to associated devices. I believe this is to avoid endless loops if you set up an association loop. Certainly I’ve seen this previously.
I think your only option here is to associate the first switch directly to OH and then use a rule to update the state.
Here you go. I turned the switch on, changed the dim level, turned it off, turned it back on, (might have changed the dim level a 2nd time), and turned it off. I also did the same thing with the Aux switch. Main switch is Node 3, Aux is Node 4.
I was pretty sure with the old binding that I was getting the changes showing up in OH when the Aux turned the main on/off but can’t be 100% sure and can’t go test. I can setup some postUpdate rules to take care of it so not a huge issue. Thanks.
I messed up the change to fix this - I’ll update the binding shortly.
Regarding the switch 4 - at the end of the log I see some messages from switch 4 - I guess this is where you are switching it to change switch 3 state? There are no switch 3 messages received during this time, so I think what I said earlier is correct.
When I wrote this binding, I wanted to simplify things and I removed the DEAD node code and I now only use the controllers view of the node. I figured that this would be more reliable as the controller is “continuously” (well, periodically) exchanging messages with devices at lower level that we see at binding level. I’m starting to think this isn’t as reliable though and may need to rethink this concept if the controller is going to make what I assume are working nodes as FAILED…
The weird thing is that any triggers to these sensors do come through even with the failed notice. What I’m not getting that I did get with the old binding is the battery updated (though with the old one it took a while before that reflected). Should I try changing anything with polling intervals?
One small bug. Everything works perfect from the main switch, but with the Aux switch if I turn on, change dim level, and then turn off. OH is picking up the change in dim levels but not the on / off. Attached is a debug log following that sequence (Node 4). https://drive.google.com/open?id=0B77VHtwPft8eUEZlNWcyN3JDb3c
On a side note, with the uninstall/reinstall of the updated binding one of my two sensors appears to be staying on line now…
No rush at all. Thanks again for all the hard work!!
I did shorten the wake time interval to 10 minutes, but it didn’t look like that updated yet before it started staying online. I did remove / install the new zwave binding while keeping the system up which also corresponded to the change. I’ll experiment if it goes back in failed mode to see if I can figure out what made the difference.
I have noticed that failed is mostly a temporary state. If the device wakes up, or communicates in any way, it is no longer marked as failed. The ZCOMBO has a mind of its own, only communicating when it feels like. It gets marked as failed often, and then when it wakes up or heart-beats, it gets marked healthy again.
This has also been my experience when I developed this approach, but if I understand correctly the device did wake up a number of times and it stayed failed (right?). It’s worth confirming this - I dont think the log I looked at had any device messages so can’t confirm it in this case.
It would broadcast a door status change but stayed failed. Not sure if it did a regularly scheduled wake up (I had it originally set for every hour). I updated to the latest snapshot last night and 1 of the 2 sensors went into failed status. I just kicked it into the 10 minute wake mode and it reconnected and seems solid this morning.
Ok, so it seems the approach is ok then? Even with the old system, it would not initialise until the device wakes up so it’s the same here. It will still receive messages in the event of a notification, so this all looks ok I think?
The old version seemed able to wake it up sooner or just didn’t report the failed attempts to the log file every 30 seconds. But at least I have a way to force it to get back on line so I’m good. Thanks.
).
