[SOLVED] Weatherflow Smart Weather Station binding

Curtis · January 14, 2021, 8:58am

For those wanting to get their Tempest weather station working in OH3. This is the method I used and it works perfectly.

Initial device setup on https://tempestwx.com/
Setup an account on https://www.wunderground.com/ add your station to the devices section. This will give you a code that you can enter in https://tempestwx.com/
Go back to https://www.wunderground.com/ and check the weather station is online in the devices section.
Go to the API Keys section and create the key (expires every 6 months which is disappointing)
Install the Weather Company Binding and add the account thing and copy the API key into it, add the other things and that’s it!

Works perfectly:

sjcliffe · January 14, 2021, 9:10am

I guess that’s a workaround but I’d much prefer being able to get the data directly from the hub connected to my local network rather than via two cloud platforms.

I’m running the older Weatherflow hub and stations and am happy to hold off upgrading to OH3 until Bill’s binding supports it.

Curtis · January 14, 2021, 9:19am

Correct and I would prefer a local method too but this works for me in the meantime.

A sacrifice I was willing to make to run the much improved OH3.

hww3 · February 4, 2021, 6:31pm

Hello all-

I’ve put together an initial release of the Weatherflow Smart Weather binding for OpenHAB 3.0. I haven’t tested all functionality but Hub and Air things seem to be working fine (my Sky is currently down).

Please have a look and let me know if you run into any problems!

Bill

https://bitbucket.org/hww3/org.openhab.binding.weatherflowsmartweather/downloads/org.openhab.binding.weatherflowsmartweather-3.1.0-SNAPSHOT.jar

sonny · February 4, 2021, 7:07pm

Fantastic! I have tested and it is working with OpenHAB 3.0.1

I wonder is it possible to change wind speed to m/s instead of km/h? And wind direction to cardinal instead of degrees? like north, east, west etc.?

hww3 · February 5, 2021, 2:01am

Hi!

All of the measurements are sent out of the binding using the SI units conventionally used for weather measurements. Is it possible that the user interface you are using is converting that to km/h incorrectly? I’m guessing the m/s measurements are being automatically switched to km/h, which I would imagine is a “standard” default for speed.

I’ve tried to provide data from this binding that’s as close to what the various sensors report as possible, and so I’d prefer not to convert the direction value to cardinal directions. However, I wrote a binding called Weather Calculations that takes raw sensor data and generates a number of useful derived values. Adding cardinal direction support is something I’ve been meaning to add, but no one has asked for it… until now.

I might take a little time this weekend to add that. You might also be able to create an item that transforms the numeric angle to a cardinal direction if you don’t want to mess with that binding. If you follow that thread, I’ll post an update there when I add the new feature.

hww3 · February 10, 2021, 4:26pm

I added cardinal direction calculation to the WeatherCalculations binding. Please feel free to check it out from the link in the previous post!

Also, to expand on the units of measurement problem you mentioned, it might be worth opening a bug/feature request to permit quantity item types to be configured on a case by case basis, in order to override the automatic selection of alternate units.

I’ve noticed a similar (but opposite) problem with respect to dates: the UI displays DateTime items with zone information using the zone associated with the item value, rather than the zone/location configured in OpenHAB. This causes jarring results like having a clock cell (which shows the current time zone) displayed next to a time in UTC… seems like this could be better, too!

sonny · February 10, 2021, 7:31pm

Thank you for the update.

I have tested the new .jar but I cant get the wind direction to work. In the log I can find those messages.

2021-02-10 19:54:17.486 [INFO ] [s.handler.WeatherCalculationsHandler] - Item <SmartWeatherTempest_WindDirection> changed to 281.0 °
2021-02-10 19:54:17.488 [WARN ] [ab.core.internal.events.EventHandler] - Dispatching/filtering event for subscriber 'org.openhab.core.events.EventSubscriber' failed: Rounding necessary
java.lang.ArithmeticException: Rounding necessary
	at java.math.BigDecimal.commonNeedIncrement(BigDecimal.java:4621) ~[?:?]
	at java.math.BigDecimal.needIncrement(BigDecimal.java:4677) ~[?:?]
	at java.math.BigDecimal.divideAndRound(BigDecimal.java:4585) ~[?:?]
	at java.math.BigDecimal.setScale(BigDecimal.java:2891) ~[?:?]
	at java.math.BigDecimal.setScale(BigDecimal.java:2951) ~[?:?]
	at org.openhab.binding.weathercalculations.utils.WeatherUtils.getHeadingString(WeatherUtils.java:272) ~[?:?]
	at org.openhab.binding.weathercalculations.handler.WeatherCalculationsHandler.eventReceived(WeatherCalculationsHandler.java:378) ~[?:?]
	at org.openhab.binding.weathercalculations.internal.WeatherCalculationsEventSubscriberImpl.receiveTypedEvent(WeatherCalculationsEventSubscriberImpl.java:77) ~[?:?]
	at org.openhab.binding.weathercalculations.internal.WeatherCalculationsEventSubscriberImpl.receiveTypedEvent(WeatherCalculationsEventSubscriberImpl.java:1) ~[?:?]
	at org.openhab.core.events.AbstractTypedEventSubscriber.receive(AbstractTypedEventSubscriber.java:57) ~[bundleFile:?]
	at org.openhab.core.internal.events.EventHandler.lambda$0(EventHandler.java:151) [bundleFile:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
	at java.lang.Thread.run(Thread.java:834) [?:?]

hww3 · February 10, 2021, 9:20pm

Well, that’s pretty odd. I added 281.0 and 281 to the test suite and it doesn’t seem to trigger that problem.

What version of the jdk are you running and on what platform? The output of java -version and uname -a (assuming you’re not using windows) might help track the problem down.

Bill

sonny · February 10, 2021, 9:38pm

Okay, see below. I am running OpenHabian on a Raspian Pi 4 Model B

$ java -version
openjdk version "11.0.10" 2021-01-19 LTS
OpenJDK Runtime Environment Zulu11.45+27-CA (build 11.0.10+9-LTS)
OpenJDK Client VM Zulu11.45+27-CA (build 11.0.10+9-LTS, mixed mode)
$ uname -a
Linux openhab4 5.10.11-v7l+ #1399 SMP Thu Jan 28 12:09:48 GMT 2021 armv7l GNU/Linux

hww3 · February 10, 2021, 9:53pm

It’s possible that there’s a platform specific rounding difference. I’ve added some rounding instruction to the code and posted a new version. Can you download it and see if the problem moves or goes away?

sonny · February 10, 2021, 10:36pm

Now its looks better. windDirection=308.0 ° is translated to NW

sonny · February 13, 2021, 5:08pm

About wind speed and m/s. I have found out that I can specify pattern m/s on an items metadata to get translation from km/h to m/s like %.2f m/s. In code it looks like below.

value: " "
config:
  pattern: "%.2f m/s"

marklavercombe · February 19, 2021, 4:53am

Hi @hww3
I posted last week and think you replied but our posts got lost in the forum glitch.
I think you said your hub and devices were found automatically after dropping the jar in the addons folder.
Mine aren’t adding automatically, I’m afraid.
I tried to create them manually, but seem to have the config incorrect.
I don’t suppose you’d look at your ‘Code’ tab and let me know how it looks in comparison with this?

UID: weatherflowsmartweather:hub:9d1be80a1f
label: SmartWeather Hub
thingTypeUID: weatherflowsmartweather:hub
configuration:
  serial_number: Serial_Here

Also, are there any add on bindings or anything else I need to add to make it work perhaps? A required add-on that isn’t shipped as default with OH3??

Thanks for any help!

hww3 · February 19, 2021, 7:14am

Hi Mark-

I started with a completely fresh 3.0 install. I installed the smart weather binding and everything was detected in a minute. Important to mention that the devices are on the same network as my openhab install.

Here’s the “code” segment from my hub and air devices (the sky is offline because it’s buried in snow!):

UID: weatherflowsmartweather:hub:HB-00004550
label: SmartWeather Hub
thingTypeUID: weatherflowsmartweather:hub
configuration: {}

The air:

UID: weatherflowsmartweather:air:HB-00004550:AR-00002652
label: SmartWeather Air
thingTypeUID: weatherflowsmartweather:air
configuration: {}
bridgeUID: weatherflowsmartweather:hub:HB-00004550

Hopefully this helps provide some insight… please post back if that does/doesn’t work and hopefully we can figure something out.

Bill

marklavercombe · February 19, 2021, 7:47am

Still no luck on discovery. After manual setup, I now have code identical to yours, aside from the serial numbers, but nothing is happening…

Is the serial_number in your Thing Properties showing?

The same config is working perfectly in 2.5.11 PaperUI…

hww3 · February 19, 2021, 5:26pm

Yes, I see serial_number in my thing properties.

Here’s what my binding looks like in the CLI:

openhab> bundle:list |grep Weatherflow                                                                                                                                                      
239 │ Active    │  80 │ 3.1.0.202102030147      │ openHAB Add-ons :: Bundles :: Weatherflow Smart Weather Binding

If you turn logging for org.openhab.binding.weatherflowsmartweather up to DEBUG, do you see anything in the log files? I did the following, and you’ll notice a lot of chatter about reports from the devices, even if there are no things connected.

openhab> log:set TRACE org.openhab.binding.weatherflowsmartweather
openhab> log:tail |grep eather
17:23:04.127 [DEBUG] [eatherflowsmartweather.util.UdpServer] - UDP Server received datagram: java.net.DatagramPacket@18542b39

17:23:04.128 [DEBUG] [al.SmartWeatherUDPListenerServiceImpl] - Sending message HubStatusV30Message [firmware_revision=160, uptime=2532709, rssi=-51, timestamp=1613755383, reset_flags=PIN,SFT, seq=253242] for 3 listeners.

17:23:04.129 [DEBUG] [internal.SmartWeatherDiscoveryService] - Got discovered device: weatherflowsmartweather:hub:HB-00004550.

17:23:04.129 [TRACE] [l.SmartWeatherStationDiscoveryService] - Got message without serial number, ignoring: HubStatusV30Message [firmware_revision=160, uptime=2532709, rssi=-51, timestamp=1613755383, reset_flags=PIN,SFT, seq=253242]

17:23:11.237 [DEBUG] [eatherflowsmartweather.util.UdpServer] - UDP Server received datagram: java.net.DatagramPacket@18542b39

17:23:11.238 [DEBUG] [al.SmartWeatherUDPListenerServiceImpl] - Sending message DeviceStatusMessage{hub_sn='HB-00004550', timestamp=1613755391, uptime=47085193, firmware_revision=23, rssi=-60, hub_rssi=-57, voltage=3.07, sensor_status=4, debug=0, type='device_status', serial_number='AR-00002652'} for 3 listeners.

17:23:11.238 [DEBUG] [l.SmartWeatherStationDiscoveryService] - Got discovered device: weatherflowsmartweather:air:HB-00004550:AR-00002652.

17:23:11.239 [DEBUG] [l.SmartWeatherStationDiscoveryService] - Already have thing with ID=<weatherflowsmartweather:air:HB-00004550:AR-00002652>

17:23:11.239 [DEBUG] [eather.handler.SmartWeatherAirHandler] - got status message message: DeviceStatusMessage{hub_sn='HB-00004550', timestamp=1613755391, uptime=47085193, firmware_revision=23, rssi=-60, hub_rssi=-57, voltage=3.07, sensor_status=4, debug=0, type='device_status', serial_number='AR-00002652'}

17:23:11.277 [DEBUG] [eatherflowsmartweather.util.UdpServer] - UDP Server received datagram: java.net.DatagramPacket@18542b39

17:23:11.277 [DEBUG] [al.SmartWeatherUDPListenerServiceImpl] - Sending message ObservationAirMessage{hub_sn='HB-00004550', obs=[[1.613755391E9, 981.6, -1.36, 85.0, 0.0, 0.0, 3.071, 1.0]], firmware_revision=23, serial_number='AR-00002652'} for 3 listeners.

17:23:11.278 [TRACE] [l.SmartWeatherStationDiscoveryService] - Got message without serial number, ignoring: ObservationAirMessage{hub_sn='HB-00004550', obs=[[1.613755391E9, 981.6, -1.36, 85.0, 0.0, 0.0, 3.071, 1.0]], firmware_revision=23, serial_number='AR-00002652'}
openhab> log:set DEFAULT org.openhab.binding.weatherflowsmartweather

marklavercombe · February 19, 2021, 10:40pm

Hi @hww3
Thanks again.
I figured out my problem was in the socket container configuration. Now that’s fixed, thy hub was found almost instantly.
Thanks!

hww3 · February 20, 2021, 5:33am

So glad to hear you’ve got things sorted… do let me know if you run into any more problems!

Bill

mbadger88 · February 20, 2021, 6:45am

Hi Bill!

Thanks for your work on this binding. I have a tempest and can report that it’s working for me as well (although I haven’t setup an item for each channel yet).

As it may help someone else with problems with auto discovery, make sure that your firewall is open. My Centos 7 setup was blocking the tempest UDP traffic and I applied the following rule to allow that information through.

firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" destination address="255.255.255.255" protocol value="ip" accept'