Ok, can you also check the sensor that indicates the last time there was lightning? It indicates, 52 years ago (il y a 52 ans)
.
Was this a different value before? I’m aware of the issue on new instances where lightning has never been recorded. But otherwise it should try to pull from the sqlite database.
Because this uses the local UDP data from the sensor directly and not the rest/websocket API from WeatherFlow, only data captured while it is running will be available. So even though you can see there has been lightning this year on WeatherFlow, it won’t show up here unless the addon was running during a lightning strike event. This addon writes the data to a local sqlite database to help store and retrieve data that was captured while it was running to try and handle this. But until an event happens, it won’t have the data.
Hello, it’s me again. Since the update, all the sensors which had a maximum and a minimum, no longer have them
Version 3.0.3 should resolve this
You can remove those. They are left over from earlier releases.
- TZ (Timezone) and UNIT_SYSTEM are taken from Home Assistant if you run as an ADD-On
- TEMPEST_DEVICE is no longer needed as we just go through each attached Physical Device
- ADD_FORECAST is not needed. If you want the Forecast, just fill out STATION_ID and TOKEN
1 Like
I’m getting these errors in my log:
INFO:weatherflow2mqtt.weatherflow_mqtt:Setting up Tempest sensor: Wind Direction Avg
INFO:weatherflow2mqtt.weatherflow_mqtt:Setting up Tempest sensor: Wind Gust
INFO:weatherflow2mqtt.weatherflow_mqtt:Setting up Tempest sensor: Wind Lull
INFO:weatherflow2mqtt.weatherflow_mqtt:Setting up Tempest sensor: Wind Speed
INFO:weatherflow2mqtt.weatherflow_mqtt:Setting up Tempest sensor: Wind Speed Avg
ERROR:weatherflow2mqtt.forecast:Your API Key is invalid or does not support this operation
WARNING:weatherflow2mqtt.forecast:Forecast Server was unresponsive. Skipping forecast update
ERROR:weatherflow2mqtt.forecast:Your API Key is invalid or does not support this operation
WARNING:weatherflow2mqtt.forecast:Forecast Server was unresponsive. Skipping forecast update
Any ideas?
Thank you!
Looks like you may need to validate your Station Id and Station Token to ensure they are correct.
1 Like
That was it! - Thank you! (was using the Tempest name)
Thank you for creating this awsome docker container! I did notice even though I set things to imperial that some sensors are not following this setting such as wind speed, distance, etc. Before I dug into a bit of manual MQTT sensors to correct the issue I wanted to make sure there wasn’t some other setting I was missing.
This is the first I hear about this, and it has been running now for quite some time, also with Imperial users. Can you describe how you set it up (Separate Container on Home Assistant Add-On). And also exactly what sensors show wrong values.
Nevermind it looks like a trailing space on the unit_system was causing the issue. I’ve created a PR to have the template fixed on the unRaid template but it might not be a bad idea to trim the string on your side as well for double safety. Thanks for the quick response! All is well now.
1 Like
Running into a bit of an issue, Im only able to get forecast data but not any sensor data. I’m running weatherflow2mqtt in a standalone container and my tempest hub is on a different subnet.
DEBUG:pyweatherflowudp.client:Started listening
INFO:weatherflow2mqtt.weatherflow_mqtt:The UDP server is listening on port 50222
DEBUG:weatherflow2mqtt.weatherflow_mqtt:Sending updated forecast data to MQTT
DEBUG:weatherflow2mqtt.weatherflow_mqtt:Forecast update will run in ~29 minutes
DEBUG:weatherflow2mqtt.weatherflow_mqtt:Forecast update will run in ~28 minutes
DEBUG:weatherflow2mqtt.weatherflow_mqtt:Forecast update will run in ~27 minutes
DEBUG:weatherflow2mqtt.weatherflow_mqtt:Forecast update will run in ~26 minutes
I might be confused but is WF_HOST suppose to be the IP of the tempest hub or my local hosts?
Yes WF_HOST is used for that. Normally if your container and the hub are on the same Subnet, you just leave it blank and it defaults to 0.0.0.0.
I am not a network expert, so I am not sure how you ensure you reach the Hub, but I am positive the are others out there that know how to do that with UDP traffic.
UDP broadcasts cannot cross subnet/router boundaries. Your Hub needs to be on the same IP subnet as the HA container…
Just for clarification. I know what you mean but what you meant to say was the hub needs to be on the same subnet as the container for WeatherFlow2MQTT. HA can be on a different subnet as long as it can reach the MQTT broker and the broker in turn must be reachable by the WeatherFlow2MQTT container.
Hopefully this clarification is actually clearer but I may have just made it more muddy.
1 Like
Thank you, moved it around to a different host to test it out. Now I will got do a conditional forward for udp packets on that subnet.
Thanks for your work and all of the contributors to the project. Been enjoying it for the past month or more now. Love it! I finally got around to doing a review video on my channel of it and have this container/addon in the video.
1 Like