search

Koenkk / zigbee2mqtt

Zigbee 🐝 to MQTT bridge 🌉, get rid of your proprietary Zigbee bridges 🔨
https://www.zigbee2mqtt.io
GNU General Public License v3.0
11.67k stars 1.64k forks source link

Feature: Zigbee Green Power support #3322

Closed Koenkk closed 3 years ago

Koenkk commented 4 years ago

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.

phasperhoven commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

MortenVinding commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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.

image

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:

image

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 https://github.com/Koenkk/zigbee-herdsman/pull/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 (https://github.com/zigpy/zigpy/issues/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 commented 1 year ago

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 -> https://github.com/Koenkk/zigbee-herdsman/issues/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 https://github.com/Koenkk/zigbee-herdsman/pull/92

NilkOne commented 6 months ago

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

wb441 commented 6 months ago

Hi NilkOne, I recommend the following steps:

charlesrg commented 2 months ago

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 commented 2 months ago

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)