As with some other not actively up dated add-ons I’ve tried, I also could add your repository on current version of Hass.io. Not a big deal as it’s just as easy to manually install it but it would be nice if you could update it so it can be added.
After manually installing I get error while setting up platform, I believe this is also likely due to me running the latest version of Hass.io. I did have to modify the senor.py for another add-on but that was just to get it pointed at the proper location for the configuration.yaml.
Here’s the details on the error:
Error while setting up platform smartweatherudp
Traceback (most recent call last):
File “/usr/src/homeassistant/homeassistant/helpers/entity_platform.py”, line 150, in _async_setup_platform
await asyncio.wait_for(asyncio.shield(task), SLOW_SETUP_MAX_WAIT)
File “/usr/local/lib/python3.7/asyncio/tasks.py”, line 442, in wait_for
return fut.result()
File “/usr/local/lib/python3.7/concurrent/futures/thread.py”, line 57, in run
result = self.fn(*self.args, **self.kwargs)
File “/config/custom_components/smartweatherudp/sensor.py”, line 71, in setup_platform
module = SWReceiver(config.get(CONF_HOST), DEFAULT_PORT, unit_system)
File “/usr/local/lib/python3.7/site-packages/pysmartweatherudp/receiver.py”, line 34, in init
self._socket.bind((host, port))
OSError: [Errno 99] Address not available
Hi
As I said earlier unfortunately I don’t have access to my station locally at the moment, so it is hard for me to make and test changes.
But with that said, the error you are seeing I have seen before if there is another UDP listener running on the same IP address. I believe there is a way around this, by setting some options on the listener, but unfortunately it will take some month before I can play around with it.
OK, I might be able to get it going on my set up then w/o you changing any thing with my current setup.
I had added discovery to my configuration to make sure Hass.io found everything and it’s what’s currently the other UDP listener. I’ll remove that since it’s not needed any more and give it another try.
I may setup WeeWX on this same system in a Docker install which will put me back with a UDP listener on the same IP again. At that point I may just use MQTT sensors for my weather flow but at this point I’m having issues with other MQTT sensors updating status changes even though I can see Hassio is receiving the topics.
In other words I may need to use another solution like yours, so if you can fix this UDP issue that would be great.
BTW, I’m currently running your rest version and maybe this is because I setup the Dark Sky forecast but I thought all the sensor would be grouped into a card. All of mine are the top and the card for the forecast does seem to use the data from my station for 4 sensors. I was going to try and make a group with them but they don’t show the senor names when I open them, but from looking at the senor.py I think I’ve figured out each senors name but haven’t tried yet (I figured I’d wait until I get the UDP version working and worry about this if need).
Edit: I tried it again now that Hassio isn’t actively listening to UPD to descover devices and can’t think of any thing else that would also.
Hi again,
I am not a big expert on socket programming, but from what I can find the following line will make a non-blocking listner: my_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) and this is already part of the pysmartweatherudp that is a requirement for this Integration.
As I said I don’t have the station up and running currently, so I have a problem testing. But my best guess is still that there is another program running without SO_REUSEADDR in the program and thus blocking communication.
@briis This is especially problematic if you are using HA StateStream, as each MQTT topic gets updated every 3s as well - causing a LOT of unnecessary MQTT traffic (as in THOUSANDS of extra messages per minute).
It would be much better if the sky/air updates updated once a minute, and only the rapid_wind data updated at the high frequency.
I see your point and just browsed through the code again (it’s been a while). It will require a major rewrite, in order to achieve this. I currently don’t have the Weatherflow systems up and running, as I am in between houses, but will look at it as soon as I have moved (6 weeks).
Also if anyone else would like to give it go, please reach out, I am happy to give access.
Sorry to jump in on an older thread, but I’ve just installed your custom component. First off, thanks for your efforts on this!
I am apparently connecting to my station, however, all of the sensors are reading 0 (temp, humidity, etc.). Log file does not show any errors. I’ve read through the instructions several times now and verified my setup… Any ideas on what I might be happening?
Hi @whitwhittle
I am no longer maintaining this component as I don’t have the HW anymore. But let me see if I can help.
Could you post your configuration from configuration.yaml ?
Also, are do you have any other program running on the same server that listens to UDP broadcasts? If yes, could you try to stop that, and see if it works then.
Hello, I just started to read this and I will give a try to that custom component when I received my Tempest. Fingers crossed, I hope this will work !!
But I realised that you just said that you dont have de HW anymore. Can you tell me why ? And I curious… did you replace it with something else to work with home assistant ?
The solar panel kept dying due to not enough sun in the winter month here in Denmark. And also I found that the AIR unit just had a very bad battery life, so I had to replace the batteries every month (at least) even though I used the High Quality and very expensive batteries. I did not order a Tempest unit, but I really hope that these are better than the AIR & SKY units I had.
With that said, I really liked the concept, the price, the flexibility and the well documented API etc. So if the Tempest unit can survive a Winter in the Northern Part of the hemisphere, I might buy one.
I already had a Davis Vantage VUE station. Even though that is not as advanced as the SKY&AIR combined, it is extremely reliable. I hooked it up to a Meteobridge NANO logger, and this just runs 24/7/365.
I’m in Quebec, Quebec, Canada, our winter are like yours, so I’ll keep you in touch !
I was looking for something like a Davis Vantage too before I found the Tempest.
My problem was all the little piece that need to rotate… I was wondering, does they get stick in the snow or icy rain ?
No I never seen any moving parts getting stuck, even with very hard frost or a lot of snow. But the price tag on the Davis products are also a lot higher then the ones from WeatherFlow and when my station was running I found it to be pretty accurate, so price/value is very high. As said I might still buy a Tempest, as I would like the UV and Solar sensors.
I had an issue with the solar panel not working in winter and contacted support.
They told me that the 1st gen of the panel didn’t work below freezing and sent me a replacement panel and it worked fine for the rest of the winter.
That aside has anyone had issues with this component after 0.108.6? I being short on time went from 0.108.6 to 0.110.1 and now it doesn’t work at all.
Log Details (ERROR)
Logger: homeassistant.config
Source: custom_components/smartweatherudp/sensor.py:8
First occurred: 5:46:42 PM (1 occurrences)
Last logged: 5:46:42 PM
Platform error: sensor
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config.py", line 777, in async_process_component_config
platform = p_integration.get_platform(domain)
File "/usr/src/homeassistant/homeassistant/loader.py", line 273, in get_platform
f"{self.pkg_path}.{platform_name}"
File "/usr/local/lib/python3.7/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "<frozen importlib._bootstrap>", line 1006, in _gcd_import
File "<frozen importlib._bootstrap>", line 983, in _find_and_load
File "<frozen importlib._bootstrap>", line 967, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 677, in _load_unlocked
File "<frozen importlib._bootstrap_external>", line 728, in exec_module
File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
File "/config/custom_components/smartweatherudp/sensor.py", line 8, in <module>
from homeassistant.const import (ATTR_ATTRIBUTION, CONF_MONITORED_CONDITIONS,
ImportError: cannot import name 'UNIT_UV_INDEX' from 'homeassistant.const' (/usr/src/homeassistant/homeassistant/const.py)
EDIT--------
Also see this when the UV sensor is in configuration.yaml
Configuration invalid
Platform error sensor.smartweatherudp - cannot import name 'UNIT_UV_INDEX' from 'homeassistant.const' (/usr/src/homeassistant/homeassistant/const.py)
yes pull down the most recent version it should fix this, I caught this in the beta of 0.109 and figured out the fix and sent in a PR that is now merged.
When I first installed this, I got the error described above:
Platform error sensor.smartweatherudp - cannot import name 'UNIT_UV_INDEX' from 'homeassistant.const' (/usr/src/homeassistant/homeassistant/const.py)
It looks like that was supposed to be fixed in 0.1.6, but for some reason installing via HACS didn’t actually give me those changes. I went and manually modified sensor.py and then it worked.
I was trying to enter the IP address of my station, which is DHCP Reserved (Static), but that didn’t seem to work. I got errors about not being able to connect in my logs. Once I removed the host property entirely (allowed it to just find the station itself), everything booted up and seemed to work.
Upon further inspection of the different sensors though, it seems like some of them are doing something weird – the following sensors all read as 32, which doesn’t make any sense. It’s currently 91 degrees fahrenheit where I am:
dewpoint
feels_like
heat_index
temperature
wind_chill
I am seeing that the sensors are updating (e.g. wind_speed_realtime), so it’s “working” but something is messed up around these sensors. Possibly related to me manually making the changes in the link above?
I reinstalled from master and it appears to have the correct code now. I’m still seeing the issue with the value of 32 coming up for “everything” though.
I am using one of the new Tempest devices, so I wonder if things are different?
I just noticed that the sensors that are showing as 32 are all DEVICE_CLASS_TEMPERATURE.
It looks like based on their UDP docs, the format of observation data is different for Tempest vs Sky devices, so I’m guessing that’s part of the issue, but I haven’t actually figured out exactly how this all works, and I’ve never worked properly with Python or UDP, so… I guess it’ll be an adventure.