PTM 215Z enOcean slow respons randomly

[samuele2723]

What happened?

Hello, i write here to have some support for my home switches because my wife is crazu with me!!

I have a large setup with Sonoff CC2531 coordinator, my network is composed by 190 devices across 4 levels (garage, ground, 1st, 2nd).
Overall the network works good, means i don't see delays of any kind when i use from home assistant app or from Z2M interface the lights.

Only random delays i have, are when using my switches around the house, that are all PTM 215Z enOcean. And my wife is mainly using these physical buttons to control the lights.

[https://zigbee2mqtt.io/devices/PTM_215Z.html#enocean-ptm%2520215z]

Sometimes, when i click, the light is switch on\off instantly, (i could not even say there is a delay).
Some other times it takes 1 to 3 seconds. This happens also in the same switch in the same moment, means if i keep push on\off the delays changes time by time.

I can't say it's an hardware issue, because i have 25 of them and all are affected (especially ones far from coordinator that's at garage level) and also because i've used these with Philips Hue Bridge and they seemed to be more responsive in that setup

What did you expect to happen?

I expect that there is no delay or minimum and repetitible always similar when i use switches. They should be almost instant in their responsiveness, I don't also want to see difference from ground floor or second floor, i would like to understand how to prioritize message responsiveness from these switches

How to reproduce it (minimal and precise)

I can reproduce it every time, and is not related to what light i turn on, or how (home assistant or MQTT) seems related to the delay of the button transmission of PTM 215Z enOcean itself.

It can also be noticed by watching the state change of click actions of PTM 215Z enOcean in the dashboard, you can perceive the message is received in delay from the switch.

Zigbee2MQTT version

1.38.0

Adapter firmware version

20210708

Adapter

ZDONGLE P 2652 sonoff zStack3x0

Setup

Home assistant OS with MQTT and Z2m Addon

Debug log

No response

[burmistrzak]

@samuele2723 We have a similar setup, also about the same size, and observed similar things.
Mainly delayed responses from EnOcean switches. I believe this started only in the last 3–4 weeks or so.

Have you paired your switches in Unicast mode? Otherwise they might overwhelm your network with broadcast traffic.

[samuele2723]

Hello there, i didnt know about that. I paired all of them with "enable join" active by all devices i guess, because i leave always open the network when z2m start.

So should i re pair them selecting the closer router for each? Could you explain more ?

[burmistrzak]

Hello there, i didnt know about that. I paired all of them with "enable join" active by all devices i guess, because i leave always open the network when z2m start.

I'll suggest you first set permit_join: false, then remove all your EnOcean switches from Z2M. Sorry! 😅
Restart Z2M when you're done, just to safe.

So should i re pair them selecting the closer router for each? Could you explain more ?

Yes!
Reset every single switch (procedure described here), then begin re-pairing by always selecting the "nearest" Zigbee router (permit join dropdown) for each EnOcean switch.

I always use the main ceiling-mounted light in every room for this job, because it cannot accidentally get unplugged. 😉

[burmistrzak]

@Koenkk Did we change something with regards to GreenPower devices recently? 🤔
Otherwise, it might all just be a big coincidence.

@samuele2723 Do your EnOcean switches control individual lights or entire Zigbee groups?

[Koenkk]

No nothing has changed regarding GP devices

[burmistrzak]

No nothing has changed regarding GP devices

@Koenkk That's what I thought... 🤔
Unfortunately, I still see random delays (up to multiple seconds) in some parts of our network (especially for TOGGLE on lights).
I first thought this might be caused by running OTA updates on some Hue lights, but they're all finished now...
And it apparently also doesn't matter how the delayed command is issued (GP via Node-RED, Homebridge, or Z2M UI).
Have you seen something like this before?

[LaurentChardin]

GP devices are tricky because they don't really connect to the Zigbee network : they need to be translated to Zigbee using the Green Power Proxy, which is a capability that all routers have if they are Zigbee 3.0 (if i am not mistaken). Therefore there are really not regular devices, and the way the routers behaves to translate the GP messages into Zigbee messages can vary across manufacturers.

As @burmistrzak states, you want to check your mesh quality too (printing the map and checking the LQI of your routers), and also be sure you have routers with good GP proxy support (difficult to know actually, but in the end, the philips ones have very good support for GP)

[burmistrzak]

@Koenkk @samuele2723 Lol, guess I've figured out my problem...
Some Hue lights (acting as GP proxy) are blasting 46 (!) broadcast messages per second for each EnOcean action they receive. Remember, I explicitly paired all PTM 215Z in unicast mode.
No wonder the Zigbee network gets totally overwhelmed.

Just look at this photog..., uhh, screenshot:

Highlighted in pink is a PTM 215Z being translated correctly to unicast, selected (in blue) is one of the 46 broadcast messages of a misbehaving switch.

[burmistrzak]

Huh, that's interesting.
@Koenkk I tried to re-pair one of the misbehaving GP switches, but I seemingly can't get it to use unicast!?

The correct Commissioning Mode has been requested by the coordinator, but as soon as GP Pairing begins, the mode somehow changes to Groupcast to pre-commissioned GroupID (0x2), for no obvious reason.

[burmistrzak]

Oh man...
This rabbit hole goes deep!

I believe I have tracked down the root cause of the problem. It seems to be the model of Hue light selected to be the GP proxy! While our ceiling lights look the same, they're from different generations. ☝️

• Philips 3261030P7 (on v1.108.5) is always responding with broadcast to GP Commissioning Notifications.
• Philips 3261031P6 (on v1.116.3) is correctly responding with unicast, when instructed to do so.

This truly seems to be a firmware issue all along.
So I assumed all our GP switches were correctly paired as unicast, but in reality, only a few of them actually were! 🤯

[burmistrzak]

This truly seems to be a firmware issue all along.

I was able to confirm that (at least) the following devices support commissioning GP devices in unicast mode:

• Hue white and color ambiance E27
• Hue white ambiance E27 with Bluetooth
• Hue white ambiance E14
• Hue white ambiance GU10 with Bluetooth
• Hue white and color ambience Argenta spot white
• Hue Being white
• Hue white ambiance Struana bathroom ceiling with bluetooth 2400lm
• Hue outdoor Impress wall lamp

Hue lights from the same generation as the ones above should work as expected. Older generations, despite latest firmware, likely use Groupcast instead.

[burmistrzak]

@samuele2723 Alright, after I made my discoveries outlined above, I also had to re-pair almost all of our EnOcean switches. 😅

Here's some important information for anyone trying to pair their Zigbee Green Power in unicast mode:

Make sure the GP proxy you choose (e.g. a Hue light) is actually using unicast commissioning when told to do so!
One good indicator I've found is the presence of an input cluster on the Green Power endpoint.
So far all GP proxies with an input cluster on that endpoint, will use Groupcast and not Unicast to pair ZGP devices.
That's what it looks like in Z2M web UI for example:

It might be possible to force/change the commissioning mode (on GP proxies with an input cluster) using some command. We'll see. I'm currently working through the ZGP specification. 😇

[burmistrzak]

A few more details:
It appears that Signify (Philips Hue) decided at some point, to upgrade their hardwired fixtures to also include a Green Power server, alongside the client cluster available on all of their modern lights.

So the type of light (removable or not) seems to be the key here, not really product generation.

[LaurentChardin]

I always thought that Input and Output GP clusters were part of the Zigbee 3.0 specifications, and needed for the certification. I see that @Hedda answered to you in Koenkk/zigbee-herdsman#902

Anyway very nice drilldown @burmistrzak

[burmistrzak]

I always thought that Input and Output GP clusters were part of the Zigbee 3.0 specifications, and needed for the certification.

@LaurentChardin Apparently not, because the E27 Hue bulbs are definitely Zigbee 3.0 certified.
It really seems to be a policy choice by Signify to only include a Green Power Sink (server) with their hardwired fixtures.

I believe what we're seeing here is the difference between a Green Power Proxy Basic, and a Green Power Combo Basic device. The latter being an interesting combination of a GP Proxy Basic, and a GP Sink Basic in a single device.

However, one big mystery still remains: Why does the proxy of such a GP Combo Basic ignore the GP Commissioning Mode requested by the coordinator?

Btw. am I the only one finding the terminology of input/output cluster a bit confusing?
Using server/client, same as in the specification, would make much more sense IMHO. 🙈

[burmistrzak]

Just realized we absolutely need to improve the dev console with more advanced features (read/write undefined clusters/attributes), so poking around gets a bit more comfortable.

Isn't there some sort of CLI for the CC2652P to interact with the Zigbee network directly?

[Hedda]

I always thought that Input and Output GP clusters were part of the Zigbee 3.0 specifications, and needed for the certification.

@LaurentChardin Apparently not, because the E27 Hue bulbs are definitely Zigbee 3.0 certified. It really seems to be a policy choice by Signify to only include a Green Power Sink (server) with their hardwired fixtures.

As I understand it, all Zigbee Router (ZR) devices need to at a minimum include support for ZGPB/GPB (Zigbee Green Proxy Basic) to be compliant with Zigbee 3.0 certification requirements

[burmistrzak]

Ok, so we're handling a GP Commissioning Notification that's coming in as broadcast differently.

                    // Communication mode:
                    //  Broadcast: Groupcast to precommissioned ID (0b10)
                    // !Broadcast: Lightweight unicast (0b11)
                    let opt = 0b1110010101101000;
                    if (dataPayload.wasBroadcast) {
                        opt = 0b1110010101001000;
                    }

This specific condition was introduced with Koenkk/zigbee-herdsman#518, and seems to be inline with the GP specification.

[burmistrzak]

The way I read the specification, a GP Proxy has to send GP Commissioning Notification commands using the mode requested in the initial GP Proxy Commissioning Mode frame.

The Unicast communication sub-field of the Options field, if set to 0b0, indicates that the receiving proxies SHALL send the GP Commissioning Notification commands in broadcast. If set to 0b1, it indicates that the receiving proxies SHALL send the GP Commissioning Notification commands in unicast to the originator of the GP Proxy Commissioning Mode command.

However, Hue lights that implement a GP Combo Basic device (mainly hardwired fixtures) are simply ignoring it, and use broadcast instead!
Thus far, I haven't found any reason in the spec for this particular behavior...

@Koenkk Am I missing something, or is this indeed a bug in the Hue firmware? 🤔

[chris-1243]

@burmistrzak

One good indicator I've found is the presence of an input cluster on the Green Power endpoint.
So far all GP proxies with an input cluster on that endpoint, will use Groupcast and not Unicast to pair ZGP devices.

Your sentence is a bit confusing for me. Shall I use a router with an input/output cluster on endpoint 242 to get unicast ?

[burmistrzak]

One good indicator I've found is the presence of an input cluster on the Green Power endpoint.
So far all GP proxies with an input cluster on that endpoint, will use Groupcast and not Unicast to pair ZGP devices.

Your sentence is a bit confusing for me. Shall I use a router with an input/output cluster on endpoint 242 to get unicast ?

If it's a hardwired Philips Hue fixture, then (at least for now) no.
All other routers that implement only a GP Proxy Basic (i.e. only output cluster) from any manufacturer should generally be fine though.
I don't know about non-Hue GP Combo Basic (i.e. input/output on 242) devices. They might work.
@chris-1243 If you have one, give it a try and report back!

[chris-1243]

Now I do understand better your explanation.
I have 7 PTM215Z and none of them are paired to a Hue router even if I have some in my network.

• 2 are paired via an Ikea LED2101G4 with input/output cluster on endpoint 242
• 2 other via an Ikea ICPSH24-10EU-IL-2 with input/output cluster on endpoint 242
• 2 via a Sonoff Dongle-E router with output cluster on endpoint 242 only
• 1 via an Ubisys S2 with input/output cluster on endpoint 242.

I have a PTM 216Z which is paired via a Hue 4034031P7 with output cluster on endpoint 242 only and it seems to work fine.

All my PTM 215Z work fine without any delays which this configuration. My network is quite small compred to yours as I have only 35 devices.

I used to get some delays months ago as all my PTM were not paired directly to a specific router.

[burmistrzak]

I have 7 PTM215Z and none of them are paired to a Hue router even if I have some in my network.

Phew, good for you! 😇

• 2 other via an Ikea ICPSH24-10EU-IL-2 with input/output cluster on endpoint 242
• 1 via an Ubisys S2 with input/output cluster on endpoint 242.

@chris-1243 Would you be able to provide a packet capture when interacting with these switches? I'm particularly interested to see how GP Combo devices from other manufacturers behave.
We currently can't really be sure whether Hue's implementation is an outlier/bug, or generally more common.

I have a PTM 216Z which is paired via a Hue 4034031P7 with output cluster on endpoint 242 only and it seems to work fine.

That's to be expected. 👌

[chris-1243]

I just had a look on how to sniff traffic and it seems possible to use an ezsp adapter for this (I have a dongle-e laying for testing). You will have to give me some time to get everything running under windows... (not se easy🫣) I will try to send you some data.

Anything special I will have to look for?

[burmistrzak]

I just had a look on how to sniff traffic and it seems possible to use an ezsp adapter for this (I have a dongle-e laying for testing). You will have to give me some time to get everything running under windows... (not se easy🫣) I will try to send you some data.

Oh, that would be fantastic!

Anything special I will have to look for?

Yes! When pressing a button, you should see exactly two GP Notification (press & release) to your coordinator. This means your GP Proxy is handling unicast correctly.
Especially interesting to me are EnOcean switches paired to your GP Combo devices (i.e. input/output on 242).

[burmistrzak]

@chris-1243 Btw. here's a guide for EZSP adapter on Windows.
Once that's all done, follow this guide to convert, and add your network key to Wireshark.

You should be ready to go in less than ten minutes, if everything goes according to plan. I had my setup (admittedly with a TI chip) up and running in under five minutes, even on macOS. 😉

[chris-1243]

It is running in more than 10 minutes....

Now, you will have to help me a bit what I should check and extract to help you. There are so many different information that I am lost. I can see this

[burmistrzak]

@chris-1243 Hmm, I'll try getting my hands on a PTM216Z module, but they don't really seem to be readily available standalone... 🤔

[chris-1243]

I found my module only on this website https://www.farnell.com

In order to debug this module, I'm looking for an Elatec NFC reader. I found one not so expensive. I wish to have a try with the computer-based app from Enocean😉

[burmistrzak]

@chris-1243 Woah! Almost 65 EUR incl. taxes and shipping for just a single module. 🤑
We definitely won't upgrade our entire installation anytime soon, at least for that price...

I believe you need an Elatec TWN4, which is around 130 EUR. 👀

[chris-1243]

@burmistrzak whoah!!! I did not pay that much mine.

Yep, a TWN4 is needed and they are expensive!!! I am still wondering if it will be a good buy🤔.

For the moment, I will try to debug my module without it. My cheap NFC reader is out of order already.

[burmistrzak]

@chris-1243 Nah, not worth it. The app we're using now, should be more than enough for what we're doing.

When you return, before doing any more tests, completely reset the PTM216Z. Just to be safe.

I now somewhat understand how ZGP_COMMAND_MAP works in theory, but I can't see where Identify would be coming from... 🤔

Maybe EnOcean can hook us up with a PTM216Z sample for research (and Z2M development)? 😁

[chris-1243]

@burmistrzak

When you return, before doing any more tests, completely reset the PTM216Z. Just to be safe.

Of course, I will. Via NFC it is really easy and you do not have to press all the buttons👍

Maybe EnOcean can hook us up with a PTM216Z sample for research (and Z2M development)? 😁

Why not... It might be good if you could get one. For Z2M, it would be great. I know @Nerivec would be pleased to have one for ember.
What would be awsome is to get a 216Z and a 215ZE😁.
I will add this to my to do list😉

[burmistrzak]

@chris-1243 Yes, would truly be fantastic!
Especially because there seems to be some sort of issue with the PTM216Z in GreenPower_7 mode. Z2M should really have no issues pairing these ZGP devices... 🤔

Having an actual PTM216Z in hand would probably speed things up significantly. ☺️

[Nerivec]

@burmistrzak Let me know if you see anything interesting I can add to https://github.com/Nerivec/ember-zli to help debug all this GP stuff (that is if you have an EmberZNet adapter to use it with). I'm adding a router mode support for adapter (without having to flash a router firmware), should be able to do some nice things with a bit of imagination 😉

[chris-1243]

@burmistrzak

Hi, I'm back for testing.....

Also, give A2 74 60 00 37 00 a try. Would love to see packet captures for that. 😊

I let you check the file I sent. I did the paring via a Philips 8718696548738. I hope I did things correctly otherwise just let me know

PTM216Z_deviceID_0x37_2024.07.23.zip

A second try via an IKEA bulb which did not work.

PTM216Z_DeviceID_0x37_failed_2024.07.23.zip

Could you help me how to read the pages 0x48 - 0x4F ? Should I send a command like 30 48 to get an output for the line 0x48 like reading 0x44 with command 30 44?

I had a try like this which is not really successful in my opinion. I got the same output if deviceID is set to 0x47... I guess I messed up something.

[0BanZai0]

Hi @chris-1243 - I went through all posts here and I have a feeling my issues with tht PTM 215Zs an my Hue GU10 (https://www.zigbee2mqtt.io/devices/929001953301.html) might be related.
In order to participate here, I'd be happy if you could give me a hint where I can see if my switches are connected via my bulbs in unicast mode :) thx

[chris-1243]

@0BanZai0

The best way to check this is to sniff your traffic. As it seems you are getting a new coordinator, you may use your ezsp based to do it.

Let us know when you will be ready

[0BanZai0]

@chris-1243 - Update! I've installed the HMG-01 gateway as a controller today (would have wanted the ZigStar one, but in Germany not easy to get in time).
While on the way, I've switched to channel 25 and set my three WiFi APs to channel 1 and 6.
After changing the coordinator, all my devices were gone. So I've re-paired almost everything.
The switches are freshly paired to their nearest hue bulb.
About 6 switches are still missing, as I'm going to install the hue ceiling lights first before integrating them into my network.

Well, what can I say. It's working for now. No more "Busy network"...
the usual problem of changing many parameters at once is not to know what fixed it in the end.
Will keep u updated when everything is installed.
Thx again

[chris-1243]

There is a firmware update for some Hue devices available (1.116.5) which seems to resolve the broadacast/unicast issue. I updated model 5047130P9, 9290022166 and had a try with a PTM215ZE. According to the data I gained from Wireshark, the PTM paired as unicast.

[chris-1243]

@Koenkk @burmistrzak @Nerivec

Guys, it took time for me to write Enocean and to receive an answer from them. I am still stuck in memory reading and NFC configuration of my PTM216Z.

I have a great new. The community could receive some PTM devices from Enocean directly in order to have a better support. I really need one of you guys to provide me an address where to send them.

[storebatfar]

Just found this thread and also having these issues with my 215Z switches.
I have seveeral of these connected to Philips Hue bulps (routers).
My coordinator is a Zigstar UZG-01.

I have tried re-pairing all devices, but still have the same slow response.

Will follow this thread. Let me know if I can assist with any testing.

[chris-1243]

@storebatfar There is an issue in some Hue devices firmwares. What you could do is to check whether or not if you find your devices model in this table. (It is not exhaustive...)

If yes, try to pair your PTM directly to those unicast capable routers only. You must select a specific model in permit join then to start the pairing process.

[storebatfar]

@chris-1243 I have been doing some testing and actually see significan improvments.
I first re-paired all switches to to one specific Philips Hue light (router).
At first I did not see any improvements, but after restarting my coordinator and Z2M, almost all lag has disappeared.

My switches are paired to the following Philips Hue model numbers:

• 8718696598283
• 8718696485880
• 929001953101

[0BanZai0]

@storebatfar - how did you re-pair them? Just by pressing the respective button for 10+ seconds?
Does the performance stay over time? (days) I'm having a lot of delay sometimes on just some of the switches.

[storebatfar]

@0BanZai0 First I removed my devices from Z2M. Then start pairing using the one Philips Hue device. Depending on you Zigbee channel, hold the corresponding button for 10 secs and release. Confirm by pressing buttons 2+3 simultaneously.

[0BanZai0]

@storebatfar thx for your fast reply :) - Till now I've never removed them from Z2M before repairing. Seems to be worth a shot!

[0BanZai0]

@storebatfar - just a quick check on you. Are your devices still fast and responsive?
I have varying luck with some of my PTM215. Some times they are responsive, some times they are not. I have no Idea on how tho see what's causing this. They all should be in unicast mode...

[chris-1243]

@0BanZai0
It is known some Hue devices do not translate ZGP frame as unicast but as broadcast... This is well explained at the beginning of this thread. There is also a list available here which needs to be completed. You will find some routers which are able or not to translate correctly those frames.

If the routers you use are not listed, you need to sniff your traffic. https://www.zigbee2mqtt.io/advanced/zigbee/04_sniff_zigbee_traffic.html

I personally have 7 PTM215Z and 1 PTM215ZE and they are all responsive and fast. They even work better than some battery powered remotes. In order to achieve this, you must pair each of them as unicast and to a compatible router. Here is the drawback.

[andreisergiu98]

Hi! I am using PTM 215Z too, paired as unicast with the following devices:

• 4090531P9
• 915005997301
• 929001953101
• 929001953301

All of them are broadcasting ~30 messages or so, for each action and none of them have a gp input cluster, only output.

All of them are using the latest firmware 1.122.2. The adapter I am using is SLZB-06m with the 8.0.2.0 firmware, and the version of z2m is 2.0.0.

My network consists of 32 bulbs, 16 gp switches and a couple of hue dimmers. The switches are very responsive, probably because the network is relatively small, but whenever I try to use zigbee groups, when I press the buttons very fast 3-4 times in a row, i get network busy errors, and I believe this might be the reason why.

Did you receive any answers from Signify?

[0BanZai0]

@storebatfar thx for your fast reply :) - Till now I've never removed them from Z2M before repairing. Seems to be worth a shot!

Good news everyone. The removing of the device was the key!
I've removed all the slow responding PTM215 and paired them to the next available Philips Hue GU10 bulb.
Now it is perfectly responsive!!! Shout out to @chris-1243