As I was moving as many plugins as possible from my Vera to openLuup on a Raspberry Pi, I stumbled across the fact that the Weather plugin I had obtained from the MiOS app store would not run under openLuup as it is encrypted by his author. Since I need the functionality, I wrote from scratch a basic plugin for my own purposes that reads a few data from the Weather Underground website. Far less functionality than the original plugin that only runs on Vera, but it can be expanded if there is interest.
UPDATE January 31, 2017:
Version 1.6 is now available on the “App Store” from the AltUI interface.
Changelog:
Version 1.0 2016-07-15 - first production version, installation via the AltUI/openLuup App Store
Version 1.1 2016-08-24 - major rewrite for cleaner and faster code, but no new functionality
Version 1.2 2016-09-22 - added language parameter to fetch the WU data in another language than English (@korttoma suggestion) and added today and tomorrow forecast data (high/low temps, conditions and text forecast)
Version 1.3 2016-11-13 - added WU display and observation locations (@jswim788 suggestion)
Version 1.4 2016-11-14 - added ‘AllowEstimated’ parameter variable, to ignore estimated data produced by WU when a weather station becomes somehow unavailable
Version 1.5 2017-01-19 - update suggested by @amg0 to allow for two icons to appear in the device in AltUI: Not only today’s weather condition, but also tomorrow’s. This change will be effective with a new release of AltUI by @amg0 to enable the display of the additional icon.
Version 1.6 2017-01-30 - amg0 update for ‘WindSpeed’ variable
I took a quick look and was surprised to see this line in the source code:
if this_device ~= nil then -- quick & dirty solution to the fact that init gets called twice upon luup startup
…since this is not a known issue.
Then I looked further and saw that this is no surprise at all, since you explicitly call it twice: once on line 161
init()
…and once from the implementation file:
<startup>init</startup>
I also see that you create the ‘child’ devices as independent devices, rather than using the luup.chdev modules (which, admittedly, are a bit more cumbersome.) This is fine, and exactly the way I would do it if running the Lua code as part of startup rather than a bona fide device. What it means is that the child devices will not get deleted if the parent device is deleted.
Many thanks Akbooer for taking the time to check my code. Much appreciated.
I now see the issue with the call to init() on line 161… Legacy from an early version that I had ran as a module for testing… and that I forgot to remove once the code was moved to a plugin version. Appreciate the pointer and will correct.
Regarding the creation of the child devices, I actually tried to use the luup.chdev module but I could not get it to work (the parent device implementation code stopped responding after the call to chdev.sync). I then decided to stop banging my head on the wall and just use luup.create_device despite the shortcoming that you describe. I may relook at this in a future version.
[tt]chdev.sync[/tt] will cause a reload if there are any changes in created child devices (eg. the first time you create them.) This would certainly cause the handler to stop responding until openLuup.init() is up and running again.
Great to see this is now in the Alt App Store… downloaded to openLuup with one click of the download button… Plugged in my location and key and away we go. Thanks!
local json = require "json"
local key = "XXXXXXXXXX"
local req_fmt = "https://api.wunderground.com/api/%s/conditions/forecast/q/%0.6f,%0.6f.json"
local url = req_fmt: format (key, luup.latitude, luup.longitude)
local status, result = luup.inet.wget (url)
local info = json.decode (result)
print (pretty(info))
…although if you’re really an XML devotee, then you could (equally) use openLuup’s XML parser to do the same thing…
local xml = require "xml"
local key = "XXXXXXXXXX"
local req_fmt = "https://api.wunderground.com/api/%s/conditions/forecast/q/%0.6f,%0.6f.xml"
local url = req_fmt: format (key, luup.latitude, luup.longitude)
local status, result = luup.inet.wget (url,5)
local info = xml.decode (result)
print (pretty(info))
Mmmm - certainly helps when a json and a xml decoder are “just” available. It took MCV sometime to distribute a JSON decoder with their firmware and I believe it still doesn’t have a XML decoder as such? Presumably both these libraries are part of the Open Luup install?
Absolutely! Both XML and JSON required to read the UPnP files and respond to HTTP requests. The JSON one is extremely well tested (about 200 test cases, both valid and illegal syntax, all available from the openLuup GitHub repository). The XML one is good enough for the job, but not so comprehensively tested. Both are DOM-type, as you can see from the examples.
