briis / hass-weatherflow2mqtt Goto Github PK
View Code? Open in Web Editor NEWWeatherFlow to MQTT for Home Assistant. Use UDP to get local weather data in to Home Assistant using MQTT Discovery
License: MIT License
WeatherFlow to MQTT for Home Assistant. Use UDP to get local weather data in to Home Assistant using MQTT Discovery
License: MIT License
With:
ENV ADD_FORECAST=True
INFO:main:SETTING UP Battery TEMPEST SENSOR,
INFO:main:SETTING UP Solar Radiation SENSOR,
INFO:main:SETTING UP Precipitation Type SENSOR,
INFO:main:SETTING UP Last Rain start SENSOR,
INFO:main:SETTING UP Air Density SENSOR,
INFO:main:SETTING UP Dew Point SENSOR,
INFO:main:SETTING UP Rain Rate SENSOR,
INFO:main:SETTING UP Uptime SENSOR,
INFO:main:SETTING UP Feels Like Temperature SENSOR,
INFO:main:SETTING UP Visibility SENSOR,
INFO:main:SETTING UP Wet Bulb Temperature SENSOR,
INFO:main:SETTING UP Delta T SENSOR,
INFO:main:SETTING UP Dewpoint Comfort Level SENSOR,
INFO:main:SETTING UP Temperature Level SENSOR,
INFO:main:SETTING UP UV Level SENSOR,
INFO:main:SETTING UP Beaufort Scale SENSOR,
INFO:main:SETTING UP Weather SENSOR,
DEBUG:main:Device ST-00019259 has reported a sensor fault. Reason: ['lightning disturber'],
DEBUG:main:Device ST-00019259 has reported a sensor fault. Reason: ['lightning disturber'],
DEBUG:main:Device ST-00019259 has reported a sensor fault. Reason: ['lightning disturber'],
DEBUG:main:Device ST-00019259 has reported a sensor fault. Reason: ['lightning disturber'],
DEBUG:main:Device ST-00019259 has reported a sensor fault. Reason: ['lightning disturber'],
DEBUG:main:Device ST-00019259 has reported a sensor fault. Reason: ['lightning disturber'],
DEBUG:main:Device ST-00019259 has reported a sensor fault. Reason: ['lightning disturber'],
DEBUG:main:Device ST-00019259 has reported a sensor fault. Reason: ['lightning disturber'],
DEBUG:main:Device ST-00019259 has reported a sensor fault. Reason: ['lightning disturber'],
DEBUG:main:Device ST-00019259 has reported a sensor fault. Reason: ['lightning disturber'],
DEBUG:main:Device ST-00019259 has reported a sensor fault. Reason: ['lightning disturber'],
DEBUG:main:Device ST-00019259 has reported a sensor fault. Reason: ['lightning disturber'],
DEBUG:main:Device ST-00019259 has reported a sensor fault. Reason: ['lightning disturber'],
Traceback (most recent call last):,
File "/app/weatherflow_mqtt.py", line 499, in ,
asyncio.run(main()),
File "/usr/local/lib/python3.9/asyncio/runners.py", line 44, in run,
return loop.run_until_complete(main),
File "/usr/local/lib/python3.9/asyncio/base_events.py", line 642, in run_until_complete,
return future.result(),
File "/app/weatherflow_mqtt.py", line 180, in main,
condition_data, fcst_data = await forecast.update_forecast(),
File "/app/forecast.py", line 99, in update_forecast,
ATTR_FORECAST_CONDITION: await self.ha_condition_value(row["icon"]),,
KeyError: 'icon',
DEBUG:asyncio:Using selector: EpollSelector,
INFO:main:Timezone is America/New_York,
INFO:main:Connected to the MQTT server on address 127.0.0.1 and port 1883...,
INFO:main:The UDP server is running on port 50222...,
INFO:main:Defining Sensors for Home Assistant,
INFO:main:SETTING UP Wind Speed SENSOR,
INFO:main:SETTING UP Wind Bearing SENSOR,
INFO:main:SETTING UP Wind Direction SENSOR,
INFO:main:SETTING UP Station Pressure SENSOR,
INFO:main:SETTING UP Sea Level Pressure SENSOR,
INFO:main:SETTING UP Pressure Trend SENSOR,
INFO:main:SETTING UP Temperature SENSOR,
INFO:main:SETTING UP Humidity SENSOR,
INFO:main:SETTING UP Lightning Count (3 hours) SENSOR,
INFO:main:SETTING UP Lightning Count (Today) SENSOR,
INFO:main:SETTING UP Lightning Distance SENSOR,
INFO:main:SETTING UP Lightning Energy SENSOR,
INFO:main:SETTING UP Last Lightning Strike SENSOR,
INFO:main:SETTING UP Illuminance SENSOR,
INFO:main:SETTING UP UV Index SENSOR,
INFO:main:SETTING UP Rain Today SENSOR,
INFO:main:SETTING UP Rain Yesterday SENSOR,
INFO:main:SETTING UP Rain Duration (Today) SENSOR,
INFO:main:SETTING UP Rain Duration (Yesterday) SENSOR,
INFO:main:SETTING UP Wind Lull SENSOR,
INFO:main:SETTING UP Wind Speed Avg SENSOR,
INFO:main:SETTING UP Wind Gust SENSOR,
INFO:main:SETTING UP Wind Bearing Avg SENSOR,
INFO:main:SETTING UP Wind Direction Avg SENSOR,
INFO:main:SETTING UP Battery TEMPEST SENSOR,
INFO:main:SETTING UP Solar Radiation SENSOR,
INFO:main:SETTING UP Precipitation Type SENSOR,
INFO:main:SETTING UP Last Rain start SENSOR,
INFO:main:SETTING UP Air Density SENSOR,
INFO:main:SETTING UP Dew Point SENSOR,
INFO:main:SETTING UP Rain Rate SENSOR,
INFO:main:SETTING UP Uptime SENSOR,
INFO:main:SETTING UP Feels Like Temperature SENSOR,
INFO:main:SETTING UP Visibility SENSOR,
INFO:main:SETTING UP Wet Bulb Temperature SENSOR,
INFO:main:SETTING UP Delta T SENSOR,
INFO:main:SETTING UP Dewpoint Comfort Level SENSOR,
INFO:main:SETTING UP Temperature Level SENSOR,
INFO:main:SETTING UP UV Level SENSOR,
INFO:main:SETTING UP Beaufort Scale SENSOR,
INFO:main:SETTING UP Weather SENSOR,
Traceback (most recent call last):,
File "/app/weatherflow_mqtt.py", line 499, in ,
asyncio.run(main()),
File "/usr/local/lib/python3.9/asyncio/runners.py", line 44, in run,
return loop.run_until_complete(main),
File "/usr/local/lib/python3.9/asyncio/base_events.py", line 642, in run_until_complete,
return future.result(),
File "/app/weatherflow_mqtt.py", line 180, in main,
condition_data, fcst_data = await forecast.update_forecast(),
File "/app/forecast.py", line 99, in update_forecast,
ATTR_FORECAST_CONDITION: await self.ha_condition_value(row["icon"]),,
KeyError: 'icon',
Ok, to begin with, I am not sure if this is an issue, a feature request, or just a plea for help.
On the HomeAssistant app for Mac, when the hourly forecast is presented it is offset by -5:00 hours. This only happens on the HA Mac app, not in safari, chrome, or the HA companion app on iOS or iPadOS. I am not sure when this started, but no matter what I try, it does not change. I have cleared, reloaded, reset, and re-installed, always the same result. However, if I switch to the rest sensors (SmartWeather integration) it works as expected.
The offset is as if it believes it is receiving a UTC date, and then converting to local time. (see attached screenshots)
The reason I am posting is that the only thing I can see that is different is how the time is represented in the forecast. e.g. the hourly forecast from weatherflow2mqtt represents the date string as '2021-06-10T11:00:00' whereas SmartWeather (and other weather entities) include the tz offset '2021-06-10T17:00:00+00:00'. I am not sure if this difference should even matter, nor do I understand why the translation is occurring only on the Mac application. But I can consistently reproduce the problem.
thoughts? TIA
The first two are from Safari browser, the second two are from the HA Companion Mac app.
Now that my lightning sensor is (mostly) working and have been able to monitor through a small storm, I have a request to add to your backlog for consideration. Apologies in advance, as I will be a bit long winded in and attempt am going to add detail around the my specific use-case. Two additional lightning count sensors:
And just FYI. I created a template sensor from the lightning_last_strike with relative_time() that when combined with the strike count gives a really good idea of if the storm is approaching or receding (they have this in the WeatherFlow app). I am also thinking of using that handy derivative sensor that Glenn pointed me towards to create a rising/falling type sensor.
Thanks
The following error comes up when selecting the title mentioned sensors homekit (HASS bridge).
Also both sensors are added in a HA history in a different section from all other "temperature" sensors (all measured in Celsius)
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/event.py", line 269, in _async_state_change_dispatcher
hass.async_run_hass_job(job, event)
File "/usr/src/homeassistant/homeassistant/core.py", line 433, in async_run_hass_job
hassjob.target(*args)
File "/usr/src/homeassistant/homeassistant/components/homekit/accessories.py", line 389, in async_update_event_state_callback
self.async_update_state_callback(event.data.get("new_state"))
File "/usr/src/homeassistant/homeassistant/components/homekit/accessories.py", line 411, in async_update_state_callback
self.async_update_state(new_state)
File "/usr/src/homeassistant/homeassistant/components/homekit/type_sensors.py", line 119, in async_update_state
temperature = temperature_to_homekit(temperature, unit)
File "/usr/src/homeassistant/homeassistant/components/homekit/util.py", line 367, in temperature_to_homekit
return round(temp_util.convert(temperature, unit, TEMP_CELSIUS), 1)
File "/usr/src/homeassistant/homeassistant/util/temperature.py", line 44, in convert
raise ValueError(UNIT_NOT_RECOGNIZED_TEMPLATE.format(from_unit, TEMPERATURE))
ValueError: ˚C is not a recognized temperature unit.
Periodically (somewhere between 20-40 minutes) the updates just freeze/stop to HA. A restart to the container and things return to normal for another 20-40 minutes. The container typically continues to run, and there are no errors in the logs. I ran with debug on and did not see anything that looked like it would cause a problem. And in fact, the logs continue to show processing updates. However, watching the traffic from MQTT explorer, no data was being published to HomeAssistant.
Then I noticed something odd in the Station Status data. It changed from Reset Flags: BOR,PIN,POR to Reset Flags: PIN,SFT,HRDFLT. The API does not address "HRDFLT" but have to guess that is hardware fault. The hub reboots, and things appear to continue, but from the MQTT and HA side nothing is happening.
Not sure what is causing the HRDFLT. I am going to monitor for a while without anything running to see if it is just a failure in the HW.
Anyway, sorry I can't give you more to go on. But if you have some troubleshooting steps you would like me to run, certainly happy to do so.
Twice last night my pressure sensor failed causing the container to restart. Not a huge deal but figured you would want to look at the error handling.
It doesn't happen often, but that particular sensor does periodically report failure. Best I can tell, it has happened four times total in the past two months. They came in pairs, one right after another. So really two incidents of two failures ~ 13 minutes apart. I wouldn't have noticed if I hadn't been checking status of another container this morning. Log entry of the first one attached:
Hi @briis,
This is just a minor one for the next build. I've noticed the lightning_strike_distance message is using an upper-case K in the unit of measurement. It should be a lower case.
Cheers
Simon
Hi guys
Just installed new image and ran docker and sensor.wf_rain_intensity not showing up not using a config file .....
Did i miss something else to set?
Thanks
Just a suggestion for a future enhancement I'm sure it is possible but if someone's willing to tackle it the ability to show current condition related to an icon like one the animated ones used in weather cards we could define them in the config this way not to infringe on any copyrights etc. and have the ability to use custom sets as you please
Of course taking into consideration Cloud Luxe temperature weather conditions as far as precipitation is concerned etcetera in real time
Regards
Robert
It would be convenient for setting up cards and for a 'maybe' better searching experience.
Having generic names for Humidity, Temperature, etc makes it difficult (sometimes) to find a sensor from this integration.
I realize that this would require fixing all instances in ones HA to the corrected sensor name.
That said, I think a prefix for the sensor names such as "wf" would be helpful. For example sensor.humidity would now be sensor.wf_humidity
The below are the only inputs allowed for HA weather condition. Currently this is pulled from the web API. I was toying with the idea of expanding my weather condition template to pull this locally. I understand I can't get the forecast local only; but I like as much self-hosted as possible. I think the only things I can't verify is clear-night, due to light conditions at night. Thoughts below:
‘clear-night’ can't check if fog at night since no light level to compare to (open to ideas)
‘cloudy’ can get a base line lux amount and compare and if not any other precipitation
‘fog’ same as cloudy but with window below a determined temperature
‘hail’ sensor for this
‘lightning’ sensor for this (maybe any number in last 3 hours)
‘lightning-rainy’ combine sensors for this
‘partlycloudy’ same as cloudy, with maybe a trend/derivative sensor to determine intermittent light levels
‘pouring’ above a certain rain rate
‘rainy’ sensor for this
‘snowy’ a little more complicated but maybe temperature combined with blocked UV sensor and rain sensor
‘snowy-rainy’ same as snowy but easier to assume around 0C / 32F
‘sunny’ easiest just base on UV/lux level
‘windy’ wind above a certain speed or gust above a certain speed
‘windy-variant’ not sure what this is checking
‘exceptional’ dewpoint between 50-60F, temperature between 68-77F, UV below 2.5 index, not any of the above (except sunny).
So...the actual point of this... should I make my condition template and then PR to the readme example or should we incorporate this to give another calculated sensor output? I'm leaning toward a sensor, but this would add a lot more code and wanted to run it past you before a PR without a big change with any other info. I would keep the current web api returned status as you have it and create some other named sensor. Thoughts?
If the MQTT broker goes offline for whatever reason, I'm noticing that weatherflow2mqtt does not attempt to auto-reconnect. I have to restart the weatherflow2mqtt Docker container for the publishing to pick back up. Even a quick restart on the MQTT broker will trigger this.
Pretty straight-forward to reproduce. Take down the MQTT broker for a second (I just restart its Docker container), and publishing will stop.
Note that I also don't see any logs from the weatherflow2mqtt container logs indicating a lost connection, which might also be helpful.
Hello,
Just capturing the issue as discussed over on the Weatherflow forum.
I tried to install hass-weatherflow2mqtt on Docker running on a Raspberry Pi, however it would not run due to incorrect architecture.
I followed the instructions posted by @briis over on the Weatherflow forum to build the container myself on the Pi. This worked well, and I got the add-on working.
Not wanting to stop there, I started to look into Docker a little more. The Pi I was using was a little overloaded but the one running HASS is an 8GB Pi4 - I found that Home Assistant OS essentially runs inside Docker, so I loaded up the Portainer community add-on to access the HA Docker environment.
With some back-and-forth I have managed to get hass-weatherflow2mqtt running inside Docker directly on the HA Raspberry Pi.
I've still got some tweaking to do, but I'll document the steps here.
Cheers
Simon
I have hit over 100F in the last few days but:
attribution: Powered by WeatherFlow2MQTT
brand: WeatherFlow
max_day: '98.8'
max_day_time: '2021-06-26T22:40:23+00:00'
max_month: '83.3'
max_month_time: '2021-06-26T01:28:46+00:00'
max_all: '83.3'
max_all_time: '2021-06-26T01:28:46+00:00'
min_day: '63.2'
min_day_time: '2021-06-26T12:36:55+00:00'
min_month: '52.0'
min_month_time: '2021-06-24T12:41:06+00:00'
min_all: '47.9'
min_all_time: '2021-06-19T12:19:07+00:00'
unit_of_measurement: ˚F
friendly_name: WF Temperature
device_class: temperature
Max all time and max month are less than max day, and max day is not updating.
Looks like the actual max for yesterday was 108.1F
Min does not match either
Do you think it would be beneficial if you have a docker build for testing that is not in the latest? This would allow some of us to test changes before it is released in to the latest and also to easily fall back if it doesn't work.
Or you could do the testing under latest as it would be the latest and have a stable tag for the good release before and move latest to stable once there is feedback on the latest.
The sea_level_pressure sensor values are not consistent with the Tempest app or with the SmartWeather integration sensor values. However, the station_pressure is consistently reported in all (for the most part anyway, it is hard to capture a snapshot of everything at exactly the same time).
Tempest app: 29.997 inHg 29.149 inHg
Smartweather: 29.997 inHg 29.149 inHg
weatherflow2mqtt: 29.941 inHg 29.15 inHg
This is relating to the new battery percentage that was added in #63. I understand the battery calculation for Tempest is set with a maximum of 2.8V. However per Weatherflow, the ideal operating range of the battery is actually 2.55V which is 75% of max capacity (https://help.weatherflow.com/hc/en-us/articles/360048877194-Solar-Power-Rechargeable-Battery).
I had a lot of confusion wondering why my device wouldn't charge above ~75% until I read this.
I just wanted to open a discussion about an option to help avoid this confusion. Maybe a separate sensor that reports the operating mode would be an easy solution. Tempest gives the operating ranges on that page where the top mode ("Mode 0") is Voltage>=2.455. I think this could be more useful information than a percentage.
Only sensor I am missing from the SmartWeather integration. TIA for considering the feature.
This can be done with the visibility_template in the weather template or you could calculate with the given station height.
This formula is for good weather, so it would be an absolute maximum visibility distance.
Later with better fog prediction, this can be dynamic instead of a set number; just trying to lay the ground work.
1.22459 * sqrt (height in feet above sea level) = Distance to the horizon in nautical miles
using 1.2 will yield good accuracy also
3.56972 * sqrt (height in meters above sea level) = Distance to the horizon in km
using 3.6 will yield good accuracy also
I can go ahead and add this in the readme with the caveat that it is the max possible and at does not change with actual conditions if you don't want to calculate it in the integration.
For example my visibility for 335 ft above see level would be:
visibility_template: "22.4"
The weather card I use "Animated Weather Card" has a place for visibility and I didn't like a blank there, so I put in a placeholder value of my visibility to the horizon.
This would make the setup easier for lots of use cases.
probably a minimal wrapper script would be needed that would check for the config and copy it in case it does not exist. Then execute the python script.
Or you add sensible defaults in case the file does not exist in python itself - the relevant method returns None right now, so change that to return the default structure.
Had a small storm pass overnight and this morning found two things. First is that weatherflow2MQTT restarted a couple of times, both apparently due to a pressure sensor fault. This was followed by an error that "Pressure value was reported as NoneType" (see log screenshot below for details)
Second is that weatherflow2MQTT did not record any lighting data, while both smartweather (REST api) and the app recorded several events. Could be that I have an issue on the Tempest device. I do get many "Lightning Disturber" events through the UDP interface. I know that WeatherFlow does do some processing and perhaps what I am seeing is info collected from other devices, but I thought the the REST api included the raw lightning data. Anyway, would appreciate information regarding the Lightning Disturber events, and perhaps confirmation that others are not having issues.
Hi !
It would be great to have two additional sensors, one for the hub and one for the device, each with the available attributes.
Examples
Status (device) [type = device_status]
{
"serial_number": "AR-00004049",
"type": "device_status",
"hub_sn": "HB-00000001",
"timestamp": 1510855923,
"uptime": 2189,
"voltage": 3.50,
"firmware_revision": 17,
"rssi": -17,
"hub_rssi": -87,
"sensor_status": 0,
"debug": 0
}
Status (hub) [type = hub_status]
{
"serial_number":"HB-00000001",
"type":"hub_status",
"firmware_revision":"35",
"uptime":1670133,
"rssi":-62,
"timestamp":1495724691,
"reset_flags": "BOR,PIN,POR",
"seq": 48,
"fs": [1, 0, 15675411, 524288],
"radio_stats": [2, 1, 0, 3, 2839],
"mqtt_stats": [1, 0]
}
fs
and mqtt_stats
seems to be for internal use, not sure if they would make any sense here.
reset_flags values
Value | Description |
---|---|
BOR | Brownout reset |
PIN | PIN reset |
POR | Power reset |
SFT | Software reset |
WDG | Watchdog reset |
WWD | Window watchdog reset |
LPW | Low-power reset |
HRDFLT | Hard fault detected |
radio_stats values
Index | Field |
---|---|
0 | Version |
1 | Reboot Count |
2 | I2C Bus Error Count |
3 | Radio Status (0 = Radio Off, 1 = Radio On, 3 = Radio Active, 7 = BLE Connected) |
4 | Radio Network ID |
Thanks !
Regards,
Originally posted by Vertikar September 14, 2021
Would be great to be able to have the new long-term stats feature ( https://www.home-assistant.io/blog/2021/09/01/release-20219/#long-term-statistics-unlocked-for-all-sensors ) available for the weather data from weatherflow - dev details here: https://developers.home-assistant.io/docs/core/entity/sensor/#long-term-statistics
I can see zigbee2mqtt is already exposing this, looks like it'd be added to the autodiscovery.
Just FYI.
This afternoon, noticed that the daily forecast from the SmartWeather integration dropped out, loosing the forecast and related sensors. I initially didn't notice the same drop from weatherflow2mqtt, but after looking at the container, it did drop and the container had to restart, although I have it set to do so automatically. All in all, it recovered much quicker, but did require a restart.
This was clearly an issue on the WeatherFlow end as it happened to both simultaneously. But oddly, didn't appear to have any effect on the hourly version of the SmartWeather or weatherflow2mqtt data.
This is a way to show heat stress on the human body.
I have already started working on this.
Need to estimate Black Globe Temperature, some methods would require sun azimuth. I know Astral library can do this but I'm looking into other ways, but may still end up with Astral.
https://www.weather.gov/tsa/wbgt
Since a database is being implemented, have you considered logging Highs/Lows.
High/Low for
Temperature
Humidity
DewPoint
Illuminance
Rain Duration (just highest)
Rain Rate (just highest)
Wind Gust (high)
Wind Lull (high)
Wind Speed (high)
Lightning Energy
Lighting Count
Sea Level Pressure
UV Index
Solar Radiation
(ok, pretty much everything)
The high lows could be for the week (last 7 days) / month (last 30 days) / year (last 366 days, account for leap years) and maybe of all time.
And maybe some sort or reset. I am specifically thinking of lightning info since my lightning sensor has gone crazy is thousands of reported strikes a day.
Maybe more trends also, such as rain increasing/subsiding or wind. Sea Level Pressure trend is already in work.
Hello
I 've tried to run the container on a raspberry pi and created the following docker-compose file:
version: "3.8"
services:
wf2mqtt:
image: briis/weatherflow2mqtt:latest
container_name: wf2mqtt
environment:
- TZ=Europe/Athens
- TEMPEST_DEVICE=false
- UNIT_SYSTEM=metric
- LANGUAGE=en
- RAPID_WIND_INTERVAL=0
- DEBUG=False
- ELEVATION=0
- WF_HOST=0.0.0.0
- WF_PORT=50222
- MQTT_HOST=192.168.1.10
- MQTT_PORT=1883
- MQTT_USERNAME=user
- MQTT_PASSWORD=pass
- MQTT_DEBUG=False
- ADD_FORECAST=False
- STATION_ID=
- STATION_TOKEN=
- FORECAST_INTERVAL=30
volumes:
- ./config:/usr/local/config
ports:
- 0.0.0.0:50222:50222/udp
restart: unless-stopped
this is the log output:
Creating wf2mqtt ... done
Attaching to wf2mqtt
wf2mqtt | DEBUG:asyncio:Using selector: EpollSelector
wf2mqtt | INFO:weatherflow2mqtt.weatherflow_mqtt:Timezone is Europe/Athens
wf2mqtt | Traceback (most recent call last):
wf2mqtt | File "/usr/local/bin/weatherflow2mqtt", line 33, in <module>
wf2mqtt | sys.exit(load_entry_point('weatherflow2mqtt==0.10.0', 'console_scripts', 'weatherflow2mqtt')())
wf2mqtt | File "/usr/local/lib/python3.9/site-packages/weatherflow2mqtt-0.10.0-py3.9.egg/weatherflow2mqtt/__main__.py", line 10, in main
wf2mqtt | File "/usr/local/lib/python3.9/asyncio/runners.py", line 44, in run
wf2mqtt | return loop.run_until_complete(main)
wf2mqtt | File "/usr/local/lib/python3.9/asyncio/base_events.py", line 642, in run_until_complete
wf2mqtt | return future.result()
wf2mqtt | File "/usr/local/lib/python3.9/site-packages/weatherflow2mqtt-0.10.0-py3.9.egg/weatherflow2mqtt/weatherflow_mqtt.py", line 60, in main
wf2mqtt | File "<string>", line 1, in <module>
wf2mqtt | NameError: name 'false' is not defined
Hi again !
It seems that the DEBUG env var is not used everywhere to display or not information through _LOGGER.debug
.
As an example 377 is not testing the show_debug
var.
Thanks !
Kind regards,
I changed nothing and will not start ? thank you in advance....
DEBUG:weatherflow2mqtt.weatherflow_mqtt:Skipping Forecast sensor False weather
Traceback (most recent call last):
File "/usr/local/bin/weatherflow2mqtt", line 33, in
sys.exit(load_entry_point('weatherflow2mqtt==2.2.1', 'console_scripts', 'weatherflow2mqtt')())
File "/usr/local/lib/python3.9/site-packages/weatherflow2mqtt-2.2.1-py3.9.egg/weatherflow2mqtt/main.py", line 10, in main
File "/usr/local/lib/python3.9/asyncio/runners.py", line 44, in run
return loop.run_until_complete(main)
File "/usr/local/lib/python3.9/asyncio/base_events.py", line 642, in run_until_complete
return future.result()
File "/usr/local/lib/python3.9/site-packages/weatherflow2mqtt-2.2.1-py3.9.egg/weatherflow2mqtt/weatherflow_mqtt.py", line 378, in main
TypeError: cannot unpack non-iterable NoneType object
DEBUG:asyncio:Using selector: EpollSelector
I've noticed that after restarting Home Assistant, many values are unknown until the next update for those values, sometime I've notice that might be a while. For instance:
Is it possible to retain
these messages so that Home Assistant shows some data in this case? Or am I doing something wrong here?
With the last update I do not get any obs_sky messages to MQTT.
I appear to have everything else but since the actual data is all in obs_sky, I don't have much into HA.
Looks like it is related to my last PR. I passed temp and dewpoint_c so I'm not sure what happened.
DEBUG:weatherflow2mqtt.weatherflow_mqtt:Event type device_status has been processed, with payload: {}
Traceback (most recent call last):
File "/usr/local/bin/weatherflow2mqtt", line 33, in <module>
sys.exit(load_entry_point('weatherflow2mqtt==0.10.0', 'console_scripts', 'weatherflow2mqtt')())
File "/usr/local/lib/python3.9/site-packages/weatherflow2mqtt-0.10.0-py3.9.egg/weatherflow2mqtt/__main__.py", line 10, in main
File "/usr/local/lib/python3.9/asyncio/runners.py", line 44, in run
return loop.run_until_complete(main)
File "/usr/local/lib/python3.9/asyncio/base_events.py", line 642, in run_until_complete
return future.result()
File "/usr/local/lib/python3.9/site-packages/weatherflow2mqtt-0.10.0-py3.9.egg/weatherflow2mqtt/weatherflow_mqtt.py", line 305, in main
TypeError: visibility() missing 2 required positional arguments: 'temp' and 'dewpoint_c'
DEBUG:asyncio:Using selector: EpollSelector
I converted the docker run to docker-compose format. I can add it to the Readme with a PR or save it as a docker-compose.yml file if you want? Here are the details:
version: '2' services: weatherflow2mqtt: image: ghcr.io/briis/hass-weatherflow2mqtt:latest restart: unless-stopped environment: - TZ=America/Los_Angeles - TEMPEST_DEVICE=True - UNIT_SYSTEM=imperial - LANGUAGE=EN - RAPID_WIND_INTERVAL=0 - DEBUG=False - ELEVATION=0 - WF_HOST=0.0.0.0 - WF_PORT=50222 - MQTT_HOST= - MQTT_PORT=1883 - MQTT_USERNAME= - MQTT_PASSWORD= - MQTT_DEBUG=False - ADD_FORECAST=True - STATION_ID= - STATION_TOKEN= - FORECAST_INTERVAL=30 volumes: - /YOUR_STORAGE_AREA/PATH:/usr/local/config ports: - 0.0.0.0:50222:50222/udp
Let me know if you want me to do a PR for this?
I was just taking a look at the .storage.json file to add some real-world values for last rain start and last lightning to clear the 1970 date from HA. I noticed there that one is stored as ISO time/date and the other is epoch - not sure if there a reason for this?
The lightning_strike_time topic has the name "Last Lightning Today". I think "Today" can be removed from this. The sensor table doesn't say this is reset every day at midnight.
Cheers
Simon
Thanks for all the work! I just got a Tempest in the UK yesterday (early access program) and have implemented weatherflow2mqtt into my existing flow with zero issues.
So this is a query/request rather than an issue: have you considered allowing using an external database - I am thinking influxdb - rather than (or as well as) the internal one for data storage?
The advantage of this would be to allow the data to be used for other purposes (like this for data display, which is more flexible that HA). I did look in to the possibility of having multiple containers listen on 50222 but that looks like a non-starter. As a stop-gap I am exporting to influx from HA, but I would rather avoid the intermediate step and possibly use the existing Grafana dashboards that have already been created
DEBUG:__main__:DEVICE STATUS TRIGGERED AT 2021-07-05 11:55:28.313845
-- Device: ST-00028410
-- Firmware Revision: 156
-- Voltage: 2.75
DEBUG:asyncio:Using selector: EpollSelector
DEBUG:asyncio:Using selector: EpollSelector
Traceback (most recent call last):
File "/home/tcohen/perso/gits/github.com/briis/hass-weatherflow2mqtt/weatherflow_mqtt.py", line 499, in <module>
asyncio.run(main())
File "/usr/lib/python3.9/asyncio/runners.py", line 44, in run
return loop.run_until_complete(main)
File "/usr/lib/python3.9/asyncio/base_events.py", line 642, in run_until_complete
return future.result()
File "/home/tcohen/perso/gits/github.com/briis/hass-weatherflow2mqtt/weatherflow_mqtt.py", line 361, in main
device_status = await cnv.device_status(sensor_status)
File "/home/tcohen/perso/gits/github.com/briis/hass-weatherflow2mqtt/helpers.py", line 394, in device_status
return_value.append(DEVICE_STATUS[len(binarr)-x])
IndexError: list index out of range
I run it locally and in docker, I got the same error.
I was able to run a pdb to know the value of some variables:
binarr: '100000000000000000'
DEVICE_STATUS: ['Sensors OK', 'lightning failed', 'lightning noise', 'lightning disturber', 'pressure failed', 'temperature failed', 'rh failed', 'wind failed', 'precip failed', 'light/uv failed']
return_value: []
value: 131072
x: 0
len(binarr)-x: 18
Note: Hub firmware release: 170
So I guess something is missing in the DEVICE_STATUS
list ?
Hello @briis
Would you be willing to accept a PR which refactors the structure of the repo to use python setup tools ?
It will help to manage dependencies and add some unit tests
Last night Weatherflow2MQTT reported several lightning strikes, but on the tempestwx.com site and in the Android app there are no reported lightning strikes. It was clear skies and absolutely no chance of lightning in the area. Is it that Weatherflow2MQTT reads the raw data which includes electromagnetic noise and not filtered data from the Tempest service?
This can be on the bottom of the list but due to the way Home Assistant displays MQTT integrations it assumes there is a battery that is reported in percentage, and it means more at a first look than the voltage alone.
For now I am ignoring the operating modes of the tempest based on battery voltage, although I can see setting a if...then for percentage if it is in the range of each mode.
Battery range is 1.8 to 2.85Vdc
Anything > 2.85 is capped at 100%
Anything < 1.8 is capped at 0%
P = (V - 1.8)/1.05
where:
P is percentage
V is battery voltage
This is a very simple calculation but can be estimated to be simplified more and is still fairly accurate to either:
P = V - 1.8 or P = V - 1.85
either is within an acceptable range between them.
The first of the three is the most accurate but any are acceptable
I don't know how to pull in to helpers.py so I set 50% of it up and let you take care of the MQTT bit also. I'm sure if I looked around the code enough I could figure it out but I also don't want to step on your toes by introducing names outside of what you want for naming conventions.
Hi !
Thanks for the great work on this docker !
I have the following error coming in the log: DEBUG:weatherflow2mqtt.weatherflow_mqtt:Device XXX has reported a sensor fault. Reason: ['wind failed']
I'm not sure what it means as the wind sensor is correctly reporting the information.
Kind regards,
Just a quick point we live in south Florida system says hail when it is heavy rain ,,,
I don't normally look at Delta T, so I don't know when it went wonky.
Per HA the delta T is -43.2F which is impossible (under most conditions), and the app reports 9.7F.
I don't know if this is limited to just us non-metric users or if this is an issue for metric also.
Air Temp, Wet Bulb Temp, Dew Point, Humidity all track, so it appears to be a calculation in Delta T.
Documenting for now, I will look at the code after I change out some light switches.
For some reason sensors I have created for describing dewpoint comfort level keep progressing the number at the end of the sensor id during most Home Assistant updates lately. For example sensor.dewpoint_description after a update (of HA) will be sensor.dewpoint_description_2. This is not an issue with this component but a Home Assistant issue; however, including the description in the integration will save me time from having to change the same in all of my cards which can be cumbersome. I currently have this pulled from my PurpleAir sensor and was going change it over the WeatherFlow sensors but I've had this issue with of few of my sensors that are created from other sensor, so it would be of benefit (me) to include them here. Some components below don't apply but include for completeness. I think I have include enough information. Values below are in degrees fahrenheit. I utilize the descriptions for notifications and some button cards.
Dewpoint Comfort Level Description:
purpleair_dewpoint_description:
friendly_name: 'Outside Dewpoint Comfort Level'
value_template: >
{% if (states('sensor.purpleair_dewpoint')|float) >= 80.0 %}
Severely High
{% elif (states('sensor.purpleair_dewpoint')|float) >= 75.0 %}
Miserable
{% elif (states('sensor.purpleair_dewpoint')|float) >= 70.0 %}
Oppressive
{% elif (states('sensor.purpleair_dewpoint')|float) >= 65.0 %}
Uncomfortable
{% elif (states('sensor.purpleair_dewpoint')|float) >= 60.0 %}
Ok for Most
{% elif (states('sensor.purpleair_dewpoint')|float) >= 55.0 %}
Comfortable
{% elif (states('sensor.purpleair_dewpoint')|float) >= 50.0 %}
Very Comfortable
{% elif (states('sensor.purpleair_dewpoint')|float) >= 30.0 %}
Somewhat Dry
{% elif (states('sensor.purpleair_dewpoint')|float) >= 0.5 %}
Dry
{% elif (states('sensor.purpleair_dewpoint')|float) <= 0.0 %}
Very Dry
{% else %}
undefined
{% endif %}
entity_id: sensor.purpleair
availability_template: '{{ not is_state("sensor.purpleair", "unavailable") }}'
Very Comfortable and Pleasant have been used interchangeably.
Temperature description:
purpleair_temperature_description:
friendly_name: 'Outside Temperature Level'
value_template: >
{% if (states('sensor.purpleair_temp_2')|float) >= 104.0 %}
Inferno
{% elif (states('sensor.purpleair_temp_2')|float) >= 95.0 %}
Very Hot
{% elif (states('sensor.purpleair_temp_2')|float) >= 86.0 %}
Hot
{% elif (states('sensor.purpleair_temp_2')|float) >= 77.0 %}
Warm
{% elif (states('sensor.purpleair_temp_2')|float) >= 68.0 %}
Nice
{% elif (states('sensor.purpleair_temp_2')|float) >= 59.0 %}
Cool
{% elif (states('sensor.purpleair_temp_2')|float) >= 41.0 %}
Chilly
{% elif (states('sensor.purpleair_temp_2')|float) >= 32.0 %}
Cold
{% elif (states('sensor.purpleair_temp_2')|float) >= 20.0 %}
Freezing
{% elif (states('sensor.purpleair_temp_2')|float) <= 20.0 %}
Fridged
{% else %}
undefined
{% endif %}
entity_id: sensor.purpleair
availability_template: "{{ sensor.purpleair }}"
I don't have a sensor setup of UV descriptions yet, but those are easy:
Low 0 - 2.5
Moderate 2.5 - 5.5
High 5.5 - 7.5
Very High 7.5 - 10.5
Extreme 10.5 - 13
this error is coming up
have
forecast = true
Error parsing value: 'value_json' is undefined (value: off, template: {{value_json.state}})
7:56:16 AM – (ERROR) helpers/template.py - message first occurred at 7:56:15 AM and shows up 200 times
Template variable error: 'value_json' is undefined when rendering '{{value_json.state}}'
7:56:16 AM – (ERROR) helpers/template.py - message first occurred at 7:56:15 AM and shows up 200 times
I am trying this container with my old SKYs and AIRs and I can get the observations ok.
But I have registered on my hub, 3 SKYs and 2 AIRs but the MQTT topic obs_sky
rapid_wind
and obs_air
report the values of all these devices on the same topic. So I can not know what device reports what.
I think that it would be good to report on each of the above topics, the device id among the observation data.
Unit of measurement for temperature should be °C and not ˚C. The difference is a problem for exempel when using min/max-sensors as the unit of measurement for the wf-sensor isn't the same as for other temperature sensors in HA.
I have cleared and recreated several times both the container and the MQTT integration in HA. Each time I only get 20 sensors discovered and set up in HA. Looking at the logs there is nothing remarkable, even with debug on. From MQTT explorer, I see the "forecast" topic with what appears to be good data in the state and attributes. There is not a "feelslike" topic, however, there is a "obs_air" topic that contains the feels like information in the "state" along with other information. For whatever reason, the information is passed through MQTT server, but HA does not discover or update the information in these sensors.
Information that is contained in either the "obs_air" or "obs_sky" topic but does not have unique topic of its own nor does it get discovered by the MQTT integration (hopefully I got them all):
feelslike
air_density
lightning_strike_time
dewpoint
battery
rain_rate
precipitation_type
rain_start_time
solar_radiation
wind_gust
wind_bearing_avg
The sensors successfully created are:
sensor.humidity
sensor.illuminance
sensor.last_lightning_today
sensor.lightning_count_3_hours
sensor.lightning_count_today
sensor.lightning_distance
sensor.lightning_energy
sensor.rain_duration_today
sensor.rain_duration_yesterday
sensor.rain_today
sensor.rain_yesterday
sensor.sea_level_pressure
sensor.station_pressure
sensor.temperature
sensor.uv_index
sensor.wind_bearing
sensor.wind_direction
sensor.wind_lull
sensor.wind_speed
sensor.wind_speed_avg
Thanks
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.