Fundamentally, this has nothing to do with saving power for a button, or designing buttons that "generate" power when operated. It's mostly about saving power for other devices. And the side effect is that this new standard is not radio-compatible with legacy Zigbee. As a result, they don't currently work with Hubitat and it's not something the community can solve because it's too low-level.
The buttons mentioned by the original poster are completely normal buttons with a coin battery (that lasts 2+ years). They contain a PCB with normal buttons on it, and they click no more or less than any other button you have operated.
And while Green Power isn't Zigbee 3.0 specific, the radio communication specs have been enrolled into the Zigbee 3.0 specifications (according to the Zigbee Alliance).
That's not the main issue. As I said: normal buttons and a coin battery can be used, as long as the specs are followed.
Being sufficiently power efficient (battery lifespan) is enough to get the Green Energy label. But this also requires using the updated radio specifications.
This has nothing to do with using "old school battery less barbecue lighters". If it did, the devices would not be as widespread as they are. And Philips would never allow the Hue brand to be tainted by them. These are perfectly normal devices with normal buttons, long battery life, and radio specs that don't currently play nice with Hubitat (but plays well with many other hubs and devices).
As I understand it, the specifications are these:
I am assuming that something in there, like encrypting the contents of data packets or supporting new attributes is preventing correct interaction with Hubitat.
That doesn't seem to fit with the Green Power agenda described by the Zigbee Alliance; the standard was designed to permit smart devices that don't require batteries thereby eliminating battery changes (for example, the Phillips Hue Tap button is a Zigbee Green Power kinetic energy powered button that doesn't use a battery).
Certainly this doesn't rule out buttons that contain batteries, but that really isn't the point. Two-year battery life doesn't require a new standard-- It's not unusual for conventional (non-Green Power) Zigbee buttons to go that long without battery changes (even some of my Zigbee motion and contact sensor batteries last that long). Green Power devices can eliminate the battery (and battery waste) completely and are intended to be maintenance free.
They're strictly source nodes, unlike conventional Zigbee sleepy devices which receive and transmit-- they aren't required to periodically wake up and communicate with a parent router. They can remain completely unpowered until activated by a kinetic energy harvesting mechanism; the use of specialized, shorter data frames reduces the amount of energy required to transmit a message by factor of 5 or more. They do require a special proxy node (a function provided by the Hue bridge) that will tunnel these shorter frames within a conventional Zigbee frame format for transmission through an existing mesh. The 'sink' node (the hub) would need the ability to interpret the tunneled Green Power frames.
I'm not sure where you are getting your information from but the switch you linked to is almost certainly batteryless it looks identical to the one inside the hue tap and other enocean / ZGP devices... and yes... this a good thing - having a home filled with battery devices is a total pain.
Politely: I have it in front of me, I have taken it apart, and it absolutely contains a battery (specifically CR2430). Battery life is reported as minimum 8 years.
As the device is approved by the alliance and figures in their product database I am pretty confident that it's within specs.
As for where I get my information, the answer is simple: From the Zigbee Alliance home page and official specs. Links are in prior posts.
I suppose then there is a follow up question- why buy a battery powered version which youâll have to replace some time when there are plenty of battery less zgp ones that you could get that donât have the headache?
The specifications I posted above are from the exact same download page that you pulled the whitepaper from. Yes, it's clear what the intentions with the standard are, but it's ALSO clear that devices with batteries are allowed if they comply with the efficiency requirements. And many (many) devices fit this description, including devices in the "Friends of Hue" category.
The core of the problem is the altered specifications on data transfer. I don't know much about Zigbee, but if this was regular Ethernet I'd call these Layer 2 changes. It is changes to data transfer control, payload encryption and packet attributes that are extensions to regular Zigbee. This layer is not available to the Hubitat community, so any future support depends on core developers picking this up.
As the standard is expanding in use, the problem increases. It is amplified by such devices simply being marketed as "Zigbee" when in fact they only work with "Zigbee Green Power" and "Zigbee 3.0". As far as I can tell, compliance with Zigbee Green Power is embedded into Zigbee 3.0.
As an observation, a lot of hubs and products do work with Zigbee Green Power, but not Hubitat (yet). If money is an issue sign me up as someone who'd be willing to pay for an upgrade. I realize most Hubitat customers are used to getting free upgrades, but I'd rather throw more money at the problem than start replacing my ecosystem with something else. Perhaps make payment voluntary so it doesn't anger the masses?
Because these are the only ones that fit seamlessly into my existing electrical installation. They look and feel like the most common parts where I live. No other device does that. And with an 8+ year lifespan on the batteries, the presence of the battery was not a concern.
It's a moot point off course, because Hubitat doesn't support it. And I am not going to add complex services like Home Assistant or OpenHap along side Hubitat. I have tried such steps in the past and it eventually ends up being a house of cards that always collapses when my wife or kids need it the most and I am not at home. I don't want more battles in the family about "finicky IoT installations".
I'll have to wait until Hubitat either implements the necessary Zigbee Green Power specifications, or the full Zigbee 3.0 specifications. Both would solve my problem, as Green Power data transfer requirements seems to be enrolled into Zigbee 3.0.
I think what we can conclude from all of this is that there are a lot of reasons that people may want to use ZGP which is why it should be added to hubitat!
It's way too think/deep though. According to specs it's 4 mm. bigger, which would make it impossible to fit into existing housings/mounts even with DIY 3D printed hacks and tricks. And as mentioned, with 8-10 year lifespan the batteries aren't much of an issue.
The major issue is that this switch also uses the Green Power specs, so it's not compatible with Hubitat without upgrades to the transmission portion of the network stack (Layer 2 in Ethernet terms - no idea if the same are used in Zigbee).
I have green power switches that connects to 230v mains. Still the same still need Hubitat to support them, because they are green power.
There is a bit of a kind of work around though. Not ideal but it works depending on your requirement. If you have ZigBee 3.0 devices some allow you to join the devices directly. So you join the output to Hubitat and the input but the input is only connected to the output/s.
The issue is then HE doesn't know that the state has changed and you can't use it as a button.
I also spotted your reply a bit late I got distracted by some other stuff but am getting back to this project now. I've got 1 switch to test things, as well as the RPi with OpenHabian and the EnOcean dongle. However I've still got no clue how to set up the Hubitat - OpenHabian link or how to properly get the switch into OpenHabian, I'm fairly new to all this. I'm gonna try and work things out, but any help would be most welcome
To add to the discussion of why anyone would use ZGP switches: I'm sure there are many pros and cons but for me it was simply that the only smart switches I could find with the exact look that I wanted happened to be these.
Just had to resuscitate this thread to say I was very irritated with battery replacing on my battery buttons till I realised they were just the wrong buttons for me - I was using SmartThings buttons that were constantly chatting about the temperature. Changed to battery buttons that just sit there waiting to be pressed, and haven't had to change a battery since. My SmartThings ones are now at work where I need temperature monitoring
Zigbee2MQTT with HA and a different controller is the way to get this. Then use virtual switches shared from Hubitat to HA and HA automations to trigger them when your Zigbee Green Power device is actuated. Anything else is just not going to happen with the Zigbee controller that Hubitat uses. There's little evidence that it's worth that change or would be a good business move for Hubitat to change the current controller.
I've been playing recently with a similar kinetic switch that controls a Zigbee switch via RF.
Although this is not a true Zigbee Green Power device, it's fun to know I will never need to care for batteries. Will probably install it at my parents house, as the Zigbee switch can control the bulbs offline.
I'm just going to work around it I suppose.... It's not ideal, but if the solution is "use HA" then I'd rather just ditch Hubitat entirely and switch over if I'm going to be setting up a HA hub anyway.
For now, until I can be arsed to set up a HA hub (or until Hubitat fixes support for this) I'll just have Hue toggle the lights on and have hubitat capture it as an 'external light activation' by way of RM getting triggered when the light turns on, and it seeing that a global variable indicating it was set by Hubitat itself ISN'T on (I'll have to add this variable and have it get set & reset every time hubitat turns lights on/off via motion sensor or something else..).. so it knows via that roundabout way that the switch was pressed.
Unfortunately Hue doesn't allow switching zones/rooms without actual physical lights in them on or off.. that would have been ideal... but I guess this will have to do for now. sigh
I've written device handlers for ZGP switches connected to the Hue hub via CoCoHue.
So if you have a ZGP 'Friends of Hue' switch and a Hue hub, I can share the code with you.
I'll talk to Robert to see if it can be included in CoCoHue
No promises it'll work though.. I only have my own 'type' of switches on hand so no idea if the events and naming adds up for other brand FoH ZGP switches.
I got distracted by some other stuff but am getting back to this project now. I've got 1 switch to test things, as well as the RPi with OpenHabian and the EnOcean dongle. However I've still got no clue how to set up the Hubitat - OpenHabian link or how to properly get the switch into OpenHabian, I'm fairly new to all this. I'm gonna try and work things out, but any help would be most welcome
