WeatherFlow2MQTT for Home Assistant

Developers Third-Party Integrations
21

Could you also try and set the -e DEBUG=True in your docker command, to see what comes out.

22

I am receiving the data over UDP because I’m currently pulling it in via the Node Red/MQTT flow without issues. The mobile app is providing all of the information as well.

This is the interesting bit coming out of the debug:
…
INFO:main:SETTING UP Beaufort Scale SENSOR
INFO:main:SETTING UP Weather SENSOR
INFO:sqlite:Upgrading the database to version 1
ERROR:sqlite:Could not create SQL Table. Error: database is locked
ERROR:sqlite:Could not Insert data in table high_low. Error: no such table: high_low
INFO:sqlite:Upgrading the database to version 2…
ERROR:sqlite:An undefined error occured. Error message: no such table: high_low
ERROR:sqlite:Could not access storage data. Error: no such table: storage
ERROR:sqlite:Could not access high_low data. Error: no such table: high_low
DEBUG:main:Event type rapid_wind has been processed, with payload: {“wind_speed”: 0.16, “wind_bearing”: 332, “wind_direction”: “NNW”}
…

Viewing the directory, I can see the weatherflow2mqtt.db and intermittently see a weatherflow2mqtt.db-journal pop up, then disappear. I’ve stopped the container, deleted the database file, and restarted the container to double check that the database file is created again.

23

Can I suggest that you delete the weatherflow2mqtt.db and start all over again. Also make sure that the user running the docker container has write access to the SQLite DB.

Also make sure to pull the docker image with :latest to ensure you have the latest image.

24

Is this on the same machine?
Even in a docker container, I have had it where I could only read the UDP port by a single application on the same machine. You ‘should’ be able to access this data throughout all the containers but in practice I’ve found that you can not all the time; there is something about the shared network interface that has issues.
Did you try stopping the Node Red instance then trying this one?

25

I continue to be grateful for this very nice package. I’ve run into a problem. Before I troubleshoot too deeply, I wonder if anyone else has figure this out.

Every few days, HA stops receiving updates from WeatherFlow2MQTT. When I notice it and restart the WeatherFlow2MQTT container (and nothing else), things go back to normal. The HA data is stuck at the last reported value during the outage.
image
The last time it happened, I tailed the WeatherFlow2MQTT and could see that it was processing regular updates from the Tempest.

I’ll troubleshoot this and isolate it further next time it happens. As I said, for now I’m just wondering if someone else has already been down this path.

I’m running version 2.0.4 in a Docker image I built for myself on an RPi 4. The Docker image is launched via Docker Compose in the same bundle as my HA server.

26

I have not run into that issue (yet).
Ideally, we don’t want it to stop the container, but you have some options.
This does not fix your problem, but it will help mitigate it.
One option is to use make yourself a bash script that checks to see if the container is running, and if it is not then restart it. You could make a cron job to run it every hour or whatever time frame you are comfortable with.
I don’t have a script for this per se, but I do have a script to check total number of docker containers and also check updates available (I know of and used Watchtower, but it has some quirks I did not like).

27

You can add a flag to the docker command to let it restart on failure --restart=on-failure This will automatically restart the container if it crashes.

With that said, there a few bugs that have been fixed since 2.0.4, and I expect to release 2.0.9 very soon, which also catches a few of these errors that crash the container. So once 2.0.9 is out, I recommend you update to that.

28

So I have this working and it is sending the rapid_wind as expected. And I see data coming into MQTT for the other sensors but only the config and attributes seem to come over, I am not getting state from them so no values.

Example wind_bearing
config={
“name”: “WF Wind Bearing”,
“unique_id”: “HB-00048583-wind_bearing”,
“unit_of_measurement”: “˚”,
“icon”: “mdi:compass”,
“state_topic”: “homeassistant/sensor/weatherflow2mqtt/rapid_wind/state”,
“value_template”: “{{ value_json.wind_bearing }}”,
“json_attributes_topic”: “homeassistant/sensor/weatherflow2mqtt/wind_bearing/attributes”,
“device”: {
“identifiers”: [
“WeatherFlow_HB-00048583”
],
“connections”: [
[
“mac”,
“HB-00048583”
]
],
“manufacturer”: “WeatherFlow”,
“name”: “WeatherFlow2MQTT”,
“model”: “WeatherFlow Weather Station V2.0.8”,
“sw_version”: “126”
}
}

attributes={
“attribution”: “Powered by WeatherFlow2MQTT”,
“brand”: “WeatherFlow”
}

But nothing else for wind_bearing

29

Note - I just updated to version 2.0.9 and now see two new topics that update ~1/min obs_sky and obs_air which now appear to have the rest of the sensor data.

30

In my case, the docker container hasn’t crashed. I can still see new log entries. So, that flag is nice to see, but it wouldn’t help in this case.

Since I posted, I’ve been watching for this to happen again, but it’s been smooth sailing. Maybe it just needed to know that I had reported the behavior to The Proper Authorities :slight_smile:. I’ll probably upgrade to the latest release later today.

1 Like
31

