-
Notifications
You must be signed in to change notification settings - Fork 501
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Not able to detect when a device is powered on #2047
Comments
That’s incorrect. A condition with a
Only when
Note that |
Is there any way to use the
I know that reachable takes a very long while to turn false, but if I could detect when the device connects that would be enough. Are you saying that I can't do that at all, or that initial connection doesn't differ from continuous connection? I would like to have a setup where I don't power down the lights, but that's currently not an alternative. Are there negative side effects I'm missing, apart from reducing the network range? To go back to the other question, is there no way to send a default state as OP is trying to do in #170? |
The perfect attribute would be |
There's no such thing as connections in ZigBee. It's just messages. The device sends a Device Announcement message when it joins the network, after a power up, or after actually joining (as in obtaining the network key). deCONZ marks
Some end devices (sensors, wireless switches) don't react well to their parent router going MIA. Xiaomi end devices won't look for a new parent, and become unreachable. Others could actually leave the network, requiring a reset and repair (of the end device).
I tried in the distant past (before the Hue lights supported power-on settings) bluntly to send the desired state every second or so. I more or less managed to do so (on the Hue bridge), but the issue is changing the desired state. Updating scenes from rules didn't work as expected/desired, so it boils down to some pre-defined desired states with associated static scenes. I did a writeup of this on the Hue developers forum, https://developers.meethue.com/forum/t/is-there-a-way-to-change-the-startup-color/4009/127?u=ebaauw.
I think for API 2.0 we should handle reachable on device level (not on the current level of resource, related to endpoint and cluster). We could expose an attribute related to the last message received ( Better ditch |
Thank you for clearing this up for me. I really think the changes you talk about for API 2.0 sounds great. I'll leave the status of this issue to you, in case you want to use it to track the API changes. |
I would also like a function like this one. But it seem I m the only one ^^ > #1436 When a device join the network, it send some "state" to update the home application but if it come after an accidental power off, it need to take the value from the application not the reverse. On older version, like @Ofenhed I used the "rechable" field to detect when a bulb join the network after a power off and set it with good setting, but not possible ATM. I know its not possible using this field now, but not sure It's something impossible with zigbee. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
In #170 it's stated that using reachable dx will still trigger when reachable goes from true to true. This seems to no longer be the case.
I'm trying to use a lamp as a switch for other lamps using a flag. I have the following rules:
They only seem to trigger when the lamp has been turned off long enough for reachable to turn false. Is this a bug, new intended behavior, or am I missing something? The update shows up in the WebSocket.
The text was updated successfully, but these errors were encountered: