Thinking all is good, I load these into Vera (D_, I_ and S_ files) but it errors out during the loading process:
[tt]01 08/12/09 22:05:38.640 Device_LuaUPnP::CreateService 110 incomplete service /urn:upnp-yahoo-com:serviceId:YahooWeather1/S_YahooWeather.xml<0x400>
01 08/12/09 22:05:38.641 Device_LuaUPnP::CreateServices removing incomplete service from 110<0x400>
[/tt]
Not sure why, or what specifically is wrong with my Service file.
Thoughts? Has anyone tried building one of these from scratch?
Since you’re poking around with weather lookups, I want to share the following resource with you, which is NOAA’s “REST Request” facility, through which you can get up-to-the-minute weather information for any U.S. location - simply by furnishing a ZIP code, city name or latitude/longitude pair:
(Note that the LAT/LON method only seems to produce results if the coordinates are a known WGS84 pair, but the page describes how to hunt up known LAT/LON pairs inside a given quadrant.)
Seems to return data in XML format, rather than Yahoo! Weather’s pretty graphical format.
Are you sure you need a service? It only necessary if you want to make your plugin accessible from alternative upnp control points. For “in-Vera” use there’s no need in that…
I’m trying to provide an Attribute that a user can “type in” the Yahoo LocationID value for their location (ZIP Code or similar).
In effect, I’m just parameterizing the 1 “string” input value to my Weather Device, on a per Device instance basis.
There’s a VERY manual way I can do this, where the user would have to “add variable” (Vera UI) to do it manually, but I’m trying to make it trivial so folks dont have to read documentation… mostly
Other Child devices I build using Services get these Variables automatically (presumably because they’ve utilized the Service defn)
This may be too far-fetched to answer your problem, but I’ll put it out there anyway:
Since your app assumes an Internet connection, and your ultimate goal is to shield the user from having to change code or manually enter information…
…could your program simply reach out via PING or make use of the DNS IP to deduce roughly where Vera is located? I’m thinking how a TraceRoute program I used to run could glean router locality info for each “hop”, and essentially figured out my home town location without me ever telling it a thing.
If you simply do variable_set on your own (non-existent) service variable as part of lug_startup with some default value, Vera will add the properly named field on the UI - exactly the same as if you used a proper upnp service. In other words, use your service, but you don’t have to define it explicitly.
That’s what I did in all my plugins. In startup I do “get” on my “service” variable, with no actual service defined. If I get nil it means it doesn’t exist, so I do set with zero or empty string. So user has all the custom fields right away.
Yeap, know about that one also, but wanted to know the “formal” way this would work, not just the on-the-fly mechanism.
My goal here is to work out how to best “play by the rules” so Vera’s UI components, or any other future UI, understand the control correctly. This includes all it’s Datatypes for input, and any associated [Declarative] input - stuff the S_xxx files appear to support.
Libra, the “maps” of where IP addresses resolve aren’t well defined. They can get you to a general “region” but it’s hit-n-miss beyond that, they’re often wrong, and they do change over time. We have devices at work that do this, using various catalogs, and the hit rate is only reasonable.
I’d hate to have someone’s Heater “automatically” turn on when the WeatherDevice thinks they’re in Antarctica
I’d like this as my “manual override” to whatever [likely Lat/Long based] mechanism I ultimately use to automate it. That part is also complex, so this will likely be the first-gen solution.
Separately, I’m using this as an excercise to learn how it should be done. I can likely work around the problems a number of ways, but feel it’s important to thrash out these “usage” scenarios so that we can get it clearly documented for everyone else that needs the same - esp the “declarative” mechanisms.
So it’s not just about getting it done, it’s about learning how it should be done. Hope that makes sense.
[quote=“guessed, post:1, topic:164702”]In order to define a Parameter for my Weather component, I decided to add a new [tt]S_YahooWeather.xml[/tt] definition for it like:
<?xml version="1.0"?>
<scpd xmlns="urn:schemas-upnp-org:service-1-0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<serviceStateTable>
<stateVariable>
<name>YahooLocationID</name>
<sendEventsAttribute>no</sendEventsAttribute>
<dataType>string</dataType>
<defaultValue>Enter a Yahoo! Weather LocationID or ZIP Code</defaultValue>
</stateVariable>
</serviceStateTable>
<actionList>
</actionList>
</scpd>
I copied the style from some of the inbuilt ones in Vera’s luup extensions area.
Then I attach it to my [tt]D_YahooWeather.xml[/tt] file as in the following:
Thinking all is good, I load these into Vera (D_, I_ and S_ files) but it errors out during the loading process:
[tt]01 08/12/09 22:05:38.640 Device_LuaUPnP::CreateService 110 incomplete service /urn:upnp-yahoo-com:serviceId:YahooWeather1/S_YahooWeather.xml<0x400>
01 08/12/09 22:05:38.641 Device_LuaUPnP::CreateServices removing incomplete service from 110<0x400>
[/tt]
Not sure why, or what specifically is wrong with my Service file.
Thoughts? Has anyone tried building one of these from scratch?
(I’m assuming it’s something obvious :-)[/quote]
guessed, did you eventually resolve this issue? If so please post solution. If not, I have to ask what is necessary for vera to a service or service file as complete?
Never worked that one out, so it still errors like that silently in the background. The Alarm Panel interface has a different defn and it’s working fine.
More recently I’ve moved to only using the [tt]S_xxx.xml[/tt] files to describe StateVariables and [Scene] Event defs. In Weather I was trying to use them to declare my configuration parameters as well.
For the Alarm Panel, the configuration parameters are [effectively] hard coded into the code-base, not declared in the [tt]S_xxxxx.xml[/tt] file, as it turns out they really just want us to use luup.variable_set to “create” these (can’t recall MCV’s posting where this technique was blessed)
If possible I’d like one of the MCV team to load my Weather plugin and tell me what’s up, but in the grand scheme of things, it’s not that important just yet relative to the other things that need to be addressed.
Yes, this was indeed funny as i downloaded you Weather plugin as a starting point for my own device, got the same problem and the only thread about it was yours. Took me an hour of comparing a working sample to find the typo. Really tricky
