Comments (11)
For the PTM215Z/216Z, there is no need to have the permit join
always on, on my side at least. I do open the network for the pairing and close it when done.
In configuration.yaml
permit join is set to false
for me.
from zigbee-herdsman.
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 ember
test I figure out that GP switch joined the "main" instance and not the "lab" even if "main" was not configured to allow join.
I'll perform some tests with only one instance up and running to confirm this.
from zigbee-herdsman.
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 permit_join
option from the Z2M configuration.yaml
. Then we can see if any setups break.
from zigbee-herdsman.
Just putting false
as override would be a good first step for sure (just ignore the config at first). Better off waiting until after the 1st to implement any of this; just thought I'd get the ball rolling on the topic 😉
There are some special cases where permit join is required to be permanently enabled, if I remember correctly for some green power devices.
Is it the network that needs to be open, or the commissioning mode that needs refreshing?
I guess that refresh logic could be moved to GP if it's the second case (I suppose a separate button would be ideal in that scenario, kind of like Touchlink... make it clear what's what).
@dduransseau @chris-1243 Sorry for the ping, again, but I guess you've gained the GP-go-to status 😁
from zigbee-herdsman.
@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.
from zigbee-herdsman.
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.
from zigbee-herdsman.
@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 zstack
(channel 20), nothing is shown in ember
(channel 25). The other way around is the same.
Then if both adapters are on the same channel, zstack
is not impacted as it needs an open router (Hue for PTM216Z, Hue or any brand able to translate like IKEA, Sunricher for PTM215Z). ember
, the device pairs even if permit join is not active. Then, if you completely reset the device (all buttons pressed for ~10s) and you try to pair it again:
- if
permit join : false
(via the frontend) : nothing happens (I tried 3 times in a row) - if
permit join : true
via the frontend) : the PTM216Z pairs following the procedure.
It seems ember
always reacts to the commissioning frame sent by the PTM215Z/216Z even if the permit join option is turned off
from zigbee-herdsman.
In my scenario both network are on the same channel but different network and pan key.
from zigbee-herdsman.
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 think there is a need for separation here. If only to ensure proper logic, because it seems devices are currently not following open/close as directed/expected by Z2M for GP stuff.
from zigbee-herdsman.
I just found this issue that seems related
from zigbee-herdsman.
In my scenario both network are on the same channel but different network and pan key.
Make sure also have different Extended Pan-ID or you can getting strange problems then paring and network managements commands in both networks.
from zigbee-herdsman.
Related Issues (20)
- Ember driver : Error while parsing received frame, status=NO_RX_SPACE. HOT 1
- Ember driver: SET "APS_UNICAST_MESSAGE_COUNT" TO "32" with status=ERROR_OUT_OF_MEMORY. HOT 1
- State of ZiGate support HOT 17
- [Cluster Type] Align cluster definition for 'name' attribute HOT 1
- Silabs Zigbee EmberZNet 8.0.0.0 (and Silicon Labs Gecko SDK 5.0.0.0) announced and to be released in Q3 2024 HOT 1
- zStack Parsing Error & Manufacturer Custom Command reported multiple times HOT 1
- Make waitress timeout configurable HOT 1
- Lower bound of "turnsOffAtBrightness1" ignored by "brightness_move" & "brightness_step" commands HOT 1
- Issue with serialport v12 and node > v20.2.0 HOT 1
- Get strange error in latest z2m with the latest zigbee-herdsman HOT 6
- [Task] ZCL definition update HOT 4
- Want better endpoint.writeStructured() HOT 3
- Z2M 1.35.2 stops with "Adapter disconnected, stopping" after few minutes of uptime (Sonoff-E / EZSP v12 / FW 7.3.2.0 build 212) HOT 3
- Load additional manufacturer-specific clusters from device converter HOT 4
- Adapters hardware flow control issues HOT 30
- Ikea Motion Sensor E1525/E1745 not updating properly HOT 6
- proposal: deprecation of legacy clicks HOT 1
- Move special readResponse out of zhc/src/index.ts (fixes legrand pairing issues) HOT 8
- Changes to payload when sending zclData to a device breaks iobroker.zigbee function
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from zigbee-herdsman.