I had to replace the battery in one of my Samsung buttons that monitors temperature in the refrigerator in the garage. I was anticipating trouble after my motion sensor issue, but it rejoined normally and has been consistently reporting temperature. I didn't have to reset or pair it though.
The child data info on /hub/zigbee/getChildAndRouteInfo report when run on a C8 appears to report garbage, I don't know the cause of this yet.
The device count is correct, the addressing is not.
5 Likes
child devices
The IDs don't correspond to any of my zigbee devices.
3 Likes
Aha ok thanks
1 Like
Just soot checked a few of mine. Short names in routes above do match my
devices. But as you said i am missing child data.
What's weird is that even when there are nothing but child devices on the network, the shortID's that are being used on-air don't match up with the child table that the getChildandRouteInfo page is showing (and that AFAIK comes from an api call to dump the hub's child table).
At join time, every Zigbee device (router or end device) gets assigned a shortID, either by the coordinator (if it joins directly) or by the repeater/router receiving the join request . It's done to save the overhead of transmitting a full 64-bit IEEE address with every non-broadcast frame. These shortID's get generated randomly, either by the hub or router as needed; it's done that way because there's no way to otherwise coordinate the retirement/re-use of already used addresses throughout a PAN ID (and they need to be retired should they go unused for a while, because the pool would eventually be exhausted by devices that join and for whatever reason go away and never seen again).
Ultimately there is a match that must be maintained between the IEEE address and 16 bit shortID; at join time any inadvertent conflicts between shortID's (as would happen if a new device gets randomly assigned an already used shortID) get detected and resolved transparently. What we're seeing here seems to be symptomatic of a mismatch somewhere in the housekeeping relating to the shortID-IEEE matchups, and also the C-8's failure to issue randomized shortID's when a previously joined device has left the network and rejoins (for end devices; it's assigning randomized shortID's to routers correctly). Devices that the hub knows about from their initial join keep getting an already assigned shortID on subsequent resets/rejoins; also, internally it appears to not fully matchup their IEEE addresses with whatever current shortID they have been most recently given (which may have been assigned by through a router). Evidence of this is the appearance of the bogus child table shortID's (which never change somehow) that are surfacing in the hub's child table when an end device happens to be direct connected to it.
3 Likes
Sounds lile it may be some vestage left over from the zigbee migration process. Ie maybe something was missed Internally during the process. Does everything work correctly if hub is reset and zigbee devices added manually. Ie no migration?
If that's the case its gonna be a pain to fix as most of our c7s are reset and nuked so no redoing the process. That means some special external."fixup" process will need to be written.
I've actually just reset the Zigbee radio on my C-8 and did a soft reset to wipe its database. It still shows broken child table behavior; it does show different bogus ID's vs. the migration bogus ID's for the same devices (I just joined a couple of Iris V2 devices so far). But those shortID's aren't the ones that appear in the sniffer trace.
Whats bothering me now is that I can't get my Loratap Zigbee 3.0 button to join (without dropping off) at all... this device did work fine when migrated from the C-7 initially. My previous observation (that this device was one of those that I got to join by 'removal' like the Iris V2's) may have been mistaken...
4 Likes
I also had a strange problem with Loratap button:
- endpointId: 01
- application: 40
- manufacturer: _TZE200_2m38mh6k
- model: TS0601
It joined a fresh new C-8 hub (no migration), but the device LED was blinking constantly, like the pairing process never ended at the device side. I had to remove and reinsert the battery to stop the blinking loop.
A second pairing was successful however... So it may be a device firmware bug, will repeat the tests later again.
2 Likes
Ok, good info; I'll try that. I also noticed that when the Loratap (I'm using the 4 button version here) has a good pairing that it's blinking light turns solid for a while during the process.
EDIT: Just can't seem to make it join successfully; it seems to complete (device gets created) but immediately stops working and the Loratap's light doesnt go solid during the process, indicating failure. However same device does pair w/o issue on C-7 and C-3 when I tried it previously (and when migrated from C-8 originally, it worked).
Yep, that sounds exactly like how most of my pairing attempts went, but with the added twist that I experienced this same behavior early last week on my C-7 too.
1 Like
I had to reset my radio twice to get most of my devices to join. I also shut the hub down for 30 minutes. I wasn't as systematic in my approach as you have been, so YMMV. Even after the 2nd reset the hub still shows broken child table behavior. But everything joined easily and is still working.
1 Like
@Tony our devices are different, although both are sold under Loratap white label...
Yours is using _TZ3000_xxxxxxx chipset, while mine is based on _TZE200_xxxxxxxx chipset. These SoC modules are different.
Ah yes. Mine shows
- manufacturer: _TZ3000_ee8nrt2l
- model: TS0044
EDIT: Just tried and paired two of them to the C-7 (and another to the C-3; my shipment of these came in a few days ago). They all paired to C-7 and C-3 fine using your Tuya Scene Switch TS004 driver. I do notice that battery levels are showing 48% and 2.7V (and it's a coin cell-- that's pretty much dead at that voltage); if true that is very low. Maybe worth trying with a new battery on the C-8...
1 Like
Another small data point - Iris v1 button fell off my mesh. Tried batter in/out reboot, didn't help, reset button and tried repeatedly to rejoin, never got past the following:
Tried adding it to one of my C-7s, paired up easily/immediately.
1 Like
On the C-8, did you 'remove' it from its device details page prior in addition to the device reset? That seems to get complete pairing for the Iris V2 contacts & motions I've tried.
2 Likes
Yes I tried it both without removing it and after removing it. And it consistently failed to pair again on the C8. First time I tried on the C7 it paired immediately.
I haven't had similar problems with my Iris V2 motion sensors. They've either started working again by having a battery in out or by a repairing.
I'll be monitoring the Iris v2 motion sensors to see if they stay connected.
1 Like
I notice that the format of the getChildandRouteInfo page has changed slightly with the C-8.
For C-3 and C-7 it shows this:
EzspGetParentChildParametersResponse [childCount=1, parentEui64=0000000000000000, parentNodeId=65535]
For C-8 it shows:
Parent child parameters
EzspGetParentChildParametersResponse [networkId=0, childCount=0, parentEui64=0000000000000000, parentNodeId=FFFF]
There's a new parameter (networkID) in the response (or maybe that is a parameter now needed in the API call??), and the parentNodeID is now being returned (or requested? I'm not a programmer LOL) in hex instead of decimal.
Probably nothing more than a reflection of a newer Zigbee SDK level, but if anything is using parameters for the API call that generates the info shown there (and doesn't provide for the extra one and the format change), who knows... seems coincidental with the garbage child ID's now being returned.
2 Likes
Interesting; I'm also running into inability to freshly pair a previously-migrated-OK device (the Loratap button I mentioned in a recent post; new battery made no difference other than reporting 3.0 and 100% when it easily paired to the C-7; device doesn't give solid light pairing indication and doesn't work even though C-8 indicates it was found and joined).
1 Like
