Forecast values revert to C on system reboot

[strikeir13]

I'm running a Supervised installation of HA on a Pi4 and whenever I reboot the host Pi, HA comes up and my Tempest forecast is in C until I restart the Weatherflow2MQTT addon. My system units are set to Imperial and the current weather conditions are correct, it's only the forecast conditions that are off. They are also displayed in F but the numerical values are definitely in C. An addon restart fixes this, but it would be great if it showed up in F on the first startup.

If there is any information or logs I can provide to help troubleshoot, just let me know.

[briis]

Are you running as an Add-On or a Standalone Docker container? I wonder if something changed in the last few releases where it is no longer called imperial and therefor it defaults to metric. I need to do some digging in to this.

[strikeir13]

I'm running it as an addon, version 3.1.3, and HA is on 2022.12.8.

[briis]

I am having a hard time replicating this. Just made a fresh HA install, and set it up as a US Based system with Imperial units. Installed the Add-On and loaded the Forecast, which is definitely in F as I unfortunately don't have 30 degrees C on my location. I have restarted HA a few times, always with the same result - everything is shown in the right unit format and value.

I would not expect anything to show in the logs, as it does not produce an error, just seems not to do a unit conversion. I will have to play around some more to see if I can provoke the behaviour you see.

[srwareham]

I have had similar issues, although for me I'm seeing rainfall erroneously reported in mm/hr instead of inches/hr.

