Temperature units wrong after upgrade to 2021.9.0

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 :wink:

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?


Just an update for those following. @mfratto opened an issue on GitHub for this problem, maybe go over there and comment or +1 it to try and get dev attention.