<eventList> blocks in D_xxxx.xml files - help needed

Plugins & Plugin Development General Plugin Discussion
1

I’m trying to add Event awareness to the Weather Plugin, so you can have scenes that do things when the weather conditions go south.

I’ve done this before for boolean and ui4 datatypes, and it’s worked fine, but for some reason I can’t get it working with the string datatype.

I’m assuming I’ve made a bozo error somewhere, but the Scene defining UI in Vera isn’t giving me any clues.

I’ve attached the revised [tt]D_Weather.xml[/tt], along with a screenshot of Vera’s Scene definition UI showing the setup after the new [tt]“Weather Condition”[/tt] Event has been selected.

Normally at this point, Vera’s UI dynamically includes the drop-downs (etc) specified via the [tt]“event_1”[/tt] block but for some reason it’s not doing it here (nor indicating any syntax errors)

The wiki doc in this area is a little thin, so I might have missed something.

Thoughts?

2

The event_1 block is valid JSON and the eventList matches the example at http://wiki.micasaverde.com/index.php/Danfoss_Thermostat - maybe Vera does not support the string datatype for events?

[tt]
{
“event_1”: {
“label”: “Weather Condition”,
“serviceId”: “urn:micasaverde-com:serviceId:Weather1”,
“argumentList” : {
“argument_1” : {
“dataType”: “string”,
“defaultValue”: “”,
“allowedValueList” : {
“Clear”: “Clear”,
“Cloudy”: “Cloudy”,
“Fog”: “Fog”,
“Haze”: “Haze”,
“Light rain”: “Light rain”,
“Mostly Cloudy”: “Mostly Cloudy”,
“Overcast”: “Overcast”,
“Partly Cloudy”: “Partly Cloudy”,
“Rain”: “Rain”,
“Rain Showers”: “Rain Showers”,
“Showers”: “Showers”,
“Thunderstorm”: “Thunderstorm”,
“Chance of Showers”: “Chance of Showers”,
“Chance of Snow”: “Chance of Snow”,
“Chance of Storm”: “Chance of Storm”,
“Mostly Sunny”: “Mostly Sunny”,
“Partly Sunny”: “Partly Sunny”,
“Scattered Showers”: “Scattered Showers”,
“Sunny”: “Sunny”,
“Snow”: “Snow”,
“Snow Showers”: “Snow Showers”,
“Flurries”: “Flurries”,
“Rain and Snow”: “Rain and Snow”,
“Ice/Snow”: “Ice/Snow”,
“Fog”: “Fog”,
“Windy”: “Windy”,
“Heavy Rain”: “Heavy Rain”
},
“name”: “Condition”,
“comparisson”: “=”,
“prefix”: “Condition”,
“suffix”: “”
}
}
}
}
[/tt]

3

yeah, I ran through Vera’s Javascript and it seems to support “string”. I suspect something else is amiss, but I’ve been staring at it on and off for hours and I’m slowly going blind :wink:

4

@Javier,
Thoughts on why this wouldn’t be working?

5

I don’t have the code right now (i’ll check tonight); but if there’s any error parsing the JSON, it fails silently, just like you describe.

in your file the first slightly suspicious thing is the repeated “Fog” entry. (even if jsonlint.com validates, it’s not nice)

Also, double check your serviceId’s, the one in the XML part is “urn:upnp-micasaverde-com:serviceId:Weather1”; but in JSON is “urn:micasaverde-com:serviceId:Weather1”

(PD: is any reason why you’re not using SVN for this?)

6

not in source control, lest anyone “download” it and find themselves broken.

… this harks back to my original questioning on standardized “Packaging” for download, since the current source control model assumes that the top-most release is likely viable for CT’s to download and use, and there doesn’t appear to be any form of Labelling available to label release vers.

7

that’s what branches are for!

granted, i don’t know how to manage branches on SVN (and it’s generally told that merges are painful), but there’s both Mercurial and Git support on code.mios.com

also, you can get (most of) the benefits of branching by simply copying directories: create a ‘trunk’ and a ‘release’ dir, work in trunk and when it seems sane, duplicate to ‘release’.

another popular strategy is to have a ‘mostly releasable’ repository on SVN, and the development branch on a DSCM (typically Git). you can use Git for yourself, sharing with other people that knows it’s in flux, and when it’s getting less broken, push to SVN.

labelling and branching are managed on the SCM, not on the Trac UI. There’s also a ‘release downloads’ plugin available for Trac. i could install it if you’re willing to test it.