@bjarne
I see that in your Github page you have the section GitHub - briis/smartweather: WeatherFlow Smart Weather Component for Home Assistant - which basically reports the data from the Weather Station to Home Assistant. (it was very to integrate to HA)

What is the difference between this method and the WeatherFlow2MQTT method (which I am having a hard to make happen ?
I am a newbie at all of this I am just taking baby steps.

Thank you.

32

My setup stopped updating HA again today. I have Debug=True, but the log is not very informative. It just shows new data from the Tempest hub (rapid wind) being processed every few seconds, and other data less frequently, as expected. It also shows SQLite being updated.

Nothing new is going to MQTT on topic homeassistant/#. I just see the retained config messages.

When I restart the docker container, MQTT starts flowing again, as expected. I don’t see anything different in the debug logging.

Nobody else has chimed in with a “me,too”, so maybe I am the only one having this problem. As a reminder, I am using my own docker image created from the Dockerfile in the git repo, and I’m running it on a RPi 4, so I guess it could be something peculiar to that environment.

If there’s anything you’d like me to try next time it happens, I’d be happy to. Unless others are seeing a similar problem, I can’t expect you to spend too much time on it.

33

This behavior is consistent with the container losing connection to the MQTT broker. I’ve found that it does not attempt reconnects and I opened a GitHub issue on it Does not auto-recover when MQTT broker goes offline · Issue #46 · briis/hass-weatherflow2mqtt · GitHub

Maybe enabling the MQTT debugging as bjarne suggested in his reply might help debug it

34

Aha. Yes, I did restart my MQTT container today. (I use Mosquitto, and I believe I have to restart it to get it to notice new passwd file entries.) Thanks for the clue!

EDIT: I did the experiment to confirm that restarting my MQTT container was enough to cause this behavior in WeatherFlow2MQTT.

35

Yes, restarting the MQTT container, also requires a restart of the weatherflow2mqtt container. The reason is that the sensors only get active, when the topic is created, which it only is upon startup of the weatherflow2mqtt container.

I will see if I can capture a loss of MQTT connection and then re-run the setup process. (No timeline)

36

Maybe as a simple solution till you can catch the time outs, is to set a little cron restarting the services like every x hours ? This can’t be very long to provoke big gaps.

37

Version 2.0.11 is now released. It contains a few fixes, plus a major change, so if you already run this please note that you will have to change the location of the docker pull command.

CHANGE: To support multi platform docker containers the new home for the container is on Docker Hub with the name briis/weatherflow2mqtt. This is where future upgrades will land. So please change your docker command to use this location. README file is updated with the location.
With this change, you should no longer have to build the container yourself if you run on a non-Intel HW platform like a Raspberry PI.
I recommend you delete the current container and image, and then re-load it using the new location.

CHANGE: Visibility sensor now takes in to account current weather conditions. Thanks to @GlennGoddard for making this change. Fixing issue #29

39

Is there any reason why this integration cannot be installed via HACS? I see you have a HACS version of weatherflow, which would be much easier at least for me vs. setting up a separate server. Do the two versions somewhat stay in sync?

EDIT: After looking at briis/weatherflow2mqtt and briis/smartweather, the mqtt version stores data locally, whereas the smartweather integration relies on the weatherflow cloud data. However, the smartweather integration will easily set up with HACS, whereas the weatherflow2mqtt requires a separate docker installation that isn’t so straightforward to install on an existing HassOS.

40

The SmartWeather version. is a HA Custom Integration, developed to to integrate directly using HACS and the Integration Pages. It uses the REST API from WeatherFlow, and as such the data returned is more feature reach, as many of the calculated values are done by WeatherFlow (Dewpoint, WetBulb, etc.). Early on a did also an Integration that uses the UDP API, but I abandoned that again, as it needed to much rework to fully comply with the way HA needs an Integration.

However there were still some people who wanted everything local, so that is why this was done. I do agree that it is more cumbersome to get up and running, but the choice is always yours. I still maintain and develop both of these versions, and it is the same data (There are still calculated fields that is not in this version, that you will find in the REST API), so it is up to you what you want to use.

Hope this clarifies.
/B

41

Release 2.0.17

A couple of new versions have been released since I last posted here. Please see the CHANGELOG.md on Github for all the details. Here are the release notes for V2.0.17:

Changes in release 2.0.17

NEW: Battery Percent sensors added. There will 2 new sensors if using AIR & SKY devices and 1 new if using the Tempest device. At the same time, the previous battery sensor name is now renamed to voltage as this is a more correct description of the value. Thanks to @GlennGoddard for creating the formula to do the conversion.

NEW: Wet Bulb Globe Temperature. The WetBulb Globe Temperature (WBGT) is a measure of the heat stress in direct sunlight. Thanks to @GlennGoddard for creating the formula

FIX: Fixing issue #71. Device status was reported wrong. Thank you to @WM for catching this and proposing the fix.

CHANGE: Ensure SHOW_DEBUG flag is used everywhere.

NEW: Added German Translation. Thank you to @The-Deep-Sea for doing this.

2 Likes