-
Notifications
You must be signed in to change notification settings - Fork 295
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Proposal] Removal of "forever" Permit Join #940
Comments
There are some special cases where permit join is required to be permanently enabled, if I remember correctly for some green power devices. As a simple first step, let's just remove the |
Just putting
Is it the network that needs to be open, or the commissioning mode that needs refreshing? |
For the PTM215Z/216Z, there is no need to have the In |
That's an interesting case, I have a big doubt that permit_joint status (true/false) make any difference to allow GP device to join or not. Sometimes I figure out that GP device joined the "wrong" instance of Z2M when I performed some test. For example during |
@chris-1243 Can you confirm this is the case in zStack too? I believe you have access to a network using it. @dduransseau If that's confirmed, my guess would be that the coordinator is always in commissioning mode for GP (no matter what Z2M says), but that would likely be EmberZNet-specific, and coordinator-only. |
Nope, I figure out this behavior on deconz with conbee II for the first time. I'm not an expert of herdsman, since GP provisioning do not use same type of frame, would it be possible that GP frame bypass the allow_join filter ? EDIT: I just performed the test to remove a GP device from the test instance (ember) and the main one (that use conbee II), when I execute the the commissioning sequence on the GP switch, it appear on both instance and actions are correctly handled by both instance. |
@Nerivec I need to check if this behaviour occurs between my main network (zstack) and test (ember). As I have both PTM215/216, I will try with both of them. As far as I remember, I have not seen such behaviour. My two networks are not on the same channel and do not share the same network keys, pan id and extended id. All those values are different. As you have to choose your network channel when pairing, it sounds strange for me to see the same device connected to two differents networks. EDIT: If adapters are not on the same channel, nothing happens. That make sense. If I pair a ZGP device in Then if both adapters are on the same channel,
It seems |
In my scenario both network are on the same channel but different network and pan key. |
Since the current "Permit join" executes 2 actions (1- open the network, 2- turn on GP commissioning mode), the steps are a bit blurred as to what GP actually needs to pair/pair after reset. |
I just found this issue that seems related |
Make sure also have different Extended Pan-ID or you can getting strange problems then paring and network managements commands in both networks. |
This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 30 days |
Still makes sense to me. |
After observing behaviors while testing
ember
and seeing reports here and there about this, I think removing the possibility to open the network "forever" via internal workarounds would make sense.The TODOs on this would appear to be:
Related code (probably not all...):
zigbee-herdsman/src/controller/controller.ts
Line 237 in b004cf8
https://github.com/Koenkk/zigbee2mqtt/blob/f04ade6d764518bd8228eb32a15e96cd4e3fbde6/data/configuration.yaml#L5
https://github.com/Koenkk/zigbee2mqtt/blob/f04ade6d764518bd8228eb32a15e96cd4e3fbde6/lib/types/types.d.ts#L122
https://github.com/Koenkk/zigbee2mqtt/blob/f04ade6d764518bd8228eb32a15e96cd4e3fbde6/lib/util/settings.schema.json#L48
https://github.com/Koenkk/zigbee2mqtt/blob/f04ade6d764518bd8228eb32a15e96cd4e3fbde6/lib/util/settings.ts#L39
https://github.com/Koenkk/zigbee2mqtt/blob/f04ade6d764518bd8228eb32a15e96cd4e3fbde6/lib/controller.ts#L139
https://github.com/Koenkk/zigbee2mqtt/blob/f04ade6d764518bd8228eb32a15e96cd4e3fbde6/lib/extension/bridge.ts#L161
The text was updated successfully, but these errors were encountered: