I really don't know best practices for setting up devices and what the json should look like. I have, however, completely the polling of the apcaccess device. Here is the snippet:
I wrote some stuff into a light sensor as per Futzle's suggestion. I have no idea how to make those cool battery icons. [...] If someone at a high level can sketch out the proper way to do the device let me know.
That's a pretty good start. Here's a few recommendations:
It's allowed (I'd even say it's desirable) to use multiple service IDs in your device. Pick and choose from among the standard services for things that match up. For stuff that doesn't match any existing service, invent your own service ID. For stuff that does match an existing service (LightSensor has CurrentLevel, for example), set the variable twice: once with your service ID and once with the out-of-the-box service ID. Examples:
-- Set battery level. First is for my code to use, second is for battery icon in dashboard.
-- (The string urn:micasaverde-com:serviceId:HaDevice1 is magical.)
-- Set load. First is for my code to use, second is to masquerade as a light sensor.
-- Set online status. First is to masquerade as a binary switch, second is for my code to use.
(currentStatus == "ONLINE") and 1 or 0, CURRENT_APC_DEVICE)
-- No common service knows of this type. Just set the variable in my namespace.
As Ap15e says, everyone just copies-and-pastes device files. My usual sequence when making a brand-new device is:
1. Write a stub D_APCUPSBackup1.xml file. Copy and paste it from an existing device, changing: deviceType
. Empty out the serviceList
. Point staticJson
to a not-yet-existing D_APCUPSBackup1.json file. We'll make that later.
2. Write a simple I_APCUPSBackup1.xml file. Put your Lua in it. Leave most of the other sections empty.
(By this point you will be able to create a device from this file, see its log output in the Luup log, and see its variables in the Advanced tab. You can debug your Lua until you are happy that the variables are getting set properly. The dashboard will have a default device box, and you won't have any events or notifications.)
3. Write the D_APCUPSBackup1.json Static JSON file. Again, copy and paste from an existing device, or read my reverse-engineering notes
on the wiki. Leave eventList
empty for the moment. While debugging, if you need to make changes to the Static JSON file, you need to restart the Luup engine and
clear your browser's cache.
(By this point you will have a customized device appearance in the dashboard. Whatever status you've opted to include in the dashboard will update every thirty seconds, and if you've defined any tabs in the static JSON file, they'll appear too.)
If all you care about is read-only viewing of the UPS status, you can stop now.
4. Define events in the static Json file. I haven't written the reverse-engineering notes for this section yet, so copy from something already present, or let us help you write them. Events are what can trigger scenes and notifications.
(By this point you will have the ability for the plugin to trigger a scene when, say, the UPS goes onto battery, or when the load goes over a certain percentage, or whatever other events you've defined.)
5. Go back to the D_APCUPSBackup1.xml file and fill out the serviceList
section. For each service Id you've ever mentioned, put in a service
section. If you follow my examples above you'll have four. Three will mention S_*.xml files that already exist. For the fourth, invent a name (say, S_UPS1.xml) and match it against your urn:kristopher:serviceId:UPS1 service Id.
(You won't notice anything different in the UI, but anyone using "watch variable" or other introspection will be able to act on your status variables changing.)
6. Write the S_UPS1.xml file. Include any variables that you have mentioned in the urn:kristopher:serviceId:UPS1 service namespace. If you want to define any actions (for the UPS, acting on an interrupt when the UPS suddenly goes off battery would be a good one), put them in.
(Again, no UI difference, but now you can interact with the device over HTTP, and things like the dataMine plugin will be able to plot your device's variables over time.)