briis/hass-weatherflow2mqtt

WeatherFlow to MQTT for Home Assistant. Use UDP to get local weather data in to Home Assistant using MQTT Discovery

hass-weatherflow2mqtt's Issues

reported a sensor fault. Reason: ['lightning disturber'] system fault

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',

Odd behavior of forecast on HA mac

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.

Additional Lightning Sensors

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:

1. lightning_count - Despite the description in the SmartWeather readme, in my implementation this sensor represents the number of strikes within 1 minute. This turned out to be my favorite of the lightning count sensors in SmartWeather. It gives a quick indicator of the intensity of the storm and a general read if it is increasing or decreasing.
2. lightning_count_last_1hr - For me, the 3hr increment is just too long. I am sure it is different in other climates, but our storms come and go pretty quickly and many times in multiple waves. Also, lightning strikes are numerous in those periods. So I will get 60 strikes in just a few minutes, then the sky clears, sun comes out for a while, then the next storm cell comes through.. or not. Net is that the 1hr increment feels more indicative of what is happening; sort of a compromise. BTW, if I only get one, it would most definitely be the 1 minute resolution.

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

temperature & feels like temperature sensors don't work when exported in homekit

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.

Sea Level Pressure

when comparing the HA smartweather integration to this (and the regular pressure) a sea level pressure of 5.88 hPa is not possible. is there some conversion happening ?

Error with Temperature Description

Just updated to the latest and realized I was not getting any updates. Found these in my logs...

Periodic freeze of sensor updates

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.

Container constantly restarting keyerror: 'icon'

Just started a little bit ago on latest version. Anyone else? It doesn't like something.

Keyerror 'Icon' caused container to restart

Found a series of these in my logs, all 9-20 seconds apart, causing the container to restart. Seems to have subsided for now. Perhaps it found a condition that it did not anticipate. Unfortunately I don't have any more information to offer.

Pressure sensor fail caused restart

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:

lightning_strike_distance unit change Km to km

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

sensor.wf_rain_intensity` not showing

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

Current condition Icons

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

Sensor Naming Convention

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

Weather Condition generating locally

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?

Does not auto-recover when MQTT broker goes offline

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.

Unable to install on ARM architecture (Raspberry Pi in my case)

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

Max/Min attributes not updating

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

Consider a testing Docker tag

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.

Potential issue with sea level pressure calculation

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

Tempest battery percentage / operating mode

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.

Feature Request - Add Pressure Trend

Only sensor I am missing from the SmartWeather integration. TIA for considering the feature.

Visibility Calculation

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.

Can you autocreate the config.yml in case it does not exist?

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.

Pressure sensor fault and no lightning data

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.

Thanks

Request: sensor for hub and device

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,

Add state_class to entities to allow long-term statistics to be collected

Discussed in #80

^{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.

Container restarted on daily forecast unavailable

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.

Snap of the logs below.

add Wet Bulb Glob Temperature (WBGT)

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

Possible storage values

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.

container error: NameError: name 'false' is not defined

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

Request: use DEBUG env var

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,

Changed nothing and now I get error as below any thoughts

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

Retain all states?

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?

No obs_sky messages

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

Add docker-compose details

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?

lightning_strike_time topic name

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

External database

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

Error collecting device status

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 ?

Repo structure refactoring (add setuptools)

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

False lightning strikes

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?

add battery percentage

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.

Device has reported a sensor fault. Reason: ['wind failed']

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,

hail and heavy rain

Just a quick point we live in south Florida system says hail when it is heavy rain ,,,

Delta T off

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.

Dewpoint Comfort & Temperature Description

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

Newst build Docker on linux, arm64 home assint

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

Same topic for multiple devices.

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.

Wrong unit of measurement for temperature

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.

Not all sensors discovered by 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