2018-10-04 19:59:10.327 [ERROR] [nhab.binding.weatherflowsmartweather] - FrameworkEvent ERROR - org.openhab.binding.weatherflowsmartweather
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.weatherflowsmartweather [286]
Unresolved requirement: Import-Package: org.eclipse.smarthome.automation
at org.eclipse.osgi.container.Module.start(Module.java:444) ~[?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1634) ~[?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1613) ~[?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1585) ~[?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1528) ~[?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) ~[?:?]
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) [?:?]
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) [?:?]
I think this is caused by a new dependency. Iāve started adding support for triggers on events like ārain startedā and I think thatās what this error is being caused by. To resolve it, you should be able to go into PaperUI -> Addons -> Misc, and install the āExperimental Rules Engineā. Once you do that, the dependency should be automatically resolved. If youāve removed the weather flow binding, you might have to re-add it to the adding folder, but if not, it should start up automatically.
As for the triggers, thatās still a work in progress so I wonāt say any more about it until itās actually useful. Stay tuned for updates on that.
I have a few more things to add: mostly surrounding rule triggers (on events like āRain startedā or āLightning Strikeā).
It would be happy to contribute it so that it can become an official binding, though it probably makes sense to add everything on my list before that, as should it become accepted as a contribution, making changes would become much more difficult.
I am just testing everything out with the new 2.4 release of OpenHAB. If all goes well, I should have a new version ready to go in a few days.
I think the first set of messages should probably be switched to debug rather than info, now that things are working pretty smoothly.
I think I removed the accumulated rain channel because itās not something that comes from the SmartWeather Hub, but rather is generated by SmartWeatherās cloud service. Youāre likely seeing it because you installed the binding before I removed it, and OpenHAB doesnāt automatically track those changes. If you sort through your items, youāll probably find and delete it.
Iāll try to remember to re-assign the log level for that first set of messages.
Iāve posted a new version of the Weatherflow Smart Weather binding built for OpenHAB 2.4.0 to the download site above. Iāve been running it for about 2 weeks and it seems to be stable.
Features from previous release:
Less verbose logging by default. Should keep your log files cleaner.
Includes 3 triggers for use with the new rules engine: Lightning Detected, Precipitation Started and Rapid Wind. Iāve only really tested the Rapid Wind trigger, and depending on how your station is configured, this could mean a rule being triggered every 3 seconds.
If anyone is interested in having some samples of rules that use these new triggers, let me know and Iāll throw some together that print out the data available.
This is basically the level of functionality that Iād hoped to achieve when I started working on this binding. If anyone has any further feature requests, please let me know.
As always, feel free to let me know if you have any questions or comments!
Iām actually not sure how to go about doing that; Iāve only ever used PaperUI/HABmin to set things up.
I suspect that youād need to create a Bridge thing that specified the hub binding and include the hub serial number as a configuration value. The actual air/sky sensors would be contained within the bridge entry. Based on what other people are doing with other bindings, something like:
Bridge weatherflowsmartweather:hub:YOUR_HUB_SERIAL "My SmartWeather Hub" [ serial_number="YOUR_HUB_SERIAL" ] {
Thing weatherflowsmartweather:air:YOUR_HUB_SERIAL:YOUR_AIR_SERIAL "My Smartweather Air" [ serial_number="YOUR_AIR_SERIAL" ]
}
Hopefully this will get you close to a working configuration.
Iām trying to setup an OH server at home. I get some troubles with this binding: when I startup OpenHab server it recognize Weatherflow Hub but just after a moment in log I get this
2019-06-25 18:41:00.646 [WARN ] [atherflowsmartweather.util.UdpServer] - Server closed unexpectedly: Bad address (Receive failed)
java.net.SocketException: Bad address (Receive failed)
at java.net.PlainDatagramSocketImpl.peekData(Native Method) ~[?:?]
at java.net.DatagramSocket.receive(DatagramSocket.java:743) ~[?:?]
at org.openhab.binding.weatherflowsmartweather.util.UdpServer.runServer(UdpServer.java:351) [248:org.openhab.binding.weatherflowsmartweather:2.4.0.201901080330]
at org.openhab.binding.weatherflowsmartweather.util.UdpServer$1.run(UdpServer.java:219) [248:org.openhab.binding.weatherflowsmartweather:2.4.0.201901080330]
at java.lang.Thread.run(Thread.java:748) [?:?]
I took a look at the latest firmware documentation and there isnāt anything new available from the local API. Itās unclear if the work thatās been done in the past 6 months or so to make micro-calibration adjustments is happening through the cloud API or if itās being folded into the results sent from the local broadcasts.
Mine is very stable. Works well and is accurate. Great functionality and works with openhab on local network. There are some reviews on internet. My opinion is that this is currently best weather station for smart home.