I have noticed this primarily after power outages. Both my WeatherFlow Tempest and Home Assistant power off immediately (I don't have a UPS). They then reboot themselves, however, the rainfall sensor is erroneously flipped from imperial to metric. The numbers being reported are definitely in metric, and for me, the units also switched to report in metric. Here's a screenshot that visualizes the problem.

Checking the official Tempest iOS app, values are still reported as imperial.

The band aid I've found is unplugging just my Tempest's hub, plugging it back in, and rebooting the Weatherflow2mqtt add-on. The sensor values and units them report in imperial again.

Please let me know if I can help with any debugging.

My setup:

• Home Assistant OS 9.4 (HA 2022.12.8)
• WeatherFlow to MQTT 3.1.4 (was previously always at latest version) as HA OS Addon
• Raspberry Pi 4
• WeatherFlow Tempest

[robertw]

Newest build fyi

Logger: homeassistant.components.sensor.recorder Source: components/sensor/recorder.py:374 Integration: Sensor (documentation, issues) First occurred: 2:05:12 PM (2 occurrences) Last logged: 2:05:12 PM

The unit of sensor.tempest_st_00087265_visibility (nmi) can not be converted to the unit of previously compiled statistics (km). Generation of long term statistics will be suppressed unless the unit changes back to km or a compatible unit. Go to https://my.home-assistant.io/redirect/developer_statistics to fix this The unit of sensor.tempest_st_00087265_air_density (lb/ft^3) can not be converted to the unit of previously compiled statistics (kg/m^3). Generation of long term statistics will be suppressed unless the unit changes back to kg/m^3 or a compatible unit. Go to https://my.home-assistant.io/redirect/developer_statistics to fix this

[briis]

I will give it another go in replicating the error, but until I can do that, it is hard to fix.

[robertw]

it comes up often i wish i could help not a programer sorry if can provide more info please direct thank you

[kloor]

I think I'm experiencing the same issue, but it only happens when I restart the entire virtual machine which is running HAOS, not just the Home-Assistant server itself.

Here are the relevant logs from WeatherFlow to MQTT, which is installed as an add-on:

INFO:weatherflow2mqtt.weatherflow_mqtt:🏠 Home Assistant Supervisor Mode 🏠
ERROR:weatherflow2mqtt.weatherflow_mqtt:Could not read Home Assistant core config: 0, message='Attempt to decode JSON with unexpected mimetype: text/plain; charset=utf-8', url=URL('http://supervisor/core/api/config')
INFO:weatherflow2mqtt.weatherflow_mqtt:Timezone is America/New_York
INFO:weatherflow2mqtt.weatherflow_mqtt:Unit System is metric

If I were to hazard a guess, the request to the config endpoint is occuring before it is ready, and Home-Assistant is instead returning a plain text error message. If I restart WeatherFlow to MQTT, it is able to read from the endpoint successfully.

[briis]

ERROR:weatherflow2mqtt.weatherflow_mqtt:Could not read Home Assistant core config: 0, message='Attempt to decode JSON with unexpected mimetype: text/plain; charset=utf-8', url=URL('http://supervisor/core/api/config')

The call to the core config file, is one of the very first things the Add-On does, to obtain basic HASS information like: Latitude/Longitude, Elevation and the Unit System used in Home Assistant. When that error then occurs, default is set to metric - thus causing the errors downstream with all sensors and weatherforecast displayed wrong.

There might be something not fully loaded in Home Assistant when the Add-On starts, leading to the Add-On not being able to load the data.

Just for testing if this is the case you could try and set the WeatherFlow2MQTT Add-On NOT to 'Start on Boot' and then make an automation like this:

description: Start WeatherFlow2MQTT when Home Assistant has started
mode: single
trigger:
  - platform: homeassistant
    event: start
condition: []
action:
  - delay:
      hours: 0
      minutes: 0
      seconds: 15
      milliseconds: 0
  - service: hassio.addon_start
    data:
      addon: 67f4b1af_weatherflow2mqtt

Please note addon name in the automation might be different for you. Select it from the UI and you get the right name.

[srwareham]

I've implemented this workaround and will try this weekend to see if any combination of sudden poweroffs still trigger an issue. Really appreciate the time and help!

[kloor]

Switching to using an automation instead of the "Start on boot" option does seem to work around the problem for me. I even found that adding a delay to the automation is possibly not necessary as the homeassistant.start event seems to be triggered late enough in the process.

[briis]

I am happy the workaround fixes this - I am not sure why it stopped working, only that something must have changed in the order Home Assistant starts and makes the data we need available. This only applies to people running this as an Add-On and with Imperial units.

[srwareham]

Seems to have worked for me as well. Thank you again!

[robertw]

Good morning regrettably the workaround does not seem to be resolving the issue on my system Logger: homeassistant.components.sensor.recorder Source: components/sensor/recorder.py:385 Integration: Sensor (documentation, issues) First occurred: 6:30:10 AM (2 occurrences) Last logged: 6:30:10 AM

The unit of sensor.tempest_st_00087265_visibility (nmi) can not be converted to the unit of previously compiled statistics (km). Generation of long term statistics will be suppressed unless the unit changes back to km or a compatible unit. Go to https://my.home-assistant.io/redirect/developer_statistics to fix this The unit of sensor.tempest_st_00087265_air_density (lb/ft^3) can not be converted to the unit of previously compiled statistics (kg/m^3). Generation of long term statistics will be suppressed unless the unit changes back to kg/m^3 or a compatible unit. Go to https://my.home-assistant.io/redirect/developer_statistics to fix this

I tried extending the delay and it did not fix the issue if I can provide any additional information ....

[briis]

Under the assumption that you run with Imperial Units, this actually shows that the workaround DOES WORK. What you see is that the Long Term Statistics are complaining that units for a sensor has moved from one Unit to another, and I can see that it moved from Metric units to Imperial units. To fix this, go to Developer Tools and then click STATISTICS in the top menubar. Here you can fix these warnings by clicking the Solve button for each.

[robertw]

Thank you so very much !!!!!!!!!!!!!!!!!!!!!!!!

[srwareham]

@briis Unfortunately it looks like this workaround doesn't solve my problem after all. I just had a power outage again this week and my normally imperial values all shifted to metric. I'll try to dig into this more scientifically later, but what I noticed:

1. The logs section for weatherflow2mqtt addon were completely empty. When I restarted the addon, the usual log info is present. I'm not sure how they'd end up empty in the first place given the addon is in fact running and logging weather data (albeit using the wrong units)
2. The addon was successfully started by the automation with no issue. Weather data showed up in my influxdb less than a minute from addon start

I can't confirm this yet, but I think network state might be a relevant factor here. In my previous testing, I simply power cycled the weatherflow hub only. However, when I have an actual power outage, my router goes down at the same moment as my hub. I'm guessing that weatherflow2mqtt is starting before my network is up and normally running. My home assistant device (raspberry pi) is connected via ethernet but the weatherflow hub is connected via wifi. It could be that the weatherflow2mqtt addon starts before wifi (and therefore the weatherflow hub) initializes? Or perhaps there is some dependency on internet connectivity specifically? My router/AP/modem is a notoriously slow to boot XFINITY model.

[srwareham]

Digging into this more my guess is that there's a failure mode being hit either when weatherflow2mqtt.py

1. Checks if it's running under a HA_SUPERVISOR https://github.com/briis/hass-weatherflow2mqtt/blob/bfa7c4c229db76958f9159b5510de37f229df5b9/weatherflow2mqtt/weatherflow_mqtt.py#L790-L793
2. Queries http://supervisor/corea/api/config https://github.com/briis/hass-weatherflow2mqtt/blob/bfa7c4c229db76958f9159b5510de37f229df5b9/weatherflow2mqtt/weatherflow_mqtt.py#L883-L899

I'm not very familiar with asyncio. Would it be possible for the initial config set using some form of try catch? That way, if config = await get_supervisor_configuration() times out, config could be set by os.environ instead of remaining null.

Another alternative would be for config to be the union of get_supervisor_configuration() and os.environ (although one would have to trump the other in case of collision). If os.environ took precedence, this bug could probably be worked around by specifying UNIT_SYSTEM: imperial in the addon's configuration section.

What do you think?

[GlennGoddard]

It just came to my attention that HA has the ability now to do conversions for the desired unit of measurement. This can be selected via the UI in HA. We need to update for the newly added items to device_class like precipitation related ones. This will allow conversions to be removed from this integration and allow the user to selected each sensor for their desired unit of measurement.

[briis]

I have now pushed a new dev build, which incorporates the suggestions above, plus new device classes for specific sensors. Let me know if you still encounter the problem - even though I know this is not occurring all the time.

[GlennGoddard]

Initial observation is that temperature and pressure is selectable for units but rain rates, wind speeds, and distances are not selectable. I checked the code and the device class seem to have been added but it is not reflecting in HA. I will give it time and check again.

[strikeir13]

I just encountered this issue again and I identified one additional factor that may (or may not) be related. As I noted initially, I'm running a Supervised installation which means I periodically manually update system packages in the underlying Debian system, including Docker. Whenever I update Docker, it kills HA, so I reboot to allow HA to startup on its own without any additional Docker commands. This is by far the most common reason for host reboots, and is typically results in the HA error message about mismatched units. Restarting HA or the Weatherflow addon fixes the unit mismatch, as expected.

I have not implemented the delayed start automation described above, so I can't speak to whether Docker updates would affect that solution.

Edit 8-7-2023: I've implemented a HA automation that starts this addon just 2 seconds after HA startup and it seems to have resolved the error message for me.

[srwareham]

Yep sadly I just re-encountered the bug. Not sure what triggered it. Here's the log:

INFO:weatherflow2mqtt.weatherflow_mqtt:🏠 Home Assistant Supervisor Mode 🏠
ERROR:weatherflow2mqtt.weatherflow_mqtt:Could not read Home Assistant core config: 0, message='Attempt to decode JSON with unexpected mimetype: text/plain; charset=utf-8', url=URL('http://supervisor/core/api/config')
INFO:weatherflow2mqtt.weatherflow_mqtt:Timezone is America/Los_Angeles
INFO:weatherflow2mqtt.weatherflow_mqtt:Unit System is metric

Weirdly enough, I had changed my addon configuration to include UNIT_SYSTEM: imperial. I would have thought that'd stop this from happening given the semi-recent release with the changes

[sirmeili]

I'm getting the same 2 error messages as @strikeir13 above in his image.

Would delaying the addon start up fix this still or is that work around no longer any good?

Edit: Well I tried and even delaying up to 1 minute I get the issue. Would be nice if the correct settings could be loaded, but maybe it's not that big of an issue.