Hi guys. I’m got a sample project in mind and it should be easy. Basically I want to reproduce the “MimoLite Garage App”. Not all of it, just the “sensor” part. So basically I just want to create a very simple app that does this:
- When the Mimolite sensor is “Tripped” a message is displayed on the “device” panel (door is open).
- When the Mimolite sensor is “Closed” a message is displayed on the “device panel” (door is closed).
This is just for learning. So some of my questions are:
[ul][li]
What files do I have to create to get all this going? I see lots of XML files and Luup files, but I’m not sure how to get started. I assume the XML files tell the mimo engine about the luup code. I assume there is a startup function, etc.
[/li]
[li]
What do I have to define in those XML files?
[/li]
[li]
How do I register a “callback” when the Tripped event comes back from the Mimolite device. It’s a variable update. I see in the log it gets stuff like this from the mimolite “Device_Variable::m_szValue_set device: 4 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: Tripped was: 1 now: 0”
So basically I want to somehow register for that event and then update the “Device Panel” with a message. In this case, door closed.
[/li]
[li]
Then I guess, how do I update the “Device Panel”. And how did I create a custom device panel in the first place? I assume I have to define some HTML or something? I know that the existing Garage Controller App has the user update the existing device under “Advanced”. I had to change the device_file and “device_type”. That’s fine for now with this test app too. I can just refer to a custom version of those. Hmm. I’m starting to see that I can probably just look at those existing files from the “Garage Controller App” to see maybe what to do.
[/li][/ul]
Anyhow. Any advice? I tried looking for some sort of “hello world” that ties all this together, but wasn’t really finding it.
Thanks.
Hmm. It looks like I can just view the mimolite Garage App source. I’ll start with that I suppose.
There are some (rather fragmented) guides to developing plugins. Start here. It is often fastest to use an existing plugin, with similar functionality, as a prototype.
Generally a plugin may need four files:
The Device file (D_Name.xml). This defines your device to Vera. If you are creating a new device, it should have a unique device_type using your own urn. Changes to this file will affect all devices that use it. This file references the other three.
The Service file (S_Name.xml). This defines the services and state-variables that are unique to your device. It is not necessary to define existing or standard services. If you only require existing services, you may not need a custom Service file.
The Implementation file (I_Name.xml). This contains the code that implements the device. It must include a start-up function, provide communication with the hardware and support all required actions. It may also refer to additional files containing Lua code.
The UI file (D_Name.json). This defines the look and behavior of the device tile. It may also refer to additional files containing javascript.
Sometimes you can achieve what you want simply by changing the Implementation code. In this case it would not be necessary to create a new device_type or the other files. You can specify the Implementation file to be used when you create a device or through the Advanced tab.
[quote=“RexBeckett, post:3, topic:180359”]There are some (rather fragmented) guides to developing plugins. Start here. It is often fastest to use an existing plugin, with similar functionality, as a prototype.
Generally a plugin may need four files:
The Device file (D_Name.xml). This defines your device to Vera. If you are creating a new device, it should have a unique device_type using your own urn. Changes to this file will affect all devices that use it. This file references the other three.
The Service file (S_Name.xml). This defines the services and state-variables that are unique to your device. It is not necessary to define existing or standard services. If you only require existing services, you may not need a custom Service file.
The Implementation file (I_Name.xml). This contains the code that implements the device. It must include a start-up function, provide communication with the hardware and support all required actions. It may also refer to additional files containing Lua code.
The UI file (D_Name.json). This defines the look and behavior of the device tile. It may also refer to additional files containing javascript.
Sometimes you can achieve what you want simply by changing the Implementation code. In this case it would not be necessary to create a new device_type or the other files. You can specify the Implementation file to be used when you create a device or through the Advanced tab.[/quote]
Thank you. Wow it’s pretty cryptic. I’m used to writing tons of C/C++/HTML stuff. This stuff is as you say “fragmented”.
So are there “approved” file names or something? For example, “D_MimoLiteGarageDoor.xml” refers to a file called “S_SecuritySensor1.xml”. I guess my questions would be something like:
- How can I tell whether the author created the file “S_SecuritySensor1.xml” as part of his app or if it’s a canned file? I’m assuming the latter, but not sure really. Is there a list of canned files somewhere?
- How did the author come up with “D_MimoLiteGarageDoor.xml”? Are these all approved somehow? Seems a bit whacky to rely on file names for uniqueness.
I don’t know…I’ll keep plowing…
S_XXXX files can be re-used and define the equivalent of Interfaces.
i.e. there are standard service definition for a On/Off switch … but many implementations (i.e. Z-Wave, Virtual …)
The D_XXXX and I_XXXX files are typically associated with a device type (Something that has a new UI and behavior).
XXXX can be any name you want that no one else is currently using … The App Store enforces this. It’s usually related to the DeviceType and ServiceIds used in the definition and interface files.
If you can live with the old UI and only need to provide a I_ZZZZ file that provides a new implementation that conforms to the existing UI (defined in D_XXXX.json) and service implementation in S_XXXX.xml files.