I would like to change the appearance of a Device in the Dashboard. I would like to add some labels to show the state a particular device is in. I assume that this is done by providing some code between and in the D_XXX.xml file (maybe needs code as well for something to happen). I could look at code from existing devices to infer what the syntax may be (a bit messy). However, maybe there is a tutorial/documentation somewhere out there that describes how to do it. If anyone knows about some documentation, could you give me a pointer please (I looked around but could not see it). Thanks.
Hi utz,
There’s no documentation that I know of. The appearance of devices in UI4 is controlled by the static JSON file, usually called D_foo.json. What we’ve learned is that the “Tabs” array’s first element does double duty: not only does it control the appearance of the leftmost tab of the device’s detailed dialog (when you click the wrench/spanner), but it also controls the appearance of the device in the dashboard.
You will probably have to look at others’ examples for guidance. I’m still learning this stuff, so my plugins are a bit hit-or-miss. The most complex examples I know of are the DAD (astronomy) plugin and the standard Alarm Partition device. Once you’ve understood those, I think you will be as good as any of us.
Thanks for the hints. I looked at many of these D_XXX.json files and puzzled it together. The really tricky bit was to figure out that “double duty”; that took me ages I was searching for code that does that and could not find it. So now it looks as I want and I can write code that sets information on labels. However, there are some things I still do not understand and I need to figure out.
-
When I have a scene and want to use my device in commands/events it does not show up. Which code does that? Is it the section “eventList” in the .json file?
-
Often I see code in D_XXX.json and D_XXX.xml. I assume for UI4 the stuff in .xml is not needed and only stuff in .json is used?
… the programming of the system is not that bad at all. Most time is lost on figuring out how to do things. This system really needs more documentation. A set of tutorials (similar to the Luup Somfy Walkthrough, but updated) would be helpful.
eventList is for things that your device can do to trigger a scene or notification. Examples would be: “Temperature goes below X degrees”; “Alarm is disarmed”; “Power usage exceeds Y kWh”.
sceneList is for things that your device is capable of doing, manually through the Vera UI or automatically through a scene. Examples would be: “Turn off the power to the device”; “Arm the alarm with PIN Z”; “Change the temperature setpoint to W degrees”.
We’ve figured out most of the structure of eventList and sceneList, so I’m pretty confident about answers I can give here. Probably the most difficult part of this is the inevitable confusion about Service Types and Service IDs, which have similar-but-different strings and aren’t always labelled clearly.
2) Often I see code in D_XXX.json and D_XXX.xml. I assume for UI4 the stuff in .xml is not needed and only stuff in .json is used?
Yep. I don’t put any JSON into D_XXX.xml in my new plugins, and they seem to work fine on UI4.
I populated the eventList in my D_Powermax.json file. However, in a scene under Events->“Add Event”->“Please select device” I do not get my Powermax device as a selection option. So, something is missing to make the system aware that there are events to choose from for this device. Which line of code am I missing? Something in D_Powermax.xml that makes the system aware that there are events?
Below is the code in the D_Powermax.json file that I thought would do the job.
Anyone a suggestion what I am missing?
],
"eventList": {
"event_1":{
"label": "The alarm panal status has changed",
"serviceId": "urn:viewsonic-com:serviceId:AlarmStatus1",
"argumentList" : {
"argument_1" : {
"dataType": "string",
"defaultValue": "",
"allowedValueList" : {
"Awaiting Status": "Awaiting Status",
"Disarmed": "Disarmed",
"Armed (Home)": "Armed (Home)",
"Armed (Away)": "Armed (Away)"
},
"name": "AlarmStatus",
"comparisson": "=",
"prefix": "Which mode",
"suffix": ""
}
}
}
},
"DeviceType": "urn:viewsonic-com:device:AlarmStatus:1",
"device_type": "urn:viewsonic-com:device:AlarmStatus:1"
I’ve had that happen. It’s usually because of a typo somewhere. Check these:
- Your D_Powermax.xml file contains a element that points to your D_Powermax.json file. Example from one of my plugins:
<device>
<deviceType>urn:schemas-futzle-com:device:CurrentCostEnviR:1</deviceType>
<staticJson>D_CurrentCostEnviR1.json</staticJson>
<serviceList>
- Your D_Powermax.xml and D_Powermax.json files have the same contents, here urn:schemas-futzle-com:device:CurrentCostEnviR:1. XML file above; JSON file here:
"DeviceType": "urn:schemas-futzle-com:device:CurrentCostEnviR:1"
- Your D_Powermax.xml file and D_Powermax.json files have matching Service IDs (here urn:micasaverde-com:serviceId:EnergyMetering1:
<serviceList>
<service>
<serviceType>urn:schemas-micasaverde-com:service:EnergyMetering:1</serviceType>
<serviceId>urn:micasaverde-com:serviceId:EnergyMetering1</serviceId>
<SCPDURL>S_EnergyMetering1.xml</SCPDURL>
</service>
"event_2": {
"label": "Energy usage goes below",
"serviceId": "urn:micasaverde-com:serviceId:EnergyMetering1",
"norepeat": "1",
"argumentList" : {
"argument_1" : {
"dataType": "i4",
"name": "Watts",
"comparisson": "<",
"prefix": "Watts: ",
"suffix": ""
}
}
},
-
Capitalization matters. Make sure that you use uppercase and lowercase consistently.
-
I don’t know if you also have a S_Powermax.xml file describing your state variables. It might be necessary for events to work. Try steps 1-4 first.
I did most of the things you suggest. I will check again. The only thing I do not have is a S_Powermax.xml file. Is that really essential for events? Does anyone know?
I think you do need to complete the Service definition parts of your device. In your D_Powermax.xml file, what have you got at the spots marked HERE?
<service>
<serviceType>HERE</serviceType>
<serviceId>urn:viewsonic-com:serviceId:AlarmStatus1</serviceId>
<SCPDURL>HERE</SCPDURL>
</service>
I put in D_Powermax.xml
<service>
<serviceType>urn:viewsonic-com:service:AlarmStatus:1</serviceType>
<serviceId>urn:viewsonic-com:serviceId:AlarmStatus1</serviceId>
<SCPDURL>S_Powermax1.xml</SCPDURL>
</service>
now I will create an S_Powermax1.xml and see if that makes then a difference
futzle,
the S_Powermax.xml was not needed. As well, the section in D_Powermax.xml is not needed. It was the thing you described as point (2) “Your D_Powermax.xml and D_Powermax.json files have the same contents”.
However, not there yet. The Powermax now shows up in the devicelist (in events of a scene). I can pick it, the next question is “What type of trigger” and I can select “The alarm panal status has changed” but then no more fields are presented (only the back button). This actually happens as well in the Google Weather plugin where you can select weather condition but then it stops. I guess it is a problem with comparison of a string.
Solved.
The problem is that the system cannot tolerate spaces in the .json file
the code:
"allowedValueList" : {
"Awaiting Status": "Awaiting Status",
"Disarmed": "Disarmed",
"Armed (Home)": "Armed (Home)",
"Armed (Away)": "Armed (Away)"
},
must be:
"allowedValueList" : {
"AwaitingStatus": "Awaiting Status",
"Disarmed": "Disarmed",
"ArmedHome": "Armed (Home)",
"ArmedAway": "Armed (Away)"
},
That is as well the problem with the Google Weather plugin (maybe I can fix this).
http://bugs.micasaverde.com/view.php?id=1038
I haven’t changed the Weather Plugin as people have scripted against the “values” present in the fields. If you change those values to work around Bug 1038 then those scripts will be broken by the Bug Work-around.
I was not aware of the wider implications here; as well, I did not know this is a known bug I was dealing with (Will try to check these things in the future).
@utz,
Don’t sweat it, information is scattered all over the map 8)
It’s always good to have a new set of eyes looking at this stuff, and contributing new ideas/thoughts, so it’s always welcome.
Glad you got it figured out, utz. I noticed the spaces in your JSON and briefly wondered, but dismissed it as Probably Too Anal To Mention. I won’t make that mistake again…