I love the new sub-devices for multi-channel Shelly relays in HA 2025.6.0. So much cleaner!
The Shelly integration currently creates duplicate temperature sensors for each channel/sub-device on multi-channel Shelly devices (like Plus 2PM, Pro 4PM). Since these devices have only one physical temperature sensor, all sub-device temperature entities show identical values. This feature request proposes moving the temperature sensor to the main device entity.
Current Behavior
Shelly Plus 2PM creates 2 sub-devices, each with its own temperature sensor
Shelly Pro 4PM creates 4 sub-devices, each with its own temperature sensor
All temperature sensors show the same value (as they’re reading from the same physical sensor)
Proposed Change
Move the temperature sensor entity from sub-devices to the main device, creating only one temperature sensor per physical device.
Benefits
Accurate representation: Matches the physical hardware (one sensor per device)
Previously, separate temperature entities were also created for each channel/relay. This is due to the way the device sends data, for each channel it sends temperature data. We are aware of this problem, but it is difficult to solve because it may turn out in the future that devices with separate temperature sensors will be created and our fix will breake compatibility with them.
Thank you for the response and for acknowledging this issue! I understand the concern about future devices potentially having multiple temperature sensors.
Would it be feasible to maintain a device list that specifies which models have shared temperature sensors? Many integrations already have device-specific handling.
If new multi-sensor devices are released, they simply wouldn’t be in this list and would keep the current behavior. This approach:
Accurately represents current hardware (one physical sensor)
Alternatively, given that, as far as I know, to date, no multi-channel Shelly device has shipped with more than one temperature sensor (not counting devices like the Plus Uni, just considering relays) perhaps it would be cleaner to move the temperature sensor to the main device as suggested and accept that, if a device with per-channel temperature measuring is released, we have to support that when needed.
Would either of these approaches work from your perspective?
It’s a bit more complicated. Shelly integration creates a set of entities for the device based on the list of components received from the device. This eliminates the need to maintain a list of devices and their capabilities. This way, new Shelly device models simply work without any changes to the code.
In the case of the temperature sensor, this component is assigned to a relay on the device side, so the integration automatically assigns it to a sub-device. Changing this logic will probably cause problems with assigning other entities to sub-devices.
Currently we want to catch and fix any problems with sub-devices. At this point changing the logic of assigning entities to sub-devices could end in a spectacular disaster
Don’t get me wrong, we know it’s an issue and we have plan to fix it but we’re looking for a good solution that won’t cause any other isuess. That’s why it’s hard to say when the problem will be solved.
Thank you for explaining the underlying issue! It’s also great to hear that there is agreement that it should be fixed eventually.
If you have the time and inclination, I’d love to hear more about the current thinking on the long-term solution. It’s always interesting to learn how HA maintainers reason about architectural decisions and trade-offs.
Honestly, there is currently no good idea on how to solve this, but the truth is that no one is currently working on it. The priority is to reach the platinum level in IQS. I think that only after that we will return to this topic.
