The Osram and Hue Dimmer switch typically don't "do" anything until you actually press a button (at least in terms of the ZigBee logs on HE) ...... I've previously had the logs open on screen for many days at a time and never seen any packets from those devices until you push a button. Of course that's not to say that they aren't transmitting something that isn't appearing in the HE ZigBee logs.
I have a ConBee USB knocking around somewhere, I'll see if I can set it up as a sniffer.
I am really interested on learning what knock the sensor out of the network which It seems like doing. On one of your log, It look like it keep configuring the sensor.
Do you see any other error on other logs during pairing?
Every zigbee router/coordinator has limit in term of number of child or neighbor that it can communicate. Based on the number of your devices in the network with one coordinator and two router, it could be that it has gotten in weird state of being rejected due to availability issue on the routers/coordinator on the mesh. This is even more unlikely issue. However, I want to mention it here so that we can have some idea if we need to explore.
As a summary, it seems that the sensor is paired. Model number and manufacture id is captured by the hub. It sees 2 neighbors. The third neighbor is its parent. It is not included in the count. That meant that the sensor at one point in time is in the Mesh. The hub has enough time to query these basic information. I think in short amount of time it is dropped out of Mesh. I am really curious what possibly cause it to drop.
I don't see any other errors in the logs unfortunately 
Do you happen to know what the limits are on the XBEE for children?
Although it seems strange that a subsequent pairing of another Aqara device occurs without issue? In fact I just paired another Aqara device without issue, this time this one jumped on the XBEE.
Will see if I can order a ZigBee sniffer .... I could have sworn I had a ConBee somewhere but all I can dig out is a Digi XSTICK which I don't think will work as a sniffer. I also have a RaspBee, which I think is the same hardware as a ConBee and can be used as a sniffer, but no spare Raspberry Pi to put it on.
Is there any debug output from the device itself if I plug it into a PC? Or is the USB only for power?
The USB is for power only. these MCU are typically very limited in resources. A debug text is expensive and cost flash spaces. We are also limited in the serial port available.
I am sorry I do not know. They are not huge number. One responsibility of being a router, it must at least be able to temporary store packet for its children while it sleep. This cost RAM space. I doubt that XBee has a lot of them. This is why Zigbee radio has limited support for client and neighbor count.
One idea that I think probably we should try is to have the sensor connect directly to the hub. Unfortunately, to ensure this is to shutdown your Xbee. I understand that this is probably troublesome for you. I did tried each of your module at least with direct hub connection. The module also did connect fine with your ST. I am just wondering if we can force the module to connect directly to the hub. We may just get over the hump.
If I have to rank my suspicion, they will be on the following order.
In term of probability of causing issue, 3 to 5 is very very small. I have test the sensor with my hubitat hub a lot of time, They are working with devices in 4. End devices typically does not involve in packet delivery. They received and send packet only. They do not route packet from other devices.
Based on the issue and what we have tested, #2 seems to the likely hood of where the incompatibility happen. Again, I do not want to force you to try to shutdown your Xbee. I leave it to your judgement if you want to try this.
I'll see what I can do with the XBEE, I just have visions of pulling the plug on it and then having a whole host of issues afterwards trying to get everything to reconnect. Although if I do it quickly enough the end devices probably won't notice.
I should also mention that I do have an identical XBEE on the SmartThings hub, for routing and mapping. I didn't check earlier where the sensor had ended up after I paired it to SmartThings, I'll add a sensor back there tomorrow and check to see where it ends up. It's possible that the sensor jumped on a socket or an Osram as opposed to the XBEE.
For clarity the SmartThings hub has 14 SmartThings socket outlets on it, 2 sets of Osram RGB mini spots and 5 sets of Osram RGBW pole lights. I'm not planning on bringing any of that over to HE as I'm happy with it there (plus I seem to recall that the Aqara stuff doesn't play nice with SmartThings socket outlets).
I could potentially also move the XBEE from SmartThings onto HE and have a second XBEE on HE. Since I "found" a Digi XSTICK that I didn't realise I had, I think I can use that for mapping SmartThings instead (which considering all the devices on the SmartThings hub are all routers anyway, it doesn't really need an XBEE anymore).
I'll report back tomorrow.
Regarding number of end devices per XBEE router, I was looking for this info recently on the Digi website (surprsingly not that easy to find, lots of 'depending on your firmware' caveats). Read through the Q&A's and the '10-12' number popped up a few times as in this instance:
https://www.digi.com/support/forum/54449/maximum-device-xbee-that-join-network-started-coordinator?show=54449#q54449
Also found this which describes what happens in the 'router resources full' scenario:
https://www.digi.com/resources/documentation/digidocs/90001537/references/r_xbee_sleeping_problems.htm?TocPath=Categories|Working%20with%20Zigbee|_____27
That's an interesting read, based on the Everything XBEE thread my XBEEs have SN=130 and SP=AF0.
My XBEEs are XB3-24Z8ST and latest XCTU map seems to suggest the majority of the battery devices are hanging off of it.
There seems to be mixed opinions on what the client limit is, some say 10 or 12 and others say it depends on the firmware / XBEE model, as you mentioned.
Unfortunately I didn't make much progress today
I couldn't justify the potential hassle of turning off the XBEE, even if it was just temporarily, but I did do several more experiments:
Really can't see anything specifically wrong with the ZigBee network at this stage! I have a couple of Salus SP600 socket plugs on order, should arrive tomorrow so I will pair those and see what happens.
As a further test, I paired another Aqara sensor, but this time I did it about 6" from the HE hub, it paired fine and was directly connected to HE. I then tried the same thing with your sensor, directly next to the HE hub but with the same issue as before.
What I have noticed consistently now though is that by watching the network scan in XCTU, your sensors initially appear on the map, with connections to all other routers and the HE hub. But then within the next scan (which scans every 30 seconds) they disappear straight away.
As you suspected, that does seem to suggest that "something" is telling your sensors to leave the network ..... I'm just not sure what that could be given all other devices, whether routers or endpoints, are connecting fine with no issues at all.
I've ordered a ZigBee sniffer now, but it probably won't be here for a few weeks (from China to UK) so will need to wait until then to investigate any further.
I am really interested on what we can learn from your configuration.
On my end, I will try to see what I can find. I am a bit suspicious with XBee in your case. I do have XBee to test. I will try to see in the meantime if I can find anything about it. I will try to look around as well in regard issue with XBee with the Zigbee stack the I use on my sensor.
Thanks
Iman
Hey Iman,
I had a bit more time to play around today:
I'm out of ideas now really, short of shutting down every router and pulling every battery out of every device.
The sniffer is on it's way, so hopefully that may shed some light on it when it arrives!
My module was delivered this week and I connected to HE today with no problems. The driver worked great and the sensors are REAL speedy and accurate reporting. It likes to talk to EVERY other repeater in the house...quite the socialite. Haaaaa!! I'm going to try and force a few endpoint devices over to it this weekend. Will keep you posted but so far...IS GREAT!
So I was in your situation with the sensor. I was going mad, and even sent it back to Iman for a check, which it passed. I did wind up having to replace a voltage regulator on mine, but I could not get it to pair correctly even after that, until I went and bought a Cree lightbulb, through which the sensor immediately paired and has been working since. I returned the bulb, as I don't want bad repeaters in my system.
Give it a shot, locate a bulb, GE zigbee or Cree ,and then see if the sensor intializes correctly.
I know- it sounds crazy, but give it a shot. I see from your list above a "lack" of zigbee bulbs
I hope we do not get into this stage. However, one of the test that I did before I sent the sensor to you is to pair the sensor with hub without anything else in the mesh. I know that this work. We also know that the sensor connect to your ST just fine. I would say that this is a last resort thing to do.
I believe that if the sensor can pair directly to the hub it should start working. I hope your new repeater pick some children and free up a few slots on the hub so the sensor can connect directly to the hub. My reasoning is that this is a known path that I know it work. There are a lot of devices out there. If it by chance connect through a router that has some quirk, all sort of issue can happen.
@john.hart3706, thanks for the feedback. Yea, it would be interested to see more variety of endpoint tested with this module.
I think this is a different issue. I already replace the voltage regulator on Martyn's. In addition, Martyn's did have the sensor paired and at short amount of time the sensor send small amount of data. Then, it is like the module left out of the mesh. I am really curious about what cause the module unpaired. I have never seen one before.
I also tested his module in a mesh that consist of one hub. There is not a need for a bulb.
Having said that, I think @Rxich suggestion is a good one as well. a GE bulb is another repeater/router that this module can work with and tested in my home. It could potentially help in this case.
Mine would also join without bulb but then stall and stop responding. It's like the bulb allowed some critical information to be exchanged to fully complete the pair and initialization. It's easy enough to try, especially if you have Amazon prime or a home Depot near by, God knows it's like my second home 
At this stage I only have a basic understanding of ZigBee, but from what I've seen so far doesn't "slots" only refer to end devices? As far as I understand, a router device doesn't count towards any end device limits on the coordinator or any other router devices.
I now have six different router devices (XBEE, Salus and Aqara) with 28 end devices spread pretty evenly across them. The coordinator (HE hub) only has 3 end devices directly connected itself.
I believe that your sensor devices should be pairing as router devices and not end devices, so shouldn't be affected by any such end device limits?
Unfortunately I'm in the UK, so GE / CREE aren't devices that are available here.
I'm also not convinced that this would help given that other devices (Salus routers, XBEE routers, SmartThings end devices, Aqara end devices) have all paired without issues as can be seen from my previous messages.
The last Aqara end device that I paired I forced to pair directly to the HE hub by pairing it within 6" of the HE hub too and it was fine. The same test with your sensor devices didn't work.
We're suspecting that the sensors are being told to leave the network immediately or a very short time after pairing, but no other devices when paired are exhibiting this behavior.
Is there anything on the sensor side that would prevent pairing from fully completing in the first place? Perhaps some sort of timeout? Or is it expecting some data that it's not receiving from the coordinator?
Hopefully the ZigBee scanner will arrive soon and we can get to the bottom of it!
Hi Iman,
I have a V1.0 sensor version gainfully deployed as a boiler lockout monitor. I'm using DH form the below link.
I have two questions:
have you though about the best way to add a heartbeat function? It could be a rule etc, I'm just want your suggestion as to the best parameter to watch.
Is the above DH the correct one for the V1.0?
I must say this device has to be one of the most stable devices I've seen. I have had zero issues with either the hardware or connection to HE. KUDOS!
Regards
John
@martyn, I apologize for the delay. I have been busy on other work.
Yes, it would not. However, due to limitation on stack memory, there maybe a limit on neighbor table. This does not impact the limit on a device that can work with the said router/coordinator. However, for devices in the neighbor table, the way packet is sent will be different. When a zigbee device want to send a packet, especially between router/coordinator, it will check its neighbor table. If it is in the table, I can send the packet directly. If not, there is routing table that it will consult to send the packet. This will be more complicated. Other mechanism such as route discovery or source routing come in play. I just want to get some sense whether this is an area that potentially a problem.
It seems that the sensor is paired. If the sensor has issue paired into your network, the device page would not show model number and other basic information. It would also will not match the correct DTH. The additional information that it pair is that some attributes are already being sent. The information that there are 2 neighbors show that upper level zigbee protocol has already established.
Zigbee protocol has timeout mechanism. I do not adjust these values. They are set defaulted. I believe those values are chosen to be the most ideal based on the testing on the stack. If this is in an issue, typically the symptom is more intermittent. Your issue is 100% repeatable with hubitat network only. My suspicion is that there are more fundamental issue.
I hope we can learn more form the scanner. Zigbee sniffing is bit more challenging. Zigbee traffic is encrypted with unique key once paired. I hope we can get the information on the un-encrypted information.
Thanks
Iman
The sensor DTH currently has a lot of Zigbee Reporting set for its attributes. One parameter of the reporting configuration is max interval. What this does is to force the sensor to send its attribute even there is no change when the interval is more or equal to the max interval. You can use this as heartbeat since you know that the sensor must send a packet at most at n seconds.
I do not remember exactly what is the max interval for the attributes. However, with all the configure reporting in the current DTH, I would say if you don't get any packet in 5 minutes, somethings must have gone wrong. This could be your heartbeat. You can check the last updated information on your device.
I have not been doing a good job on updating label on the board. Please PM me a picture of your module. I can try to confirm with you the DTH to use.
Thanks
Iman
Download the Hubitat app
