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.
Hi.
Yes, these superfluous entities are very annoying and misleading, especially when you activate the temperature entity on one sub-device and it isn’t automatically activated on the other sub-device… This causes a lot of uncertainty and misinterpretation.
My thoughts on this, perhaps they will help find a solution :
Regardless of whether a device has one or more physical temperature sensors now or will have them in the future, I think the real question or perhaps the solution, is how these are categorized in HA and how to use this information.
Let’s assume we have a device with four temperature measurement channels, e.g., with externally connected temperature sensors (otherwise, it would make little sense to have all the sensors built into one device/housing ), and this device also had an internal temperature sensor for monitoring the device temperature.
This would give us a total of five temperature sensors and thus five independent temperature entities.
With the correct categorization of these entities in HA, it should then be fairly easy to correctly assign them to the device and the sub-devices…
To do this, it would be necessary to ensure that the internal temperature sensor entity is categorized as DIAGNOSTIC and the others as PRIMARY!
And now, define that all temperature entities with the DIAGNOSTIC category are assigned to the main device, and all entities not categorized accordingly (= PRIMARY) are assigned to the respective sub-devices.
And this logic would then also apply to all other devices, as long as the categorization is appropriate.
For example, for the “Shelly plus 2PM,” the internal temperature sensor entity should be categorized as DIAGNOSTIC and the internal sensors of the “Shelly H&T” as PRIMARY, since these serve as room sensors and not for device monitoring.
I hope I was able to convey my thoughts somewhat and that they make some sense
This causes a lot of uncertainty and misinterpretation.
:
), and this device also had an internal temperature sensor for monitoring the device temperature.