mine has been in one place all along.
Someone as ST point to me the DH may need capability "Sensor" so it show up in app like ActionTiles and WebCore. I just update the DH in github with this suggestion. I do not know if we need one here. I just add it in case that this capability help for the sensor to work with as many app as possible.
Another update to DTH to support pressureMesaurement capability.
2 Likes
Thanks for the updated driver. Working great here.
I saw your mention of sensing vibration. I just saw an article about this earlier this week - I don't know if there is anything here that would help you with your project . . . https://raspberryshake.org/
Eric
So I am also testing one of @iharyadi's devices, with the main purpose of looking at routing compatibility with Xiaomi devices.
After pairing it the first time, I realized that it would probably be difficult to "steal" rejoining devices from previously being routed through one of my XBees.
So today, I unplugged my XBees, and then paired @iharyadi's device. Not want to wait for the mesh to "heal", I went ahead and rejoined devices that were previously routing through an XBee.
So far, I've got some Xiaomi "original" and Aqara door/window sensors, a few Aqara Temp/Humidty sensors, and an Aqara Leak sensor rejoined through @iharyadi's device. We'll see how it goes in the "long" term with those.
However, I am having a really hard time getting any of my Sengled Classic (E11-G13) bulbs to pair properly. I'm seeing a Java error in the logs for all those Sengled bulbs that I've never seen before: Queue full, and I've started a forum thread specifically about that error.
The strange thing is with an extra XBee (not previously used) in XCTU, I can see that those bulbs are showing up in the mesh network map as being routed through @iharyadi's device:
I am also noticing low RSSI values despite some of the child devices being in the same room as @iharyadi's sensor (does it have a name that I can refer to it by?)
I put the cart in front of the horse a bit by not installing the custom device driver for the multi-sensor, so I installed and assigned that, and now I'm seeing that Queue full error when I try a manual configure or refresh for @iharyadi's device. Also it doesn't seem to be reporting and the Current States in the device details page hasn't populated with any information yet.
I don't want to reset it or remove it from the Hubitat network yet, so I'm going to reboot my hub and report back if there's any change.
EDIT: A reboot seems to have cleared away the Queue full errors:
I'm seeing quite a few read attr - raw: log entries for the device, mostly on cluster 0B05.
The RSSI information is the last value read in a packet received from a device. If the last packet comes from a distance device, the RSSI value can be low. If you can refresh at right moment to catch your closest device send packet through the router, you can get a high RSSI value. I would not try to do this though. It is hard to do so.
0B05 is a diagnostic cluster. When you refresh the device, it will read the attributes in the cluster. BTW, one of the attribute is RSSI.
It look like some kind of queue is full literally. However, the fact it is logging the error, some kind of activity from the device is happening. I would suspect that the hub and devices has some activity. Therefore, it maybe possible that the zigbee communication is fine. The issue could be at dth level. I hate to speculate further.
BTW, I really appreciate your help in testing the xiaomi. How long typically a xiaomi device would drop connecting through an incompatible router? Is it a matter of hours or days? In theory, based on my understanding of the aging device issue, devices should dropped out of network in a matter of a few hours. Is this correct? A device can drop out of zigbee network for other reason. I want to make sure that we can have good guess for the reason why it drop by looking at the interval.
Hi Eric,
Thanks for the info. I will take a look at what sensor do they use. Let me see if I can learn what kind of data from the sensor that we can use.
Thanks
Iman
@veeceeoh, I for got to mention in xtcu, they also display LQI. Currently, the stack calculates LQI based on RSSI. The calculation is linear map between -90 db to -10 db to a number between 0 to 255. This calculation is not as generous as other routers. These are pretty low power devices. It is unlikely that all devices in a house will read the same RSSI (hence, the similar LQI value).
On the other hand, for example, the coordinator (any many other router) does give generous LQI value regardless the distance of connected devices. I do not have any knowledge about those implementation. It may take into account the quantity of the signal by looking at the preamble signal quality over RSSI to calculate the final LQI.
I do not want to mess around at this point about the LQI calculation. I also have to admit that I may not have enough knowledge to argue with either implementation. I would like to take it safe to use the default stack implementation. The receiving sensitivity of the module is roughly about 90db anyway. It should be able to perform well with signal above that.
But is that all devices in the mesh network, or only the ones connected to that particular router? In my case, I'm testing with your sensor and my Hubitat hub and the XBee (to map) all in the same room. The furthest end device connected through your sensor/router is just 8-10 ft away.
As long as the device driver is actually doing something with those read attr messages, then great! I haven't had a chance to sit down and read through your driver code yet.
Based on everything that happened, I believe this error was at a lower level than any device drivers. It may have been related to my powering down the XBees, which orphaned some end devices. I'll wait to see if someone with Hubitat replies with an explanation on what the error means, though.
If a router's end device timeout is shorter than a Xiaomi's 50 or 60 minute check-in interval, then the device will generally be dropped within 1-3 hours, but you won't see any more check-ins (indicated by the battery report update) beyond the first one, if there is any at all. Waiting 12 hours is safe enough to decide whether a Xiaomi device has been dropped due to the end device aging timeout.
All of my Xioami devices routing through your sensor have definitely made it past that point, so now I will leave them connected for a week to see if any drop for other reasons (which may be very difficult to identify without a sniffer). I will also continue to try to rejoin a few other types of Xiaomi devices to route through your sensor to see how they do in staying connected, of course.
The RSSI value is only devices which packet arrived at sensor module. From radio HW, a packet contain RSSI field. Therefore, this report will never show RSSI devices that it never heard from. End devices which never route its packet to the module will never have the RSSI value reported. This is not a scan of your network. It is just simply the RSSI value of the last received packet.
Yes, the driver will display it on ST tile. In hubitat, it will store it in attribute fields.
Thanks for this information. This confirm my understanding of the issue with Xiaomi. My experience with playing around with ST and Hubitat, in very rare occasion, devices do drop from Zigbee network. I want to differentiate this kind of occasion with aging xiaomi issue.
1 Like
played with your environment sensor for a couple of weeks now. Super impressed you built your own sensor.
The first week I just pair your device and routed a few Xiaomi devices through it and then didn't touch them. Everything appeared fine for that week.
But then I found that if you unplugged it and then plug it back in it would drop off the network after approx 15 minutes. I tried many different ways as well as with the hub in pairing mode and holding the reset button while plugging in the environment sensor and holding for an extra 5 seconds or just straight plugging it in without using the reset button.
the environment sensor even after it dropped off the hub if I unplugged it again and replugged it back into power it would appear on the hub scan again and report sensor readings again for a short period but then fall off again.
The only way to get the environment sensor to work again was to remove it from the hub and then put the hub back into pairing mode and while holding the reset button plug the environment sensor back into power and keep holding the reset button for 2-5 seconds. Then it would pair again every time.
The down down side is once it is paired and working properly if there was a power outage then it would fall off the network. So it should be plugged into a battery back up like a UPS or even just a portable usb battery pack and then have the usb battery pack plugged into the house power.
I noticed a similar issue with my Sylvania Smart Plug 72922 where it would not work correctly after leaving it unplugged (powered off) for more than a few minutes. Thus I leave plugged into my UPS battery backup.
The second issue is when the environment sensor was paired and working correctly and I placed the hub into pairing mode then tried to wake up a Xiaomi Aqara water sensor (by holding the water sensor button until it flashes 3 times and then release and wait for a multi flash on the water sensor) it would almost immediately kick your environment sensor off the network. I would have to go through the whole removing the environment sensor and re-adding it again procedure to make the environment sensor work again.
The environment sensor would never get kicked off when I did this with a Xiaomi Aqara door or Aqara motion sensor only the Aqara water sensor and I tried this and got the same results with different Aqara water sensors at opposite ends of the house.
(was just saying water sensor paired through you device fine but now I see it is not getting scanned with my xbee)
Very strange.
The only other recommendation is maybe adding a power or transmit led so you know it is alive and working.
I am sorry that I have not mentioned about the the function of the button. It only have one function. That is to reset the module. Once you do that during the start up, all configuration on the device is cleared( factory reset). It will never connect anymore until you remove the device on your hubitat. The button does not work like Xioami's where they may have multiple functions.
Now that is out of the way, I have tried to shutdown my modules and reconnect after 15 minutes in the past. I do not remember whether I did that with ST or Hubitat. I will pay more attention now with Hubitat and see if I can reproduce the issue. I will compare also with ST behavior. I will let you know what I find.
I will note this behavior. I had issue in the past with Bosch devices. In this case, I found the Bosch went rouge. Every zigbee device is assigned a 16bit network id. The bosch at one point keep taking over the 16 bit network id of my module. Yes. It literally send packet using the network id of the module. The module zigbee network layer detect this condition perform conflict resolution. It does leave the network and rejoin the mesh. I found while connecting to ST. ST allow the module to come back without manually do the join process. I found this problem by looking at 16 bit network id. The module network id keep changing every couple hours in ST ide. To troubleshoot this issue, I have to use Zigbee sniffer. I rebooted the Bosch. The issue went away. I can never reproduce the issue.
I mentioned my finding above because that is the only instance I can recall the module get kicked out of the mesh. In ST, it was able to re-joined and assigned a new id. If I do have the time, I will try to get the water sensor. However, if my suspicion is correct , there is nothing the module can do. If a device in a network steal its network ID, it will leave the network. This bring to a point related to your first issue. It seems like the module is not allowed back.
Thanks for this suggestion. Let me think about it. I do get opposing suggestion. Some people do not like blinking led. Keepin the sensor anonymous is also an advantage for some people. They just want the sensor to be tucked in some corner and not calling for attention. I do hope to have some kind of device health feature. This will get the job done and more discrete.
I got chance to try the shutdown scenario. I shutdown the module 20 minutes. I am not sure whether how long it is down make a difference.
There is no issue for the module to come back to the mesh. In the log, you will see the gap where I shutdown the device. The DNI (the 16 bit network id) stay the the same, D582. I do not have to re-pair the devices. It just come back straight in and start reporting 405 attribute which may be a humidity.
2018-07-10 17:48:17.779:debugdescription is read attr - raw: D5820804050A0000216310, dni: D582, endpoint: 08, cluster: 0405, size: 0A, attrId: 0000, encoding: 21, value: 1063
2018-07-10 17:27:20.973:debugdescription is read attr - raw: D5820804000A0000210422, dni: D582, endpoint: 08, cluster: 0400, size: 0A, attrId: 0000, encoding: 21, value: 2204
@NoWon, I am guessing. there may be issue somewhere else. If this module had communication to the hub through another router, the said router may prevent my module to rejoin. In zigbee, there is a concept for rejoining a mesh. Perhaps, somehow in your network, the module is unable to get back in using the rejoin request. Again, this is not an issue with my hubitat network here. Let me know if you find anything new. I would be interested to get some information and feedback about this issue. BTW, I really appreciate your help.
Thanks
Iman
Regarding power issue it was working fine for a week I didn't do any testing with it I just xbee scanned it every few days then I just unplugged the environment sensor for 1 minute I could see it missing xbee scans as expected and then plugged it back in (not using reset button). The xbee scans returned and I could see the sensor readings return in the hub log. But then after about 15 minutes it would drop off.
I repeated this test many times with the same results.
Regarding the Xiaomi I left the environment sensor paired and working fine for 24 hours then I paired the Aqara water sensor through it and within 15 minutes the environment sensor would fall off or if the water sensor was already paired to another router and I just did a wake on the sensor the environment sensor would fall off right away.
I was able to knock the environment sensor off with the Aqara door sensor once but not consistently I ran out of time Today I will focus on the Aqara door and motion sensor tomorrow.
I am glad you brought this up. I did double check at my home. I still have the log. It is still connected in my case.
2018-07-10 18:59:00.650:debugdescription is read attr - raw: D5820804050A0000213F0E, dni: D582, endpoint: 08, cluster: 0405, size: 0A, attrId: 0000, encoding: 21, value: 0E3F
This has been ~71 minutes since it come back from the intentional shutdown. The system is still chugging along.
The 15 minutes drop after re-connection (rejoin) mean that there is no issue rejoining. It could just drop out of the network. Could an interference be in play at the new spot?
If this happen again, can you check the dni: D582? If the id change every time you restarted, it could be an issue with conflicting id.
I will check tomorrow when I get home definitely could be a conflict.
As far as re-powering the device issue I have a lot of high powered xbee and other devices that could cause interference but you would think they would cause problems even on initial pairing or even after initial pairing during normal operation why only on rejoining?
I will look closer at my Xbee scans maybe it is rejoining through another router and that router is dropping it.
Thank you. Let me know what you find.
In my own setting, since I shutdown one of my sensor, I want to report that the module is still chugging along.
2018-07-11 07:46:18.084:debugdescription is read attr - raw: D5820804030A000021EE03, dni: D582, endpoint: 08, cluster: 0403, size: 0A, attrId: 0000, encoding: 21, value: 03EE.
Here is what I am going to do on my end.
I will unplug module for a few hours now. I will see when I plug it back in that I can reproduce the issue.
I will also try to unplug the module for exactly 1 minute later today. I want to see if I can see the same issue. However, I have done this short term unplug and plug back in plenty of time. I may not do it in exactly one minute. I am sure that I never seen the behavior your saw. I just want to make sure that I did exactly the step that you did. There are a few other user that unplug the module and move them around the house. I believe they do not need to re-join the module. You can tell from the ResetCount attribute. This tell you how many time the module has been rebooted.
BTW, as a background for anyone who are interested. The CC2530 does have non-volatile storage that will survive reboot. In this storage, some configuration, binding info and current network information are stored. The module can be rebooted. I understood that some smaller MCU may not have nonvolatile storage in their implementation. This is not the case with CC2530.
1 Like
ok I have found the problem with rejoining it is my GE Zigbee Wall Switch 45856GE which also happens to not work with xiaomi sensors.
Looks like the environment sensor always want to rejoin to it and it then drops it from the network.
I hoped it was also related to the xiaomi Aqara water sensor but even with the circuit breaker pulled from the wall switch and waking the water sensor it still knocked the environment sensor off but atleast with the wall switch unpowered I could just pull power from the environment sensor and plug it back in and it would start up again and stay on the network. I would not have to go through the whole removing and re-pairing the environment sensor as long as there was no power to the GE wall switch.
But the GE wall switch when powered back up would also knock the environment sensor off the network.
