Allow to change parent of a device and force parent during joining

[Koenkk]

Currently it's not possible to change the parent of device.
However this should be possible by only allowing the device to join through a certain parent.
Zigbee supports this as the permit join command allows to open a network only at a specific node.

Related issues:

• Cannot connect new devices to a TRADFRI repeater #2879

[ArkadiuszNiemiec]

@Koenkk Thanks for investigating. So this means that if I have a full coordinator and the device prefers it instead of repeater, it will never pair to a repeater? I will order a new CC2530 and try to pair the device with it.

[sjorge]

I noticed this too with Xiami device, there is a repeater close by with a good connection tot the controller but they still seem to connect to the coordinator with low link quality. But they don't always do it :/

[CodeFinder2]

Would be great to force devices to 'enter' into the network using a specified router 🙈

I've seen similar issues (Xiaomi end devices).

Edit: does it also mean that the parent will remain fixed and does/can not change over time?

[ArkadiuszNiemiec]

@Koenkk I see it was implemented. Can you tell me how to call it in zigbee2mqtt?

[Koenkk]

Its not finished yet (WIP)

[ArkadiuszNiemiec]

Oh, sorry. I have changed my coordinator to source_routing firmware and it did not help in my situation. Devices join through TRADFRI repeater for some time after setting up the network and then I cannot pair anything to it.
Edit: still waiting for my CC2531 dongles to replace a TRADFRI as a router.

[alekslyse]

This is absolutely awesome. The best solution to the xiaomi issues today is to use an xbee as a router where you can stop the kickout. If we could force those sensors to choose the xbees as parents there would be a major convencience in not having the sensors dropping out cause of not following standards

[highlandr]

Hey guys, this would be TOP as I have lot's of Xiaomi and Ikea endpoints as well.
1 CC2531 Coordinator, 1 CC2531 Router and 10 Xiaomi Plugs as Router so imagine the carnival that I have ... They tend to play alot by jumping from one to another without checking the best route... in the meanwhile I get timeouts and connectivity issues.
Thanks.

[highlandr]

From what I understand you can use the payload:
{addrmode: source_device, dstaddr: destination_router , duration: seconds, tcsignificance: 0}
and it will do the job, correct?

[ArkadiuszNiemiec]

@alekslyse can you please give me a link or reference to using xbee and stopping the kickout?

[highlandr]

I wonder how thousands of people handle the Xiaomi\Ikea kickout ... They just work and don't work... I usually don't re-pair but it's a pain to go into the shower and get into the dark for a few minutes :)
@alekslyse gave me this info on discord, https://www.sparkfun.com/pages/xbee_guide and https://www.digikey.com/short/zp7rfq
Cheers!

[alekslyse]

Im working hard on trying to get some real integration with the xbee and z2m, but sadly it require some manual modifcation in the code. In general the point with the xbee is much more control on when a child get kicked off, and used on other hubs as a solution for this issue.

The extra benefit IF we can manage to customize the xbee in is the xbee is much more than a repeater. You can run sensors on it, python scripts, battery etc, and can have a 1000m range with some versions.

[ArkadiuszNiemiec]

Thank you for your answer. So if we can force a sensor to only connect to a xbee router and turn off kickoff the sensor would not disconnect by itself as it do right now?

[alekslyse]

Thank you for your answer. So if we can force a sensor to only connect to a xbee router and turn off kickoff the sensor would not disconnect by itself as it do right now?

In theory yes, as a common problem is xiaomi timing out and are not rejoining. by stopping the router from asking the end point to rejoin. Of course its no guarantees, and to be honest if xiaomi just worked as they should this would not be a problem.

[stale]

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.

[ArkadiuszNiemiec]

Can we unstatle it? This would still be a very useful feature.

[stale]

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.

[ArkadiuszNiemiec]

Unstale

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[MRobi1]

Bumping this up to see if forcing of a parent device is possible yet?
I have 9 ikea blinds that I joined through a specific router. The blinds are all on 1 wall about 20-25ft long, router is located directly underneath blind 4. Within an hour all devices had switched to different parent devices, some are even in a completely different room. Within 24hrs 3 of the 9 blinds are not responding at all. It would be great to be able to join them through a specific device and have them stay on that device.

[Kirbo]

Bumping this up to see if forcing of a parent device is possible yet?
I have 9 ikea blinds that I joined through a specific router. The blinds are all on 1 wall about 20-25ft long, router is located directly underneath blind 4. Within an hour all devices had switched to different parent devices, some are even in a completely different room. Within 24hrs 3 of the 9 blinds are not responding at all. It would be great to be able to join them through a specific device and have them stay on that device.

What about the other way? If I was able to block certain devices to connect to the coordinator, wouldn't they then try to connect to different nodes? This way I could block like all the other devices, except lets say 15 "parent" devices.
I mean, if there was a "whitelist" and/or "blocklist" for each node that which children are allowed/prevented to join that node.

I have no idea is the idea even feasible..
Nevertheless, I'm facing the same issue. The cover in our bedroom does not want to connect to the ceiling light that is like 2 meter away from the cover, but instead if connects to kitchen light, that has 2 walls between the cover and the lights and they're like 20 meter apart. This makes no sense.

[Z18Aplha]

I am facing the same problems with my RTCGQ11LM in combination with IKEA LED1624G9.
My room of interest has two reinforced concrete walls between my coordinator. The IKEA bulbs seem to be strong enough to keep a solid connection to the coordinator. The battery powered devices have SOMETIMES ha connection to my coordinator.
The "permit join (specific device)" button does not work and all my devices want to connect through the coordinator.

I absolutey dont know why, but yesterday one of my four RTCGQ11LM connected to one of my Ikea bulbs and is its child now.
It works perfect now, but only with this certain sensor.

Maybe a blacklist on the coordinator could help, but i think the problems are caused by the cheap aqara sensors, which doesnt follow the official zigbee protocol. Otherwise they would reparent automatically.

[elbowz]

@Z18Aplha thanks for the tip of the "permit join (specific device)". It works on my configuration!

I have the same RTCGQ11LM and an IKEA E1746 (router).
First time I have paired and all works as expected (ie sensor->router->coordinator), after a while I have changed the old exhausted battery and the RTCGQ11LM wouldn't connect through the router, but setting the global join to false and permit join only on router, solve (for now)...I don't know in the next days.

[memesalot]

Is there any way to force this in the config?

Using the "Permit join (device)" worked for me, but after 12/24 hours, the devices roam to "less optimal" routes.

I have 6 bulbs in my "mancave" (concrete walls) and a Tubez router in there. I joined all the bulbs/sensors to the router, everything is great. After 12-24 hours, all but 1 bulb have migrated off the router, to random outlets/bulbs in different rooms around the house. (LQI went from ~120 on each bulb, to 6-10) When using my automations (remote/motion etc), there is a huge delay on the bulbs that have a super low lq.

If this feature does not exist, it would be nice to support forcing a device to stay on one specific router, especially when it makes no sense to roam to a device very far away with a low link quality.

[timdonovanuk]

Reviving this thread...

For me this is still critical functionality. I recently had a mains light device go offline, and it took out 1/4 of my network because of the annoying feature of Aqara devices to not actually mesh.

I'd love to re-add these devices and force using a router usb stick.

Also the advice in similar threads is contrary to the advice when adding devices, i.e.:
"for Aqara devices, add them in-situ (i.e. where they'll be used) so that they don't use the coordinator directly"
vs the advice on z2m pages to:
"move the device you are pairing as close as possible to the coordinator".

@Koenkk is this something available in another tool perhaps or something that can still be added?

[timdonovanuk]

Oh, maybe that is what this list is in the UI? It's never been clear to me what the drop down is, and reading the docs I still cannot figure it out:

[Koenkk]

Yes, picking a device in the list will only permit joining via that device so you can steer the parent.

[stefa168]

Yes, picking a device in the list will only permit joining via that device so you can steer the parent.

What happens if the parent goes offline? Do the children choose a new parent? If so, if the old parent comes back online, the old children will not change back to it, right?

[Koenkk]

@stefa168 I would expect this indeed (but it depends on the firmware of the device)

[timdonovanuk]

You'd think so, but even expensive hue devices such as the wall modules don't bother to search out an alternative parent if the existing parent goes offline or has low signal (and a poor route to coordinator). I expect it goes against the zigbee 3 spec, but hardware manufacturers don't seem to care.

FWIW, I've never got the functionality in this thread to work. Devices just flat out refuse to join the network when forced via a parent.

[matti125]

I'm in the same situation as @timdonovanuk , I cannot join the TuYa ZG-227Z (or some other devices) unless I select Permit Join (All). OTOH, I was able to join the IKEA E1603 by enabling just a single router. Any idea what could cause the difference?