Feature: Zigbee Green Power support

[Koenkk]

Zigbee Green Power support has now been added. This enables support for e.g. the Philips Hue Tap and Friends of Hue switches.

I've created this issue in order to discuss this functionallity.

• Requires latest dev branch
• Documentation (important)

[electrofloat]

So If I'm reading the docs right, this won't work without a Philips Hue device, am I right?

So even If I bought a Hue Tap only (without any bridges, other Hue devices, etc.) I wouldn't be able to use it.

[Koenkk]

@electrofloat correct (and it needs to be in range)

[electrofloat]

@electrofloat correct (and it needs to be in range)

That's a shame.. I'd have liked to use it in itself (without any other devices).
But great improvement anyways.
Maybe in the future some miracle happens and makes this doable :)

[Koenkk]

@electrofloat maybe in the future an additional CC2652R router can also be used for this. But for sure a "special device" is needed to make it work.

[alekslyse]

Have you tried the green power firmware for xbee? I did see yesterday when I was trying to get xbee working with z2m they had a dedicated ZigBee green power firmware. Anything you want me to try?

[TheNetStriker]

@Koenkk I've just tested this and I managed to get my two Hue Tap switches to pair. They are now in the database and I assigned a friendly name, but I cannot see anything in the debug log after the pairing when I push the buttons. There are also no mqtt messages on zigbee2mqtt/friendlyname.

Are there any additional steps needed to get this to work or what am I doing wrong?

By the way, I managed to get the devices paired on channel 11 by long clicking on the big button with the one dot that surrounds the smaller buttons. (The documentation states that only channel 15, 20 and 25 can be used)

[Koenkk]

@TheNetStriker thanks for testing this, any chance you could sniff the traffic when joining the device and pressing buttons afterwards? https://www.zigbee2mqtt.io/how_tos/how_to_sniff_zigbee_traffic.html

[TheNetStriker]

@Koenkk I already uploaded a packet capture in the first thread about the Hue Tap. Here is the link to the pcap file: https://www.dropbox.com/s/pk1jt5h5yvtkb36/HueTap.pcapng?dl=0

Or do you need a fresh packet capture for this?

I also found something about the Hue Tap in the log:

zigbee2mqtt:error 2020-04-11 13:12:59: Failed to execute LQI for 'huetap_1'
  zigbee-herdsman:adapter:zStack:znp:SREQ --> ZDO - mgmtLqiReq - {"dstaddr":28743,"startindex":0} +10s
  zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,3,37,49,71,112,0,32] +10s
  zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,1,101,49,0,85] +10s
  zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,1,101,49,0,85] +0ms
  zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 1 - 3 - 5 - 49 - [0] - 85 +0ms
  zigbee-herdsman:adapter:zStack:znp:SRSP <-- ZDO - mgmtLqiReq - {"status":0} +10s
  zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [] +1ms

And in the state.json this is the only property that the device has:
"linkquality": 0

[Koenkk]

Green power devices don't respond to these LQI requests, so I've excluded them from the network scan (fixed in latest dev branch)

Regarding the sniff, it doesn't contain useful information. I need a sniff in were they are also successfully paired with zigbee2mqtt.

[ndfred]

Congratulations on getting this working! Should the docs also specify that a Zigbee 3.0 firmware is needed for this to work, or did you manage to get it to work with Zigbee 1.2 as well?

[Koenkk]

@ndfred it also works with 1.2

[ndfred]

Just tried it with zStack12 on channel 20, worked wonderfully! Held the button for 10 seconds, paired immediately when I let go, all buttons work no problem. I went around the house to see if the taps would register everywhere (I wondered if it would use the mesh network or if it would only communicate through its gateway bulb) and it worked flawlessly everywhere. Super happy I could pair all my remotes now!

A few nits that might be worth calling out in the documentation:

• binding doesn't work (I expected that, but always good to be explicit)
• the vendor might need some polish, I would have expected it to be Philips (not a big deal relly)

Specifically this is the configuration entry for the device (mine is a Philips Hue Tap switch which I bought in France ages ago):

{
  "ieeeAddr": "0x0000000000408e0f",
  "type": "GreenPower",
  "networkAddress": 36367,
  "model": "GreenPower_On_Off_Switch",
  "vendor": "GreenPower",
  "description": "On/off switch",
  "friendly_name": "bedroom_fred_bedside_remote",
  "manufacturerID": null,
  "modelID": "GreenPower_2",
  "lastSeen": 1586699144251
}

TBH this is a super niche type of switch (expensive and not very nice to tap) so I would understand if you don't want to bother with that, but if you do I am more than happy to redo all the pairing with whatever debug logs you need to display the proper hardware profile.

And thanks again for getting this to work!

[Koenkk]

@ndfred thanks, added this to the docs.

We cannot distinguish between e.g. a Hue Tap and a Friends of Hue Niko switch, Green Power device don't share such specific information.

[TheNetStriker]

@Koenkk I've just uploaded a new packet capture to my Dropbox: https://www.dropbox.com/s/andvjbcpr78p8jk/HueTap.pcapng?dl=0

[Koenkk]

@TheNetStriker I need your network key in order to decrypt te sniff, please send them to me on telegram (@Koenkk).

[Zibeez]

This is fantastic! This was the only thing keeping me from migrating away from my Hue bridge :)

I tried this with a Niko Friends of Hue switch and a couple of Philips Hue bulbs, with a CC2531 USB stick.

Some notes:

• Is it possible to clarify which actions are supported by which devices? Looking at https://github.com/Koenkk/zigbee-herdsman-converters/blob/21ebddc40f13df79eeb3bd47adbace614826f93b/converters/fromZigbee.js#L4503, a lot of actions are listed, but I find that for the switch I tested only 'recall_scene_x', 'press_x_of_2' and 'release_x_of_2' seem to be supported.
• For the switch I tested, these names are also misleading. Better would be: 'recall_scene_[0-3]' -> 'button_press_[0-3]' and 'recall_scene_[4-7]' -> 'button_release_[0-3]'
• I sometimes experience a (large) delay. At this point I am unsure whether the delay is caused by the fact that the CC2531 is underpowered, a zigbee2mqtt performance issue, or a performance issue in the automation code processing the mqtt messages (I use openhab on a raspberry pi). With the Hue Bridge, response was always instantaneously.

[ndfred]

Sharing my experience with it, hoping it might be helpful to you, I have a Hue Tap and not a Niko one:

• the actions I've been able to capture are toggle, recall_scene_0, recall_scene_1 and recall_scene_2 respectively for the buttons with 1, 2, 3 and 4 dots
• I haven't seen any delay, how long is "large" in your experience? A few things worth checking:
  • if you tail the ZigBeeToMQTT logs while you are taping the buttons, are you seeing the delay? If not then maybe OpenHAB is introducing it.
  • are you seeing a lot of traffic when tailing the ZigBeeToMQTT log? If so you might see contention on the network.
  • did you change your ZigBee channel from the value you had on the Hue bridge? You might now see interference you didn't see before
  • can you share the link quality of the bulbs around the switch, and have a look at your network map to if the routing makes sense? It might take a bit for your new network to adapt.
  • are you running your CC2531 USB stick from a USB extension cord, and do you have a PCB antenna or an actual antenna? The shielding might be worse than the Hue Bridge.
  • do you still have the Hue bridge running? That could cause ZigBee interference if they are on the same channel (though ZigBee is not that chatty).
  • how large is your ZigBee network (number of devices)? CC2531 is performance issues are only apparent past a certain threshold

I have 17 devices including 6 remotes and one motion detector so really 10 devices that are always on the network, which is not a lot for the CC2531. My Hue Tap remote link quality is 10, which is less than other devices but I guess that is down to its low power budget.

[Koenkk]

Is it possible to clarify which actions are supported by which devices? Looking at

1. Hard to do, the main problem is that we cannot identify which device it exactly is, unlike non green power devices, they don't share an exact model ID.

For the switch I tested, these names are also misleading. Better would be: 'recall_scene_[0-3]' -> 'button_press_[0-3]' and 'recall_scene_[4-7]' -> 'button_release_[0-3]'

Because of point 1, we cannot further specify the actions, it make work for e.g. the hue tap but not for another device, currently I made the action match against the green power specification.

[Zibeez]

@ndfred
Thanks for the quick responses!

I haven't seen any delay, how long is "large" in your experience?

Multiple seconds - up to 5.

if you tail the ZigBeeToMQTT logs while you are taping the buttons, are you seeing the delay? If not then maybe OpenHAB is introducing it.
are you seeing a lot of traffic when tailing the ZigBeeToMQTT log? If so you might see contention on the network.

I will do some more experiments in the next days.

did you change your ZigBee channel from the value you had on the Hue bridge? You might now see interference you didn't see before

Yes, my Hue bridge was running on a different channel (I had 2 zigbee networks running in parallel for the past year - one for the Hue bridge, one for zigbee2mqtt). It could be that the Hue Bridge channel was more robust, I will check that if none of the other suggestions help.

can you share the link quality of the bulbs around the switch, and have a look at your network map to if the routing makes sense? It might take a bit for your new network to adapt.

Good points, will check that later this week.

are you running your CC2531 USB stick from a USB extension cord, and do you have a PCB antenna or an actual antenna? The shielding might be worse than the Hue Bridge.

Yes, I run the USB stick from an USB extension cord. I do not use any PCB or antenna.

do you still have the Hue bridge running? That could cause ZigBee interference if they are on the same channel (though ZigBee is not that chatty).

No, I shut it down. As mentioned above, it was running fine in parallel with zigbee2mqtt for the past year.

how large is your ZigBee network (number of devices)? CC2531 is performance issues are only apparent past a certain threshold

I have 29 devices (and 3 groups).
Note that I use the Niko switch to control groups of 3 bulbs using the 'groups' configuration, which works very well (they always go on/off in sync, albeit sometimes with that delay).

I will do more tests during the weekend. Thanks for the help!

@Koenkk

Because of point 1, we cannot further specify the actions, it make work for e.g. the hue tap but not for another device, currently I made the action match against the green power specification.

Ah, that helps! Might be a good idea to clarify that in the documentation.

[Zibeez]

I sometimes experience a (large) delay. At this point I am unsure whether the delay is caused by the fact that the CC2531 is underpowered, a zigbee2mqtt performance issue, or a performance issue in the automation code processing the mqtt messages (I use openhab on a raspberry pi). With the Hue Bridge, response was always instantaneously.

if you tail the ZigBeeToMQTT logs while you are taping the buttons, are you seeing the delay? If not then maybe OpenHAB is introducing it.
are you seeing a lot of traffic when tailing the ZigBeeToMQTT log? If so you might see contention on the network.

I will do some more experiments in the next days.

Additional testing pointed indeed to Openhab and its MQTT broker. After optimizing those, zigbee2mqtt + Green Power support now works similar to the old Hue bridge :-)

[presslab-us]

Does anyone have experience using Z-Stack 3.0.x Router as a GPP? I have it working with Zigbee2mqtt but there are some problems with Z-Stack. I opened a thread over on the TI forum.
https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/t/902398

[mshli]

@Koenkk: For your Information: The Philips Hue Tap can also join the Network on Channel 11 by pressing the "One-Dot-Button" for 10 Seconds. Works without any problems. Please add this to the docs.

[thibaultmol]

@Koenkk so no special zigbee hub/usb stick is needed to be 'compatible with' zigbee green power, correct?

[XRyu]

Works now :)

[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

[wb441]

Good afternoon!
I have a couple of Niko Friends of Hue switches.
The doc allowed me to pair them successfully.
So far, I could only get them to do anything useful by going via NodeRED to "pair" the button actions to send a MQTT command back to z2M.

Ideally, I would like the Niko Friends of Hue switch to influence a nearby Ubisys D1. That last one supports Zigbee Green Power, but is there in fact now way for them to work together unless a layer like NodeRED/Home Assistant/OpenHAB is used?

Thanks for the clarification

[vandenbogerd]

I just managed to get the "GreenPower_On_Off_Switch" in Zigbee2MQTT.
But I don't get how to get the 4 buttons active in HA?

Anything I'm missing here?

[davidjb]

@vandenbogerd The four buttons appear as the state of the relevant Tap switch's sensor in Home Assistant. So, in other words if you have a Tap switch with the friendly name of tap_switch_foyer in zigbee2mqtt, it'll appear as sensor.tap_switch_foyer_action in HA and its state will momentarily be one of toggle (button 1), recall_scene_0 (button 2), recall_scene_1 (button 3) and recall_scene_2 (button 4) after a press occurs.

From there, you can use the state of the sensor to create triggers for automations like so. This example listens to presses from different buttons on two different switches to perform the same action but you could just as easily listen to just a single trigger:

- id: switch_foyer_light
  alias: Toggle Foyer Light from foyer switch and lounge switch
  initial_state: true
  trigger:
    - platform: state
      entity_id: sensor.tap_switch_foyer_action
      to: toggle
    - platform: state
      entity_id: sensor.tap_switch_lounge_action
      to: recall_scene_2
  action:
    - service: light.toggle
      entity_id: light.foyer_light

[phasperhoven]

I'm in the process of moving my devices from deConz to Zigbee2mqtt. After pairing one of my Greenpower switches I noticed this combination doesn't seem to support a hold (long press) action. I just see press and release actions. deConz sent different codes for short and long press. Unfortunately I was using some of these long presses, so I'd like them supported:-). Is that something that is coming, or has someone found some sort of solution/workaround, either in Z2M or in Homeassistant?

[juamiso]

I'm in the process of moving my devices from deConz to Zigbee2mqtt. After pairing one of my Greenpower switches I noticed this combination doesn't seem to support a hold (long press) action. I just see press and release actions. deConz sent different codes for short and long press. Unfortunately I was using some of these long presses, so I'd like them supported:-). Is that something that is coming, or has someone found some sort of solution/workaround, either in Z2M or in Homeassistant?

Consider staying with deconz. I went from zigbee2mqtt to deconz and the robustness has improved dramatically. At least in my case it has been rock solid (using green zigbee devices).

[phasperhoven]

I'm in the process of moving my devices from deConz to Zigbee2mqtt. After pairing one of my Greenpower switches I noticed this combination doesn't seem to support a hold (long press) action. I just see press and release actions. deConz sent different codes for short and long press. Unfortunately I was using some of these long presses, so I'd like them supported:-). Is that something that is coming, or has someone found some sort of solution/workaround, either in Z2M or in Homeassistant?

Consider staying with deconz. I went from zigbee2mqtt to deconz and the robustness has improved dramatically. At least in my case it has been rock solid (using green zigbee devices).

Thanks, that obviously was not what I wanted to hear :-) :-)
But of course switching back may alway be an option.
I have two reasons for switching:

1. device compatibility where Z2M supports more types of devices
2. terrible performance of deConz at the moment: when I switch on a light it may last several seconds before it responds.

[nickagian]

I've read through the thread here and I'm still unsure how to use Green Power devices with Z2M. It is written that a prerequisite is that a Hue device has to be in range, but no further details are given.

Will any Hue device work?
Do I need a Hue gateway?
Do I need to do anything special or just power the Hue device and keep it in range?

[wb441]

Dear nickagian,

Indeed, I found this somewhat surprising as well.
Although many devices talk about Zigbee Green Power, in fact,
if I want the Friends of Hue batteryless button, I need to have a Hue device present in the installation. In my case, I use the Philips Hue plug.
If I unplug it, the Green Power Device doesn't work anymore.

I am sure that the Friends of Hue devices need a Hue device which is powered to 'decode' the messages.
I have that working well on multiple locations. I also would find it great that this 'translation' could be extracted and added to the zigbee herdsman/z2m implementation, but today I believe it is not yet taken up by someone.

If Zigbee Green Power devices from other manufacturers have enough with the implemention on your Zigbee coordinator, that I can not confirm or deny. Perhaps you can post a question about it with a more experienced member? I would be interested to find out more.

[wb441]

The doc also states that binding is not supported. However, z2m knows which device the command is coming from. So I wonder what the technical reason is that binding is not supported for Green Power devices...

[akentner]

I'm in the process of moving my devices from deConz to Zigbee2mqtt. After pairing one of my Greenpower switches I noticed this combination doesn't seem to support a hold (long press) action. I just see press and release actions. deConz sent different codes for short and long press. Unfortunately I was using some of these long presses, so I'd like them supported:-). Is that something that is coming, or has someone found some sort of solution/workaround, either in Z2M or in Homeassistant?

I also just switched from deCONZ to z2m and sadly realized, that PTM215Z (in my case Scenic Friends of Hue) does not support "long" press. I only get recall_scene_x and press|release_x_of_2.

I'm not familiar with external converters, yet. Perhaps, it is possible to "fake" a long press. Like, if the time between recall_scene_0 and recall_scene_4 is 0-500ms => press_1_short, if 500ms-1500ms =>press_1_long, longer than 1500ms => hold_1.
I don't know, if that possible. Anybody ideas on that?

[phasperhoven]

I (sort of) implemented the long press in Homeassistant: pressing a button triggers an automation that sets a boolean to true, waits a second and switches it off again. Releasing triggers an automation that chooses between two different actions depending on the state of the boolean.

Downside: the long press-action is not triggered on hold, but on release after hold. Takes a little getting used to,

[MortenVinding]

Indeed, I found this somewhat surprising as well. Although many devices talk about Zigbee Green Power, in fact, if I want the Friends of Hue batteryless button, I need to have a Hue device present in the installation. In my case, I use the Philips Hue plug. If I unplug it, the Green Power Device doesn't work anymore.

I am sure that the Friends of Hue devices need a Hue device which is powered to 'decode' the messages.

I only have a SunRicher SR-ZGP2801K4-DIM remote.
Pairing to Z2M is cumbersome but doable. I only have 2 Hue bulb's in my zigbee network, so I tried to disconnect power to both of them, but the remote continued to work.

I believe that the IKEA bulbs with newer firmware also works as Green Power proxies.

Consider staying with deconz. I went from zigbee2mqtt to deconz and the robustness has improved dramatically. At least in my case it has been rock solid (using green zigbee devices).

Is that only with green power devices? I don't like green power because I prefer to bind the remotes to the bulb's.
but my experience with Z2M is rock solid! I simply can't remember the last time it missed a beat.
even with most of the house fitted with cheap IKEA bulb's it still super stable.

and that correlates fine with the experience I hear from other places, where many has switched from Deconz to Z2M.

I also just switched from deCONZ to z2m and sadly realized, that PTM215Z (in my case Scenic Friends of Hue) does not support "long" press. I only get recall_scene_x and press|release_x_of_2.

I'm not familiar with external converters, yet. Perhaps, it is possible to "fake" a long press. Like, if the time between recall_scene_0 and recall_scene_4 is 0-500ms => press_1_short, if 500ms-1500ms =>press_1_long, longer than 1500ms => hold_1.

That is interesting. Do we really miss some info from these devices, or is the hold action from Deconz actually just a simulated event? @Koenkk ?

[Koenkk]

That is interesting. Do we really miss some info from these devices, or is the hold action from Deconz actually just a simulated event? @Koenkk ?

I guess it does, you can see when the device sends a message by pressing button while debug logging is activated.

See https://www.zigbee2mqtt.io/guide/usage/debug.html on how to enable debug logging.

[Skorfulose]

As per the device specification, I am now quite sure it only sends press and release events.

1.1 Basic Functionality
[…]
It is therefore possible to distinguish between radio telegrams sent when the energy bar was pushed and radio telegrams sent when the energy bar was released.
By identifying these different telegrams types and measuring the time between pushing and releasing of the energy bar, it is possible to distinguish between “Long” and “Short” push button presses. This enables simple implementation of applications such as dimming control or blinds control including slat action.

[gulli1986]

I am really interested to see an automation either in Node Red or HA if someone managed to simulate a long press!

[MortenVinding]

I am really interested to see an automation either in Node Red or HA if someone managed to simulate a long press!

I have had success by using the blueprint:
Controller - EnOcean PTM 215Z (Friends of Hue) switch
Controller automation for executing press/hold/release actions triggered by EnOcean PTM 215Z (Friends of Hue) switch.
https://gist.github.com/nickknissen/cecd1d6260068f886c565427059c3a0a

it has 3 actions for each of the 4 buttons:
Pressed,
Held and
Released

I use it with the brightness_move command in Zigbee2MQTT, so the "Held" action sends a brightness_move command, and the "Released" action sends a brightness_stop command.
works almost as good as direct binding, even on my small RPi3b.

I have also tried with the new version of Tasmota with the new "Dimmer >", "Dimmer !" and "Dimmer !" commands.
(brightness increase, stop and decrease.

I use this code for Tasmota:

service: mqtt.publish
data:
  topic: cmnd/tasmota_CCEAC0/Backlog
  payload: Dimmer1 >

not as accurate as zigbee control, but usable.

[MortenVinding]

That is interesting. Do we really miss some info from these devices, or is the hold action from Deconz actually just a simulated event? @Koenkk ?

I guess it does, you can see when the device sends a message by pressing button while debug logging is activated.

See https://www.zigbee2mqtt.io/guide/usage/debug.html on how to enable debug logging.

Thanks a lot @Koenkk!
From looking at some of the other GitHub issues I now see there is no held command from this switches, so I guess the blueprint implementation I have found is the best way to do this.

I really appreciate the crazy amount of work you put in to this project! I have been using Zigbee2MQTT for a few years now (first with OpenHAB and now with Home Assistant) and it just keeps getting better and better!
I love the technology agnostic nature of it (changing from OpenHAB to Home Assistant was just a matter of pointing my new Home Assistant to the existing MQTT broker!), and in my opinion none of the other zigbee implementations does get anywhere close to the functionality and stability of Zigbee2MQTT!

May I recommend every user to do what I have done: DONATE!
Donate if Zigbee2MQTT is as important in your smart home setup as it is in mine. We really want this project to continue developing as much as it already has don't we? 😉
https://www.buymeacoffee.com/koenkk

[mikkelsiggaard]

I've just spend some time reading about Zigbee Green Power.
Sources:
https://csa-iot.org/wp-content/uploads/2022/01/docs-14-0563-18-batt-Green-Power-Basic-specification-v1.1.1.pdf
https://www.silabs.com/documents/public/user-guides/ug103-15-green-power-fundamentals.pdf
https://www.ti.com/lit/an/swra615a/swra615a.pdf
https://hometoys.com/the-power-of-zigbee-30-all-about-the-new-and-improved-zigbee-30/

It is feature set included in Zigbee 3.0 and it enables battery-less devices to communicate, by using the energy harvested by pressing buttons.
I think this is why there are no "hold" actions sent; because no energy can be harvested by simply holding a button.
This can only be done by pressing a button.
A device with a battery can use Zigbee Green Power to achieve lower battery consumption, but sacrifices bi-directional communication (beware of exceptions).
To further reduce battery consumption Zigbee Green Power devices uses a smaller packet size, compared to good ol' regular ZigBee.

The best technical, but still relatively high-level description of the requirements to run a Zigbee Green Power is found in the document from Texas Instruments:

From this image, I think that the Coordinator can act as the "Sink" (I think they also call it "source").
What we normally think of as a Zigbee Router, which now is called a "proxy" (and sometimes a "node"), is used to convert the smaller Green Power packet to a normal Zigbee packet, that is then sent to the Coordinator/sink/source - possibly along one or more Routers/proxies/nodes (normal Zigbee mesh stuff).

I think this explains the behaviour people in this thread are experiencing. Namely:

1. A Router/proxy/node that conforms to The Zigbee Green Power specification v 1.1.1 has to be between the Zigbee Green Power device and the Coordinator/sink/source. I.E. a Philips Hue bulb/plug.
2. Since the Coordinator/sink/source doesn't "know" that a packet came from a ZigBee Green Power device, because it was translated by the Router/proxy/node, I don't think a Coordinator/sink/source has any problems receiving packets from a Zigbee Green Power device - and hence there shouldn't be any modifications made too Zigbee2MQTT (AFAIK) since it already has been handled by Green Power support zigbee-herdsman#92.

So, it is up to the rest of the manufacturers of mains-powered Zigbee 3.0 (sometimes also called "Zigbee PRO") to implement support for the Zigbee Green Power specification v.1.1.1.

Alternatively (and I don't know if this is up to spec, instead of waiting for the lazy manufacturers, could it be possible to implement the Zigbee Green Power specification v.1.1.1 in the Coordinator firmware? I realise this would circumvent the whole mesh functionality of Zigbee, but it might work? Just maybe.. ?

BTW: A nice breakdown has also been made here (zigpy/zigpy#341) but with ZHA in mind.

A quick note: I hate the way the Zigbee standard has evolved. Standards within standards, confusing naming schemes and exception upon exceptions. I've spared you all the nasty details, to be able to provide as clear and precise a description as possible. I think they had pretty good intentions, but too much freedom was left for the manufacturers - in my opinion, that is.

[Hedda]

FYI, Silicon Labs EZSP ("EmberZNet Serial Protocol") based adapter support is still experimental in Zigbee2MQTT, and while Silabs EFR32MG1x/EFR32MG2x hardware and firmware have does have support "Zigbee Green Power" (ZGP, a.k.a. GreenPower) the ezsp adapter/driver code in the zigbee-herdsman library which Zigbee2MQTT depends on does not yet support "Zigbee Green Power" (ZGP, a.k.a. GreenPower) which Philips Hue Tap and a few other "Friends of Hue" batteryless devices uses, see development here -> Koenkk/zigbee-herdsman#319

So for now you need a Texas Instruments z-stack (CC2652 or CC1352 based) adapter/driver or if you are a Python developer yourself then you could help with coding for the project by mapping the correct missing frames needed for "Zigbee Green Power" (ZGP, a.k.a. GreenPower) into the ezsp adapter/driver code -> https://github.com/Koenkk/zigbee-herdsman/tree/master/src/adapter/ezsp so in conclusion the ezsp software code need some development work to specifically add "Zigbee Green Power" (ZGP, a.k.a. GreenPower) support -> https://github.com/Koenkk/zigbee-herdsman/search?q=green plus both more developers as well as more testers activly helping out on improving that ezsp adapter/driver code in the zigbee-herdsman library.

Again, "Zigbee Green Power" (ZGP, a.k.a. GreenPower) is already supported by the z-stack adapter/driver (for Texas Instruments CC2652 or CC1352 based dongles), see Koenkk/zigbee-herdsman#92

[NilkOne]

Hello, how to add it with Zigbee2MQTT ?
My model is MOES ZT-LP-ZEU2S-WH-MS

[wb441]

Hi NilkOne,
I recommend the following steps:

• Read documentation on how to pair devices to zigbee2mqtt. If you're not that far yet, the steps before are also on there.
• Usually, in order for zigbee2mqtt to 'find' your new device, there is some factory reset button or long-press. That usually does it. If the device is not yet in the supported devices list, more configuration is needed as described here.
• If you run into an issue, open a new topic on the appropriate channel, which in this case I believe is this one.
  As a general piece of advice, it is best to go through the documentation first, have a go at it, and start a separate topic if you run into issues. Thanks for keeping this in mind!

[charlesrg]

Hello, how to add it with Zigbee2MQTT ? My model is MOES ZT-LP-ZEU2S-WH-MS

Did you ever got it to work ? I've ordered 2 and still could not get them online, however I didn't try sniffing the traffic yet.

[Namyts]

Did you ever got it to work ? I've ordered 2 and still could not get them online, however I didn't try sniffing the traffic yet.

#19405 - here is the GitHub issue for this particular device. Closest I've gotten is registering button presses (but no distinction between which one)