Ok, I was able to reproduce your situation with a clean install. It looks like a number of channel type definitions got removed when I added the new “Better Forecast” thing. Not clear how it happened but that was definitely the cause of the problem. I’ve uploaded new versions of both 3.2.0 and 3.3.0-SNAPSHOT. If you could try it again (remove the jar, uninstall the bundle and reinstall as above) and let me know how you fare, that’d be great.
Thanks for your patience!
Bill
That fixed it! All channels now appearing correctly, thanks so much for the quick response!
Question: The “temperature” item is reporting in Celcius. In the Tempest setup app, it’s set to Farenheit, but that seems to be ignored. Any way to get the temp item in F, or do I need to create a new item/rule for that?
The weather flow system operates natively using SI measurements, so the setting in the tempest app is used just for displaying the data in that app. The binding is “Units of Measurement” aware, so you may just need to change your openhab configuration to use the right system of units:
Settings → Regional Settings → Click the “Show Advanced” button → Measurement System
Note that if you’re in the US, we use the “U.S. Customary” measurements system, which differs from the U.K. “Imperial” system in a few places (their units for pints and gallons, for example are quite a bit different than those in the US). I haven’t investigated to see what conversions are actually being used. I don’t think though, that the differences matter for anything you might get from the weather sensors. For example:
First of all: Thank you for the binding! Tempest works like charm, I can’t get the HUB working, but I guess it’s due to the fact I have some newer version and frankly I do not miss it much.
There are two things I was not able to figure out.
Weather widget
I’m using either BasicUI or the new UI. I managed to create a widget in the new UI from the weathercard.yaml file, I add it to UI, configured the forecast item to “better forecast” (tried both raw and enriched), but it just shows “TypeError: Cannot read properties…”. Both items contain data and logs show BetterForecast is regularly updating. Not sure what I do wrong and not capable enough to do proper coding myself (just scripting or messing with better people code ;-)). So I find it sad that I’m not using this provider at all.
Event trigger for rapid wind
I’m kind of conservative and using old textual rules. I just can’t find out how to get the thing channel to trigger the event properly. Nevertheless, as WindSpeedGust gets updated I’m using this item and it works. Just curious how others solve it.
Hi-
What sort of problem are you having with the hub? Are you seeing any errors in your openhab.log file?
For the first problem with your weather card widget, I would make sure that you’re using the enriched weather channel, as this has some things that make the weather card widget much simpler. Second, I’d verify that you’re using the weather card yaml from this project. There’s an “originaI” widget available elsewhere that looks similar but doesn’t work with this data. I’d then verify that the data in the forecast item looks valid (though you said it does have data).
Mine looks something like this, though I can’t show all the data on one screen:
Then, make sure you’ve assigned the item with the forecast data in the widget properties. You might have to reload the page in your browser.
Also, what browser/version are you using? I’ve tested with Safari and Firefox. I know at least one other user who’s been able to get it working, but I’m not sure what browser they’re using. You might also check the javascript console in your browser for any suspicious looking errors. I don’t get any in my browser, just a few debug messages that I intentionally left in.
Finally, I don’t know that the RapidWind trigger will work with the “old” rules engine. The modular event trigger feature is specific to the new rule engine (the rapid wind events don’t have a channel so it’s not possible to use the them to trigger rules on the old engine.
Bill
Thanks a lot!
No errors in openhab.log
Items are linked to channels, but show no values.
I have had my HUB exchanged some time ago, this one is quite new and different (e.g. has USB-C port), not sure if it may be related. Firmware is 177. I see all information on web, but I understand the binding should read local information. As mentioned, station (Tempest) sends all data well, including rapid events, which is sufficient. As it seems to me it updates the Item immediately to tiggering change on wind_gust seems to work. I haven’t yet tried triggering precipitation_type or strike_count but guess they would work as well.
Yes
I do. In fact, I tried to try both, but only yours has the forecast item, the other works on item_prefix basis.
My enriched item looks like
Done. You can see how the widget looks on this picture
The error message is "TypeError: Cannot read properties of undefined (reading ‘current conditions’)
Chrome or Edge so far. But I will give it a try.
This may be it - quite a lot of errors came out.
I’ll try some googling, digging or experimenting and keep you posted.
Hi-
Since you’ve replaced your hub, I assume you’ve updated the new serial number of the hub in the various places (things definitions, items and such). Weatherflow hasn’t published the 177 API but it’s hard to imagine they’ve changed something that would cause problems. If your hub thing is online and you’re receiving updates, it’s probably okay not to worry about the hub channels… there’s nothing really important there.
Your configuration and item value looks okay, but you’re getting more errors than I’d expect… and 404 (not found) at that. On my install of 3.3.0-SNAPSHOT, I don’t get any 404 errors. You might want to look at the “network” tab and do a reload of the page. That might give you some clues, and I’ll see if I can find a machine which chrome or edge to test on.
Let us know what you find out!
Hi-
Just wanted to provide a little update here:
I tested the page I added my version of the weather card widget on a few more browsers, and they all seem to work fine:
The widget yaml file is probably very sensitive to re-formatting, like extra spaces or line breaks. So, if you’re getting javascript errors in your browser console, that could be a possible source of problems.
Bill
Thanks a lot - you brought my attention to it after I gave up and surprisingly I guess I was able to fix it :-).
I found out in other browser that the error points to missing dummy.js - which was not present in your distribution.
I than I changed line 198 of the yaml from dummy.js to rapidWind.js - done a few refresh and voila!
Once more thans for your support and work on the binding!
I’m glad to hear you figured out what the problem was. I did just take a little time to add some basic installation instructions[1] for the widget and made sure I included the creation of the dummy.js file. It’s true that you can use any file that exists… I did it exactly how you described but eventually decided it might avoid future problems by not using a file meant for something else.
Anyhow, glad you’ve figured things out and please don’t hesitate to let me know if you have any suggestions or ideas for improvement!
Hey,
I updated to openhab 3.40 now getting this error
Error while starting bundle: file:/usr/share/openhab/addons/org.openhab.binding.weatherflowsmartweather-3.3.0-SNAPSHOT.jar
Unresolved requirement: Import-Package: org.openhab.core.config.core
Hi Milo,
I also updated today and got a similar error at startup but it seemed to recover and is working fine so far:
2022-12-25 16:21:40.537 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/opt/openhab/addons/org.openhab.binding.weatherflowsmartweather-3.3.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.weatherflowsmartweather [28]
2022-12-25 16:23:47.931 [INFO ] [.SmartWeatherStationDiscoveryService] - Creating discovery service: org.openhab.binding.weatherflowsmartweather.internal.SmartWeatherUDPListenerServiceImpl@25c897c3
2022-12-25 16:23:47.950 [INFO ] [.SmartWeatherStationDiscoveryService] - Starting scan: this: org.openhab.binding.weatherflowsmartweather.internal.SmartWeatherStationDiscoveryService@35d25fb3 udpListener: org.openhab.binding.weatherflowsmartweather.internal.SmartWeatherUDPListenerServiceImpl@25c897c3
Boy early adopters! I haven’t had a chance to investigate the new release, though I suspect the binding will just need to be recompiled against the new version’s dependencies. I’m in the middle of moving, so I won’t have a chance to get to this for a week or so, but I’ll look into it as soon as things settle down here.
In the meantime, you can verify the status (whether it’s started properly or not) by doing a bundles:list.
Bill
It’s now been running fine for me on 3.4.0 for a few days Bill:
openhab> bundle:list | grep Weather
28 │ Active │ 80 │ 3.3.0.202206212331 │ openHAB Add-ons :: Bundles :: Weatherflow Smart Weather Binding
Same for me …only the “error” during Startup is logged but I don’t see any issue so far…running 4days now
I just found this binding, can’t believe I hadn’t seen it before, but thank you for the great work on it Bill!
I’ve had the Tempest for a year or so now from one of their campaigns and local data is the thing I’ve been missing.
Quick question to clarify on some of the rain data though, I have read through this thread and wanted to make sure this was still the case, seems its changed over time.
What is the correct channel/data that should be used?
rain_accumulated channel does not look to be an option in the API docs for Tempest Observations, I saw mention that this doesn’t work for some types of stations and is always 0 but it is in the API specrain_accumulated and precipitation_type channelsMy assumption is that rain_accumulated is actually the “Rain amount over previous minute” for the Tempest, which would then be what I use to calculate the total rain over the day.
I am on OH 3.4.1 using the latest version of the binding.
Hi-
Yes, it’s a little confusing because I tried to use the field names that weather flow uses for their observation data API, which isn’t quite the same as how they describe the fields in the local API documentation. The field “rain_accumulated” doesn’t seem to be described in any detail there, but it is the amount of rain registered since the previous report. There’s a local day total field which only has meaning if you get the observation data from the Weatherflow cloud API, so I no longer expose it.
You can use the Weather Calculations binding to manage the summing of rain accumulation, though you could do it yourself using a rule.
Hope this clarifies things a bit!
Bill
Hi all,
Just wanted to drop a quick note to let you know that I’ve compiled the Weatherflow binding for openHAB 3.4. It has no other changes, and as I don’t have a 3.4 installation, I’m not able to test it out yet. However, I think it’s likely to work without problems. Please feel free to try it out and let me know if you run into any problems.
Here’s the link:
https://bitbucket.org/hww3/org.openhab.binding.weatherflowsmartweather/downloads/org.openhab.binding.weatherflowsmartweather-3.4.1.jar
Best,
Bill
Exactly what I needed, so thanks for confirming, essentially this is mm/min with the interval being every minute, which is what can be used to calculate the rest.
Have also installed the new version and seems to be working fine, thanks.
Last question for now, because I couldn’t see it in previous comments (apologies if it is detailed somewhere), if I want to use a rule based on the rain event trigger, would the trigger channel be "weatherflowsmartweather:tempest:HB-00000000:ST-0000000:precipitation#event"?
And Lightning events would just be :lightning instead?