Replies: 5 comments 9 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 and ZHA Toolkit 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? |
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. 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. 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 joined the ”Works with Home Assistant” (WWHA) partner certification program but so far they have only certified their Z-Wave devices and there is unfortunatly no mention if certification for Zigbee devices is also planned or not: Anyway, asI understand it, 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. 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.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Shelly Group SE (the IoT device company that was formely part of Allterco JSCo) has recently released a few new devices with native Zigbee support and since then the devlopers of Zigbee2MQTT/zigbee-herdsman has raised these questions regarding Shelly RPC cluster and new endpoint; so will these new Shelly's Zigbee devices need/require to use custom manufacturer clusters to be fully supported nativly via zigpy’s zha library and new ZHA Device Handlers (quirks V2)?
For reference please this Z2M pull request custom Shelly WiFi Setup Cluster:
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 this question for discussion with zigpy developers here is obviously a goal to someday get full native support of all custom endpoints 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 started by @SvenKirschbaum 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 also offer Smart Energy Power Measurement 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/DeviceFeatures
https://shelly-api-docs.shelly.cloud/gen2/Integrations/Zigbee/WiFiSetupCluster/
"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