In theory, no, this is not normal for ZigBee devices. They are meant to respond every 7.6 seconds, and their parent is meant to buffer this data for this time, so no messages should get lost. This is quite different to how other protocols (eg ZWave) may work.
Ok, I’ll have a better look at this as we are getting these announce messages and this should bring it online (but the framework may not do this at the moment).
I’ve had a look at this, and confirmed that the latest NCP code is reporting EZSP V7 as per your log. I can’t find anything documenting this in the Silabs docs, but as best as I can tell there are no changes. I’ll check with Silabs if anything has changed.
I have created a PR for this, but it will take a little while before it migrates through to the binding. In the meantime I’d suggest to use NCP 6.3.4 for now.
No, I believe that reply was to Shree_kant up here, who has some issues getting the dongle to work.
I know the TRÅDFRI dimmer works with ZigBee2MQTT (https://github.com/Koenkk/zigbee2mqtt). I tried that, but it seems like it somehow messed up my entire ZigBee network, and I am definitely not ready to move everything over to a system that so far seems less mature, and needs everything configured using a more manual approach, and so on. My original plan (since I bought two cc2531 as I started with ZigBee) was to just use ZigBee2MQTT until the dimmer was implemented into Chris’ work.
Hi,
I have included the aqara human body sensor but the Occupancy channel is always ON. I have the aqara sensor inside a box for testing so it should be OFF. Do you know if that is a common problem Chris?
It´s probably the same problem as with the Trust motion sensor. It´s trigger never goes off. @chris mentioned this is somekind of build-in “feature” and can be “activated” in the binding. But I think he has been too busy to look into it.
Not exactly. ZigBee devices have a flag that says if they will only report the ON state, and not the OFF state. I could use this in the binding to start a timer to reset the state to OFF after (say) 30 seconds (user configurable) but this does function not currently exist. For now, you would need to do the same thing, but using a rule to reset the state.
@Kergilo
I found an much easier solution to this, by the use of the expire binding.
All I had to do.
Install the expire binding.
Add this to my item defintion for presentdetection: (note the very last of the line)
Switch TrustMotionPresence "Trust PIR Motion Presence [%s]" <cum_motion> (gMotion) {channel="zigbee:device:4beca465:00158d00019533d3:00158D00019533D3_1_motion",expire="20s,state=OFF"}
This is set for 20 seconds, and the switch is turning to OFF.
I´d try with 10 seconds, but I couldn´t re-trigger the motion sensor after 10 seconds. It took some more seconds. So I believe as far as my Trust sensor goes, there might be a minimum of 15-20 seconds or something like that.
But this is a very easy solution, in my opinion. I have never worked with the expire binding before. I bet, this isn´t the last time
Help! yesterday without any interaction to my system I’ve lost control of my ember controller. I’ve attached a copy of the logs error output I receive. I’m running ubuntu 18.04 LTS / Zulu-8 java. Any Idea what is causing this or what I can do to help track this down? I’ve turned the zigbee binding logging up to debug and it doesn’t show anything out of the norm. This random ash frame issue is all i see.
Seems after fighting for a while - I cleared the cache and restarted and this issue is gone - for now. Let me know if there are any suggestions for troubleshooting should it occur again - I’m running the most recent testing release by the way.
@chris
I think the above from @jfrank1845 starts to look like a pattern for the ember coordinator. I believe I have seen others mention the same also using a ember coordinator. And this has been one of my problems as well.
Hopefully the sniffer will caught this rather frustrating issue.
I’m not so sure. There is no real information on which to draw any sort of conclusion in my mind. There is very little in the log posted above - if anything, this looks like something different than I’ve seen before.
I know it’s very easy to conclude that there’s a particular issue because a number of people have the same observable symptoms, but when the symptom is so broad, I would really suggest to be cautious with such conclusion as there is very likely to be different things happening.
I don’t think a sniffer would help for the log I see from @jfrank1845.
@jfrank1845 if possible can you enable debug logging please so it’s possible to find out what happened if it happens again.