[SOLVED] Weatherflow Smart Weather Station binding

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…

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

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!

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

Bill

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'
1 Like

Hi,

I also have a Tempest … actually, I have 3, but 2 are not deployed yet.

Discovery on 2.5.12 was flawless, once I figured, I had to install the experimental rule engine. I’ve set all sensors up and added them to my InfluxDB/Grafana setup. Let’s see, how we get on, but so far this is looking good.

Thanks for the work on this.

/M

1 Like

Hello all since M5 build of openhab 3.1 i get this error

2021-06-01 14:08:07.859 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle:

file:/usr/share/openhab/addons/org.openhab.binding.weatherflowsmartweather-3.1.0-SNAPSHOT.jar

org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.weatherflowsmartweather [313]

  Unresolved requirement: Import-Package: javax.measure; version="[1.0.0,2.0.0)"

	at org.eclipse.osgi.container.Module.start(Module.java:463) ~[org.eclipse.osgi-3.16.200.jar:?]

	at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:440) ~[org.eclipse.osgi-3.16.200.jar:?]

	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.6.8]

	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.6.8]

	at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [bundleFile:3.6.8]

	at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.6.8]

	at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.6.8]

@hww3 can you recompile the bindings? See here openHAB 3.1 Milestone discussion - #181 by wborn

I’ve uploaded a version that’s been recompiled. I have not tested this so YMMV.

https://bitbucket.org/hww3/org.openhab.binding.weatherflowsmartweather/downloads/

2 Likes

Hi Bill, I wanted to give the 2.5.11 Version a try but openhab denies the installation when I add it to the addons folder it says:

Error while starting bundle: file:/usr/share/openhab2/addons/org.openhab.binding.weatherflowsmartweather-2.5.11-SNAPSHOT-2.jar

anything I can supply you with to make this thing work again?

Thanks in advance!

Cheers

Hi-

Are there any more error messages related to this problem in your openhab.log? Usually when something like this goes wrong, the root cause is printed (it can be pretty verbose).

What version of openhab are you running?

Bill

Hey Bill I am still on OH2, here you are:

[WARN ] [org.apache.felix.fileinstall        ] - Error while starting bundle: file:/usr/share/openhab2/addons/org.openhab.binding.weatherflowsmartweather-2.5.11-SNAPSHOT-2.jar

org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.weatherflowsmartweather [248]

  Unresolved requirement: Import-Package: org.openhab.core.automation

	at org.eclipse.osgi.container.Module.start(Module.java:444) ~[org.eclipse.osgi-3.12.100.jar:?]

	at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[org.eclipse.osgi-3.12.100.jar:?]

	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.6.4]

	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.6.4]

	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1221) [bundleFile:3.6.4]

	at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:515) [bundleFile:3.6.4]

	at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.6.4]

	at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.6.4]


Ok… I see what the problem is. You need to install the “new rules engine”. It’s not enabled by default and for some reason openhab doesn’t detect the dependency automatically. Once you enable it, the binding should start up without problems.

Bill

Hello @hww3 ,

I recognized that the lightnings. It updated in OH is this a known problem??

I’m not sure I follow… there are 2 pieces of lightning functionality:

  1. The lightning fields in the periodic reports from the air/tempest sensor, which should update any items you have linked to those channels.

  2. If the hub broadcasts a lightning strike event, that can be used to trigger a rule using the new rules engine.

Can you clarify what you think is going wrong?

Thanks!

Bill

HI Bill, any chance to integrate weatherflow weather forecast data?

Hi-

The forecast data isn’t available in the local UDP broadcast data from the SmartWeather hub. The forecast data is available from the weather flow REST service, which is sort of separate from the observation data. I was going to suggest that maybe that be added as a new data source for the Weather binding, but it seems that’s not been updated for use with OpenHAB 3 (seems like a pretty odd thing to get left behind).

As a stop-gap, you could generate an access token and then use the HTTP binding to fetch forecast data…

You can generate a token at https://tempestwx.com → Settings → Data Authorizations.
You’ll also need your numeric station ID, which you can get from the “Sharing Page” under Settings → Public Data.

Then you can generate the URL you need from this page:

https://weatherflow.github.io/Tempest/api/swagger/#!/forecast/getBetterForecast

I’d set the refresh interval to something like 1200 seconds (every 20 minutes) with a timeout of 2000 ms.

Then you can create channels and items that pull bits and pieces of the forecast data every time it’s fetched. The data is JSON, so you can use the JSONPath transform module to do this. For example, here’s a snippet you can use as a state transformation that will get the expected conditions from the first hour of the forecast:

JSONPATH:$.forecast.hourly[0].conditions

Here’s an example I just threw together that creates a thing with the currently forecast condition. Just change your station ID and authorization code:

UID: http:url:WeatherflowForecast
label: Weatherflow Forecast
thingTypeUID: http:url
configuration:
  authMode: BASIC
  ignoreSSLErrors: false
  baseURL: https://swd.weatherflow.com/swd/rest/better_forecast?station_id=0000&token=MYTOKEN
  refresh: 1200
  commandMethod: GET
  contentType: application/json
  timeout: 2000
  bufferSize: 2048
channels:
  - id: ForecastJSON
    channelTypeUID: http:string
    label: JSON
    description: ""
    configuration: {}
  - id: Hourly_Conditions
    channelTypeUID: http:string
    label: Hourly_Conditions
    description: ""
    configuration:
      mode: READONLY
      stateTransformation: JSONPATH:$.forecast.hourly[0].conditions
1 Like

The periodicaly reports…I still see 0 even a lot of lightnings right now in my area

I would verify that your sensor is actually indicating data. If it isn’t, the binding won’t show anything either. You can snoop udp port 50222 to see the data broadcast by your hub.

See this page for details of where to find the lightning strike data:

https://weatherflow.github.io/Tempest/api/udp/v143/

Hoi Bill, any hint how to install it? Any disatvantages or problems I might face with OH2 when installing this “new rules engine”?

Cheers and thanks for the help!