Replies: 16 comments 24 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: |
|
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. |
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. |
|
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? |
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/ |
|
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? |
|
I think for now, an interface that allows the user to write plain text and then read the response is more than enough. |
|
@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? |
|
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. |
|
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). |
|
Yes I agree with you. I already proposed this feature. Its quite a big change because it requires recertification and its pretty important change. |
|
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. |
|
This is really disappointing. I did not expect Shelly to cut corners like this. |
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). |
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:" 
|
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. |
|
Currently trying to decide if I use 2PM Gen4 for quite a few shutters. All mounted in wall. |
|
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 |
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: |
|
Kind of a sidebar-ish question. I fully am behind getting Zigbee OTA working (if only for full certification w/ HomeAasistant) and also understand that such updates will suck over Zigbee due to image size. Also I am in the boat of having several of these in-wall so getting to the buttons is a no-go from a practical sense. With that context, is there any work/progress on ZHA being able to toggle Wifi on the Gen4 devices over Zigbee endpoints as is being worked on in the Z2M camp? If I can turn on wifi, update, and turn it off without touching the device physically that goes a long way towards good maintainability and keeping sanity intact. My github searching is failing me on finding this so far. |
|
FYI, Shelly have now released three new Zigbee products, (as well as a new "Shelly LoRa Add-on" for their Shelly Gen4 devices that can link two existing Shelly devices up to 5km to "Break barriers and extend control where other technologies can't reach"): Shelly BLU Remote Control ZB (model SBRC-005B) - remote with Bluetooth and Zigbee connectivity for flexible control of smart devices: Shelly Flood Gen4 (S4SN-0071A) - leak detector with sensor cable (released in both North America and the European Union + the UK)
Shelly Dimmer Gen4 (S4DM-0A101WWL) 
|
For reference, spotted that zigbee-herdsman developers has merged some initial Wi-Fi Configuration feature for Zigbee2MQTT now. See: and You can see a such Z2M configuration example here: Anyway, there is a request for zha quirks (ZHA Device Handlers) for Shelly Gen 4 Specific Clusters including Shelly WiFi Setup Cluster here: |
|
@teodor-hristov FYI, for reference, you should be aware that the zigpy project (goverened by the Open Home Foundation) now also have its own official central firmware Zigbee OTA image repository (beta and dev) as well as matching zigpy-ota OTA provider for the zigpy library: Quote: "Please check if this meets your needs and fill out the issue form there to submit your firmware." Example proof-of-concept implementation here in the zha library: Quote: "Please reach out if you have any questions or open a discussion on the zigpy repository directly" Update: Note that by default, only stable firmware is available, (which is highly recommended for most users that are not zigbee developers). So the zigpy-ota stable channel is active by default with Home Assistant Core 2026.1.0 and later with no configurations required by the end-user. To opt into pre-release firmware, add this to your Home Assistant configuration: zha:
zigpy_config:
ota:
extra_providers:
- type: zigpy_ota
channel: beta # or 'dev' for bleeding edge (unstable, not recommended)
override_previous: truePS: Here is a more extensive introductory comment that TheJulianJES wrote for ThirdReality: Originally posted by TheJulianJES in zigpy/zigpy#1724 (comment)
|
|
@teodor-hristov any update or thoughts on Shelly providing Zigbee OTA firmware images to the official zigpy-ota repo for HA's ZHA? Again, while the repository is still in its early stages but the plan is for it to sooner or later eventually officially become the Open Home Foundation's prefered way for Zigbee device manufacturers to provide Zigbee OTA firmware updates if using Home Assistant's ZHA: As others have pointed out I believe many potential buyers of these will simply not buy Zigbee devices from Shelly if they find out that can not upgrade device firmware via Zigbee OTA process using the Zigbee gateway application that the device is joined/paired with. |
|
We created an endpoint where HA can get available Zigbee firmwares per device. It is not public yet. We have tested it using a modified config. We want to use our endpoint instead of posting .fw files inside a GitHub repo for numerous reasons. I missed the part to find where this information should be provided to you, but I hope i will find it when we deploy the new ver. |
@teodor-hristov reference this for your internal testing -> https://github.com/zigpy/zigpy/wiki/OTA-Information-for-Manufacturers Legacy method was to add provider code to the zigpy library -> https://github.com/zigpy/zigpy/blob/dev/zigpy/ota/providers.py (That outdated content was documented here -> https://github.com/zigpy/zigpy/wiki/OTA-Device-Firmware-Updates ) Also, if the files are not provided to the zigpy-ota repository by yourself then can always temporarily allow some selected end-users to alpha/beta-test OTA files by following this manual OTA configuration -> https://github.com/zigpy/zigpy/wiki/OTA-Configuration Recommend you open a private dialogue with @TheJulianJES and @puddly to discuss why you do not want to use zigpy-ota repo. PS: Regardless, suggest also post a public discussions too in zigpy-ota repo here -> https://github.com/zigpy/zigpy-ota/discussions |
|
Quote for reference from last reply post in this indirectly related issue tracker for the zigpy library -> zigpy/zigpy#992 Originally posted by @TheJulianJES in #992
|
|
FYI, Shelly has now released a Zigbee and BLE-based "Ecowitt WS90" (SBWS-90CM) 7-in-1 weather station in partnership with Ecowitt: @paveljandejsek and @DougMunford begun working on an zha quirk device handler for it that he posted in a device support request here: For reference; Zigbee2MQTT has also already added a handler for it: Ecowitt Weather Station Power by Shelly
|
|
FYI, Shelly have now released or announced several additional dual-protocol devices that will support both Zigbee 3.0 and Bluetooth 5.0 Shelly BLU TRV (model: SBTR-001AEU) smart Thermostatic Radiator Valve battery-powered that added Zigbee support in newer firmware 
Shelly BLU H&T Display ZB (model: SBHT-103C) battery-powered temperature + humidity sensor e-paper display with built-in Digital Clock 
Shelly BLU H&T ZB (model: SBHT-203C) battery-powered temperature + humidity sensor available in different colors 
Shelly BLU Wall Switch 4 ZB DK (model: SBBT-104CEU) four button battery-operated in European style wall plate design 
Shelly BLU RC Button 4 ZB (model: SBBT-104CUS) four button battery-operated in North America style wall plate design 
Shelly BLU Button Tough 1 ZB (model: SBBT-102C) shock/water/dust-resistant compact single button battery-operated 
PS: Note that @benmaximov & @gutiar-junky are currently developing ZHA Device Handlers (a.k.a. zha-quirks) for some Shelly BLU devices. |
|
@Hedda FYI, I was able to snatch up three Shelly BLU H&T ZB and all of them work fine via Z2M, despite being not certified (yet). 🤞 |
|
FYI, Shelly have now released Zigbee firmware for two additional dual-protocol devices that can now support both Zigbee 3.0 or Bluetooth: Shelly BLU Distance ((model: SBDI-003E) ultrasonic distance sensor (which can be optionally be activated via vibration sensor or button) 
Shelly BLU Door/Window (model: SBDW-002C) detects open/closed doors/windows + it can also measure tilt-angle and light/luminosity. 
PS: Several developers of ZHA Device Handlers (a.k.a. zha-quirks for zigpy/zha) are working on adding custom support for these and more:
|
|
For reference, @dw86uk has open an issue in zigpy repositoryspecifically addressing zigpy not parsing and matching RPC requests here: He also submitted a pull request with a suggestion for a possible solution for that specific issue here: Update: Also spotted that @LaurynasGr submitted a manufacturer-specific custom Shelly WiFi setup quirk for Shelly 1PM and 2PM devices: And @teodor-hristov submitted a custom ZHA quirk for handling Shelly presence sensor and its Zigbee light custom cluster: @benmaximov from shelly has also submitted an indirectly related pull request to zigpy for handling DST attribute handlers to Time cluster: @teodor-hristov any chance you could review that pull request and address feedback/input to the issue if needed too? |
|
I saw the MR but the proposal there suggested the function to be implemented in a quirk. |
|
FYI, Shelly has now released several new devices based on ESP32-C6 and as such they also migrated to Espressif's Zigbee stack will differ(?). These at least all look to be available in Europe and supports Zigbee, BLE, or WiFi: Shelly Dimmer Gen4 (S4DM-0A101WWL) high-voltage dimmer module:
Shelly Dimmer 0/1-10V PM Gen4 (model: S4DM-0010WW) low-voltage dimmer module: 
PS: Noted that enclosure color on the Shelly Dimmer 0/1-10V PM Gen4 is not green in colour so that part does not follow their other color schema for different device functions, as all their other dimmers have in the past had the color green. |
Yet another few multi-protocol devices marketed globally (USB or 110-240 volt) from Shelly that is also based on ESP32-C6 MCU SoCs: Shelly Presence Gen4 (device model: S4SN-0U61X) mmWave radar human occupancy sensor can track up to 6 people in 10 zones: 
Shelly EM Gen4 (device model: S4EM-002CXCEU) energy meter for external power monitoring that supports up to 2 single-phase 120 Amp AC current clamps, as well as having a dry contact relay for contactor control, plus more storage for local data logging on the device: Note that their page sais it supports up to 120 Amp AC current clamp variant but the one it ships with is only one 50 Amp in the box:
@teodor-hristov / @benmaximov have you at Shelly made any progress with native Zigbee OTA firmware updates on these "newer" devices that are based on the ESP32-C6 MCU or your "older" devices that were based on Silicon Labs EFR32 Multiprotocol Wireless MCUs? Also curious to hear news if Shelly as a Works With Home Assistant partner have any plans to get these Zigbee devices WWHA certified too? |
For reference, @dw86uk has now also opened pull request to zha-device-handlers (zha-quirks) for custom Shelly RPC input state support: @teodor-hristov can Shelly Presence Gen4 quirk expose occupancy endpoints dynamically (presence zone discovery) via RPC? See ref: Also spotted that @LaurynasGr pull request for adding manufacturer-specific custom Shelly WiFi setup zha-quirk has now been merged: |
I guess we can try to implement it. Let me check if we are on the same page. That's all about implementing easier usage of the rpc cluster through the quirk and then throwing some rpcs to the device getting the proper information, right? |
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 zha & zigpy support those?
Can all features from Shelly's custom cluster be fully exposed in the ZHA integration? -> https://www.home-assistant.io/integrations/zha
I think that the best outcome would be if ZHA could some day expose 100% of all of Shelly's manufacture-specific funtions in an easy way.
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?
https://github.com/zigpy/zigpy/wiki/OTA-Information-for-Manufacturers
For reference please these Z2M pull requests add custom Shelly WiFi Setup Cluster (Zigbee endpoint 239) configuration + RPC cluster node:
Feature: Wi-Fi Configuration via Zigbee for Shelly Gen4 Devices Koenkk/zigbee-herdsman-converters#10276
[Feature] Basic RPC cluster code and LED control for Shelly Powerstrip Koenkk/zigbee-herdsman-converters#10659
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 and @benmaximov 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 most of these globally and obviously any Zigbee device not using mains-powered can be used world-wide:
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).
Update, best for users of the ZHA integration in Home Assistant if the we together could convince Shelly to follow Zigbee standard for OTA cluster so possible to release standard Zigbee OTA files for firmware updates via Zigbee OTAU and always get a copy of those uploaded/published via the zigpy-ota repository (on GitHub).
PS: Also certified all Shelly devices that are Zigbee capable as Zigbee devices for the "Works With Home Assistant" (WWHA) program. See:
All reactions