Replies: 6 comments 16 replies
-
|
For reference; @h1ghrise has now also posted this specific device support request posted as issue to ZHA Device Handlers for zigpy/zha asking to expose endpoints for Shelly WiFi Setup Cluster (0xFC02) and Shelly RPC Cluster (0xFC01) via zha quirks: Can all these requests/issues even be resolved via zha-quirks alone or are also changes required in the zha and zigpy libraries as well? And should this discussion maybe be moved to issues? PS: FYI, for reference, there is a similar device support request discussion for Zigbee2MQTT here: |
Beta Was this translation helpful? Give feedback.
-
|
FYI, again I have not tested any of this myself as do not own these devices, but FYI, @teodor-hristov has published a repository with YAML script tools to use Shelly’s custom Zigbee clusters for WiFi with ZHA integration enabled which require ZHA Toolkit (zha-toolkit by @mdeweerd) installed from HACS. Check it out here: Looks like the current version of that script uses ZHA Toolkit to allow you to read the Wi-Fi attributes and show then as a persistent notification, but not yet write attributes or show them via the ZHA UI according to todo in the readme file. |
Beta Was this translation helpful? Give feedback.
-
Hey! At this point, it likely doesn’t matter whether the device is for the EU or North America. What’s important is whether endpoint 239 exists. You can check that at: If EP 239 is available, then you can apply a quirk or integration for the custom clusters. If it’s not present, applying a quirk won’t be possible. The custom RPC cluster works in a pretty dynamic way — you need to keep reading chunks of the response until the full data is received. Because of this, a quirk may not be the best solution there. However, for the Wi-Fi setup cluster, a quirk should work well enough. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the reply! Is there any functionality in this RPC cluster that isn't exposed by the standard ZCL clusters? Or is it mostly used for setup? |
Beta Was this translation helpful? Give feedback.
-
So the RPC cluster allows everyone to use our Shelly devices to their full potential. Like adding a JS scripts, adding schedules, adding webhooks the RPC cluster opens a whole new world. We documented everything that can be done with our devices in our documentation https://next-api-docs.shelly.cloud/gen2/ |
Beta Was this translation helpful? Give feedback.
-
|
I see 😅. ZHA definitely isn't in a position to expose an entire scripting interface or an entire tunneled protocol right now. Does the device allow concurrent communication via Bluetooth to configure these options? |
Beta Was this translation helpful? Give feedback.
-
|
I think for now, an interface that allows the user to write plain text and then read the response is more than enough. |
Beta Was this translation helpful? Give feedback.
-
|
@teodor-hristov do you have any insights on native Zigbee OTA firmware update support from Shelly? Do you know if there is any future plans to add Zigbee OTAU support and/or publishing standard Zigbee OTA firmware? Is there a chance that Shelly will release native Zigbee OTA images soon or is it there at least a plan on roadmap for Shelly's Gen4 devices? |
Beta Was this translation helpful? Give feedback.
-
|
We decided not to implement native Zigbee OTA. I think this can be changed if we have to implement it due to user feature requests, but for now we do provide a way for firmware updates which is through wifi/ap. |
Beta Was this translation helpful? Give feedback.
-
|
That is very sad to hear. That will probably be showstopper for many ZHA (and Zigbee2MQTT) end-users who mount these in-wall. I should maybe add that from Home Assistant’s end-users perspective it would not be intuative to force ZHA-users (i.e. users of Home Assistant's built-in Zigbee gateway) to connect Zigbee devices WiFi just to upgrade device firmware on a Shelly device connected via Zigbee. It would be more user-friendly to also provide standard Zigbee OTA firmware images and allow native Zigbee updates via Zigbee gateway applications (such as ZHA or Zigbee2MQTT, etc.). That is, Zigbee devices should really never require to use Bluetooth or WiFi for firmware upgrades, that is stepping away from the Zigbee standards. I even think native Zigbee OTA update support was required to certify a Zigbee device on the Works with Home Assistant program? So if you will please consider this a feature request, as personally I will not buy a new Zigbee device in 2025 that do not support Zigbee OTA firmware updates, (and personally I avoid WiFi, however I actually own and use several Shelly Z-Wave devices today). |
Beta Was this translation helpful? Give feedback.
-
|
Yes I agree with you. I already proposed this feature. Its quite a big change because it requires recertification and its pretty important change. |
Beta Was this translation helpful? Give feedback.
-
|
Well, for me not providing OTA for Zigbee equals to not providing Zigbee at all. The importance of firmware updates cannot be overstated. The recent release notes speak for themselves. If I understood the documentation properly, with the current implementation I would need to press 5 seconds the button to enable back the wifi to initiate a firmware update. This is a tremendous burden for devices tucked away behind switches, rollers & whatsoever and it will definitively hurt scaled adoption. |
Beta Was this translation helpful? Give feedback.
-
|
This is really disappointing. I did not expect Shelly to cut corners like this. |
Beta Was this translation helpful? Give feedback.
-
FYI, Shelly (the company) has now officially joined the ”Works with Home Assistant” (WWHA) partner program (Open Home Foundation's official collaboration partnership and device certification initiative) but as I understand that Shelly have so far only choosen to certified some of their Z-Wave devices and there is unfortunatly no mention if certification for any Zigbee devices from Shelly is planned or not: Again, I believe that native support for Zigbee OTA updates from within the ZHA integration (via the zha and zigpy libraries) will probably be required before the Open Home Foundation coulld certify Zigbee devices from Shelly. And by the way, similar goes for Z-Wave devices which should also support Z-Wave OTA updates nativly as it should be possible to update Shelly's Z-Wave devices via the built-in Z-Wave JS integration. At least from what I understand, the agrement guidelines for that ”Works with Home Assistant” partner certification program stipulate that the company wanting to certify Zigbee devices for WWHA is more or less required to provide standard Zigbee OTA firmware updates nativly via Home Assistant’s built-in ZHA integration for certified Zigbee devices for standaized sustainability with support for local updates, and the devices themself also needs to have Zigbee CSA Certification as well. They seem to have reformulated this OTA firmware updates requirements recently though. Quote: Available to access firmware updates directly in Home AssistantIdeally, all devices should be able to access over-the-air (OTA) firmware updates from within our system. If this isn't possible, you must provide a way to alert users about firmware updates. PS: It should also be noted that the Works with Home Asssistant partner pogram is handled by Open Home Foundation who also governs the zha and zigpy libraries, so one would think that it is in Shelly's interest to give users of the popular Home Assistant's built-in ZHA integration the best possible out-of-the-box experince in Home Assistant's native Zigbee Gateway (which depends on zigpy/zha). |
Beta Was this translation helpful? Give feedback.
-
For reference, Zigbee2MQTT / zigbee-herdsman developers are working on a built-in GUI to configure the WiFi cluster on Shelly devices: "I faced some other problems with Shelly's custom WiFi cluster and decided to write high-level support from scratch." "GUI (default) looks now like below:" 
|
Beta Was this translation helpful? Give feedback.
-
I'll make a PR. Maybe soon you will get one :) |
Beta Was this translation helpful? Give feedback.
-
Please do not get me wrong here, I already have many Shelly Z-Wave devices and love those I have, but then they are full-on Z-Wave devices that completly follow the Z-Wave standard. So all I am saying is that a Zigbee device from Shelly should be able to do everythibg through the Zigbee protocol, including getting OTA firmware updates. |
Beta Was this translation helpful? Give feedback.
-
|
Currently trying to decide if I use 2PM Gen4 for quite a few shutters. All mounted in wall. |
Beta Was this translation helpful? Give feedback.
-
|
The thing I wanted to share without actually sharing(Maybe soon you will get one :)) here is that we have a green light for a native Zigbee OTA. :D |
Beta Was this translation helpful? Give feedback.
-
Ah, nice! Thanks for sharing, looking forward to that! Maybe soon you will get one when that is available 😄 Will you look at having a public Zigbee OTA provider server that zigpy (and thus also zha) can use? PS: Off-topic here but might also want to coolaborate with Zigbee2MQTT / zigbee-herdsman devs too: |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Does all of Shelly's new Zigbee devices require support for custom Shelly clusters and if so how can and should zigpy/zha support them?
Can all features from Shelly's custom cluster be fully exposed in the ZHA integration? -> https://www.home-assistant.io/integrations/zha
The premises is that Shelly Group SE (the IoT device company that was formely part of Allterco JSCo) has recently released a few new IoT devices with native Zigbee support under their Shelly brand and since then some devlopers working on Zigbee2MQTT device handlers (zigbee-herdsman converters) has raised these questions regarding "Shelly RPC Cluster" and "Shelly WiFi Setup Cluster" which uses custom Zigbee manufacturer specific cluster endpoints to give access to low-level and high-level features which are unique to Shelly devices; so will these new Shelly's Zigbee devices need/require to use custom manufacturer specific clusters to be fully supported nativly via zigpy’s zha library + new ZHA Device Handlers (a.k.a. zha-quirks) as well as Home Assistant's ZHA integration (both the core zha component and what is exposed in its frontend UI)?
Directly related question is also what can be done by the Shelly company to add native Zigbee OTA support to all of Shelly's Zigbee devices? Which if not supported may needs other workaround to send commands to devices and receive notifications and replies from these devices?
For reference please this Z2M pull request custom Shelly WiFi Setup Cluster (Zigbee endpoint 239):
feat: Support Shelly WiFi Setup Cluster Koenkk/zigbee-herdsman-converters#9468
"The custom Cluster is documented here: https://shelly-api-docs.shelly.cloud/gen2/Integrations/Zigbee/WiFiSetupCluster/
The documentation is however missing the fact, that any interaction with the cluster requires the APS Frame profileid to be set to 0xc001."
Fix for PR #9468: Added ShellyWiFi interface to address Type issue for properties Koenkk/zigbee-herdsman-converters#9927
Also see this related Z2M pull request which exposes a new option to override the profileId contained in the APS frame individually:
The main purpose of raising these questions and potential issues with Shelly Zigbee devices is for discussing with zha/zigpy developers here is obviously a goal to someday get full native support of manufacturer specific "Shelly RPC Cluster" and "Shelly WiFi Setup Cluster" or other custom clusters in Shelly Zigbee devices inside Home Assistant’s built-in Zigbee Home Automation (ZHA) integration component, (so that all features and functions can be controlled via Zigbee using the default UI for the "Zigbee Home Automation" component inside Home Assistant), but for reference also see this related zigbee-herdsman converter (Z2M device handler) pull request and Zigbee2MQTT discussions about adding support for enabling Shelly WiFi Setup from Zigbee config inside the libraries that Zigbee2MQTT depends on.
Follow-up question is if those should be exposed in UI of Home Assistant's ZHA to make those feature more accessible to end-users?
Then there is another follow-up question if their current Zigbee firmware support Zigbee OTA clusters and Zigbee OTAU updates? Maybe @teodor-hristov who works for Shelly has more input on all these questions? IMHO it is really stange if they do not support Zigbee OTA firmware updates and requiremthat you connect each device to WiFi just to upgrade Zigbee firmware.
I also don't know which devices Shelly only released in North/South America verses which devices they only released in the Europe Union but they are currently selling these globally:
Note! All of those devices have multiprotocol support and most also offer Smart Energy Power Measurement (PM) for energy monitoring.
https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/Zigbee
https://shelly-api-docs.shelly.cloud/gen2/Integrations/Zigbee/RPCCluster
https://shelly-api-docs.shelly.cloud/gen2/Integrations/Zigbee/WiFiSetupCluster/
https://shelly-api-docs.shelly.cloud/gen2/Integrations/Zigbee/DeviceFeatures
"Shelly RPC cluster is a custom Zigbee cluster with ID 0xFC01 that acts as a channel for the Shelly RPC protocol."
For reference, while the Shelly Group has just in the last couple of years started selling the same type of products in the Americas markers they have been a very popular brand within the European markets for about 10-years now. Shelly Europe started with only Wi-Fi devices based on ESP8266 and then ESP32 using their own Shelly IoT protocol (but also supping MQTT as an option) , and more recently they partnered with and later bought Qubino for their Z-Wave expertice (before launching their Shelly Wave series), and just in the last year they launched several multi-protocol devices that supports Wi-Fi, Bluetooth, Zigbee, and Matter (over Wi-Fi), as well as supporting KNX over IP.
By the way, [Paulus Schoutsen (founder of Home Assistant and the Open Home Foundation) hinted during the Home Assistant 2025.6 Release Party video that the Shelly company will soon join the "Works With Home Assistant" program (WWHA) but did not specify if thier device certifications will be limited to Shelly's Wi-Fi and Z-Wave based devices, or if some of their new Zigbee based devices will get certified as well. Anyway, this is relevant since both the zigpy organization and the "Works With Home Assistant" program are part of the Open Home Foundation.
For reference check out this introduction:
All devices must also have Zigbee CSA Certification (as well as FCC/CE or equivalent certifications for electronic safety and radio regulation).
PS: Again, should try to convince Shelly to follow Zigbee standard for OTA cluster and release Zigbee OTA files for firmware updates via Zigbee OTAU. FYI, Leviton and Jasco, which both Z-Wave as well as Zigbee devices have both so far only certified their Z-Wave based devices for the "Works With Home Assistant" program, and just as interesting is that niether of them provide Zigbee OTA firmware update files (at least not as far as I could find). Sad if it will be the same situation for Shelly’s Zigbee devices and even more sad if there do not publish standard Zigbee OTA update files for their devices. See example:
Beta Was this translation helpful? Give feedback.
All reactions