About the ‘standarized packaging’ issue, the submission procedure to the MiOS marketplace is progressing. eventually we want this to be the main form of code dissemination :slight_smile:

And all this is of course no requirement, nor pressure. You’re free to use or not any of these tools. I just want to know when/where are they coming short.

8

Hmm, odd. My SVN client isn’t allowing either Branches or Labels, I’m not using the Trac interface for any of the source version management, just for the Wiki and backend SVN.

for now, to keep things simple, I’ve just checked in [tt]D_Weather.xml[/tt] as “broken”, with the two mods you mentioned (removal of Dup entry for “Fog” and change of serviceId) so you can pull the latest version to see the issues.

It’s still not working though. Perhaps this is related to the other problem I have with Advanced Scenes (the UI2 is currently only letting me define 1 of these, otherwise the Open/Close actions on the UI stop working for the Advanced Scenes)

On SCM, what I’d like to see is:

a) A set of guidelines and/or best practices for Directory structure.
This helps people know “what to expect”, and would encompass any “release”, “trunk” (etc) type directories.

b) A prescriptive for how to “bundle” the deliverable, until MarketPlace can handle it.
If you’re dev’ing the Market place, perhaps you can just provide us a short spec for container/deployment and we’ll follow that. When you’ve got the rest done, then we’ll be ready to go. Rules here would incorporate:

b1) File Naming rules
UPPERCASE, lowercase, camelCase, AltCamelCase etc
Release version # in the Filename Yes/No?

b2) File Format
ZIP, EAR, JAR, ??? along with any internal “structure” and/or expected Metadata files.

Ultimately I’d like to get rid of the Box.net stuff I’m using, but dont think we’re quite there just yet.

c) Download counter
Box.net gives me all sorts of stats for Download counts (etc). Something similar here would be handy for general tracking (esp if we release something by accident, and someone downloads it in the meantime… then we need to notify)

So what’s in the Release Downloads tool for Trac? Happy to test it if it steps us closer to the Marketplace direction (and some standards)

9

ok, i got to reproduce and correct the problem with one of my plugins. because of the way the JavaScript constructs the pulldown menus, the left-hand part of the allowedValueList entries can’t have any spaces or other ‘special’ characters. try to use only letters, numbers and underscores, and don’t start with a number.

specifically, there are some places where it constructs a JS command and [tt]eval[/tt]'s it. and uses that lefthand as part of a variable’s name.

in your case, it means changing the list like this:

    "Haze": "Haze",
    "Light_rain": "Light rain",
    "Mostly_Cloudy": "Mostly Cloudy",
    "Overcast": "Overcast",
10

Javier,
Thanks for tracking this down.

Since the Left-Hand values are anything that’s “valid” to put into a Device [State] Variable it seems like Vera should handle that by tackling any required encoding/decoding before presenting it to the Luup code.

ie. if spaces are allowed in State Variables, they should be allowed in Device Scene/Event definitions

What Bug Tracking # is being used to get the problem addressed in the core JS libs (and ensuring it works in UI4)?

11

[quote=“guessed, post:10, topic:165843”]Javier,
Thanks for tracking this down.[/quote]

so, you got it to work on your plugin too?

it’s not about presenting to luup; it’s used as part of a Javascript variable name, not a device’s UPnP state variable.

i think it shouldn’t have any restriction at all, it should be treated as string data. (at most, HTML limitations, since it’s ultimately shown in a HTML pull down menu)

i’ll be on this (and a couple other things) this weekend. i’ll try to submit a patch to get it done.

12

Yeap, if I strip out all the entries with “spaces” in them, then it works. I will push an update to SCM like that so that the “basics” are in place.

If you want to validate the fixes you put in, you’ll want to pull the original D_Weather.xml that has all the spaces, slash characters etc:

http://code.mios.com/trac/mios_weather/browser/D_Weather.xml?rev=2&format=txt
13

@Javier, let me know if you need a hand to validate your changes, or a tracking bug filed if it’s going to take longer than expected to fix.

14

Filed this for tracking so it doesn’t get lost:

http://bugs.micasaverde.com/view.php?id=1038
15

Javier,
Any joy? I just repro’d in UI4 also, so doesn’t look like that release has fixed the JS either.

Can you move the Mantis (above) into the UI4 Queue?

16

Javier, any thoughts? This is still an issue in UI4.