I have notice a recent problem where if one of my RGB strips drops from the zigbee network and is recovered then my webcore pistons will no longer address the light. This happens even if hubitat hub is able to address it fully.
The only way I have been able to resolve this is if I edit the piston with the device, edit the statement controlling the device and then save and save piston. After which webcore will be able to address the RGB device/light.
Is there someone who could look into this problem or have others experienced it? Zigbee is suppose to be robust and just because a device dropped off network and recovered webcore should not have to be edited or readdress its subscribed devices manually due to a zigbee network resync.
Thanks...
Does the device ID (not the DNI) change for the device when it gets re-added, the one you see at the end of the URL when viewing the device detail page? That's the only thing I can think of that would cause this, and it would affect every app, not just webCoRE.
I assume you are not removing and re-adding the device (just "re-adding" if you even need to do anything). That would definitely cause this but also isn't necessary for Zigbee.
Hard to tell on the fly b/c once its back online, it is completely controllable from the hubitat device page. I do not think there is a logging for the DNI.
No I do not have to remove or add the device. A simple power cycle does the trick, if needed, most of the time it just rejoins the network. Also to note this is not a new occurrence. The particular RGB light strips are flaky, but when they drop off the rejoin within minutes. However, only in the last week has it become a problem with webcore not ever seeing them again until edited in the piston.
I do understand that if the DNI were altered it would not be addressable, however, would not webcore place in the piston a temp/random device DNI as it would if that device were deleted?
Thanks for reply
Specifications for device:
- endpointId: 0B
- application: 01
- manufacturer: GLEDOPTO
- model: GL-MC-001
- softwareBuild: 3.0.0
The DNI is the piece I was not asking about. Logs can tell you the device ID (or past logs in your case), but checking the URL of the device detail page before and after is pretty easy too. This ID is the piece of interest.
It doesn't sound like anything you're doing should be causing this, but it would at least solve half the mystery if it were...
Another possibility: could the Current States of the device be wrong after this happens, and coupled with the command optimization setting in webcore (if enabled) make krnspoesr like nothing works? Enabling more logging in the piston and checking that output might also help shed light on this.
