The value in the MQTT message is 74, which is expected since the Shelly is configured to output °F.
I’ve always used the Shelly Discovery python script. Works flawlessly.
and does the discovery topic that’s created contain a unit of measurement?
It does, but it has always been C because the Shelly announce doesn’t include that (I pinged the developer of shelly_discovery.py. However, HA never seemed to do anything with that until now. My first guess is that HA started listening to that configuration entry with the update. My MQTT config is listed in the original question above.
I’m going to experiment with switching to the Shelly integration.
Well that’s ultimately the problem. If you can get the script to have the correct unit_of_measurement, then the problem should be fixed. My guess is that the changes with the latest energy updates cause the unit of measurement to be loaded at a different time from the customizations, which is causing issues on your system. Ultimately making your band aide (setting ºF) no longer work.
For what it’s worth, you’re not crazy and you’re not alone. I’m having the same issue with the Glances integration. As soon as I updated from 2021.8.8 to 2021.9.1 alarms started going off that my server hard drives were overheating at 78C. I eventually solved the problem by appending _f to the names of each temperature entity in the Glances integration, and then creating a template entity with the original name to convert it back to C (see below). That seemed easier than trying to track down every reference to the entities in automations, scripts, Lovelace panels, and Grafana dashboards. If it ever switches back, this should be simple to undo. Maybe this is a convenient work-around for you as well.
- platform: template
sensors:
glances_schlerver_sda_temperature:
friendly_name: "Glances Schlerver sda Temp C"
unit_of_measurement: 'ºC'
value_template: "{{ ((states('sensor.glances_schlerver_sda_temperature_f')|float -32) * (5/9))|round(1) }}"
glances_schlerver_sdb_temperature:
friendly_name: "Glances Schlerver sdb Temp C"
unit_of_measurement: 'ºC'
value_template: "{{ ((states('sensor.glances_schlerver_sdb_temperature_f')|float -32) * (5/9))|round(1) }}"
1 Like
I started swapping over my Shellies from MQTT to the Shelly integration. Those are working excellent, and the units are correct.
1 Like
Maybe due to:
You should open an issue
Having the same issue here. I use Farenheit for weather and ambient sensors, but I prefer server and 3D printer measurements in Celsius. To work around this, I used to set the unit_of_measurement to “C” without the degree symbol, causing the temperature conversion to not pick them up. After 2021.9.0, my OctoPrint MQTT sensors still read as C but they are incorrectly being converted to Farenheit. Temperature sensors started reading as 100 degrees C and triggering alerts.
remove the device class
I came for the same issue, temperature values from OctoPrint (mqqt via auto-discovery) since 2021.9.x branch. The temperature sensors are defined in the mqqt payload as:
availability_topic: octoprint/mqtt
payload_available: connected
payload_not_available: disconnected
name: OctoPrint Tool 0 Temperature
unique_id: 2626fde636f44a2bb46dc6dcebe7f0ad_TOOL0
state_topic: octoprint/temperature/tool0
unit_of_measurement: °C
value_template: ‘{{value_json.actual|float}}’
device:
identifiers: 2626fde636f44a2bb46dc6dcebe7f0ad
name: OctoPrint
manufacturer: Clifford Roche
model: HomeAssistant Discovery for OctoPrint
sw_version: HomeAssistant Discovery for OctoPrint 3.3.0
device_class: temperature
icon: mdi:printer-3d-nozzle
platform: mqtt
And mqqt payload shows like such:
actual: 23.71
target: 0
but my sensor still shows like this:
octoprint Tool 0 Temperature: 73.69 C
not sure it’s good option. You are going to replace most reliable solution with something inferior (for lot of reasons).
Personally I would do everything to make mqtt work as expected. If I understood correctly your case confirms that discovery script has flaws too. It proves that manual mqtt entities configuration is the most reliable way since you have control over everything being not dependent on software limitations
Out of curiosity, what do you consider the inferiorities of the Shelly solution? I’m far more inclined to standardize on MQTT for everything, so I will always start with that. However, the Shelly solution has been robust and stable so far. Zero delays, and it takes 3 seconds to get a new Shelly device setup. Trading that for a lot of YAML editing will require a bit more info.
comfort during configuration might not be worth a risk of low reliability. for example release 2021.9 broke shelly integration for shelly i3. Although it has been fixed in patch 3, I wouldn’t be happy with such outage.
In contrary MQTT is matured technology, independent from HA and is rock stable. Of course mqtt integration might be potentially impacted by development, but it didn’t happen for at least last two years (compare it with number of issues of shelly integrations)
here is some summary I made not long ago:
- core integration development strictly depends on available human resources in HA teams.
- when using mqtt new shelly features are available immediately, you must not wait for the integration updates
- when shellies coap protocol gets changes it might break the integration (it happened slready). cannot recall similar situation with mqtt but if it happen you can make changes in configuration on your own, noth waiting month(s) for the integration update
- more flexibility in HA entities configuration - it’s on you how you let interpret data found in mqtt. in case of the integration you are limited to what programmers coded
- access to native Shelly features, not supported by HA (and never be in near future because of HA internal limitations)
- better reliability (no risk of bugs with every ha release)
- HA mustn’t know network configuration of shellies which means easier maintenance.
- There are no ghost entities: what is not configured in config files - just doesn’t exist after mqtt entities reload
- easier monitoring/debugging of communication by watching at mqtt (MQTT explorer)
- access to shellies from multiple systems at the same time(ie NodeRed or even other instances of home automation systems)
- quicker reaction (have no exierience but a lot of reports confirm significant lags with native integration)
- native shelly integration requires multicast in network allowed. besides I’m not sure multicast is good idea in overal, but it requires specific routing conf especially in case of vlans.
- likely more…
In short, shelly integration is a black box being developed with limited resources, constrained by HA development process. All together making the use of mqtt best choice in my opinion. For the same reasons I use zigbee2mqtt instead of zha.
I see your point. I will have to make a decision regarding changing back to manual MQTT setup. I don’t want to use the discovery script if it is not going to work properly. I will let the decision stew for a bit though given the Shelly integration has worked flawlessly since I installed it. No delays at all. In fact, some of my battery devices are faster with Shelly than they were on MQTT.
Yes, it is. I already reported this issue to them providing tcp dump. In the dump I can see those devices communicate with the mqtt 3 times (instead of once) doing something time consuming in between, incl ntp lookup. It adds 1 second comparing to DDD communication.
I suppose some bit of time can be saved by using local ntp server.
but otherwise they recently shorten reaction time from 9 to 3 sec 
I switched everything on my 21 Shellies back to MQTT, and all is working relatively well. Battery devices are at least as quick as they were before. The Shelly discover python script added a use_fahrenheit option so now my HT sensors are working right again. However, now my flood sensors are not answering for temperature anymore. The MQTT messages are there, but the entity is gone.
Configure them manually as mqtt entities. I repeating to death it’s most reliable option if you don’t want to be dependent on developers
I know you did, but I have other things to do. I can live without the temperature from my flood sensors. Manually setting up 20+ MQTT entities is not something I wanted to spend what little free time I have on.
The HT sensors were my main concern, and they are working perfectly now. Until it becomes painful, or I get bored one day, I will stick to the python script.
That’s the same exact reason I am here: Octoprint temperature info is stuck in Fahrenheit.
Sensor information comes over MQTT as ºC, but because HASS is set to Imperial units globally, it converts everything to Fahrenheit.
Up until this update, you could switch it back by customizing the entity to unit_of_measurement: C which no longer works.
Converting everything to a standard unit system as it comes in is fine and all, but switching certain things back should not be as difficult as create a template sensor. Anyone have any further clarification or can we get some devs to chime in?
Thanks!