I'm working on a new plugin for home built Arduino sensors that transmits data to Vera using the nRF24L01 radio chip. Initially I will only send data one-way (to Vera) but there is really nothing stopping two-way communication (or even building mesh networks of sensors like z-wave).

I would like to design it to keep the changes to a minimum in the ReceiverSketch (running on the Arduino attached to Vera) and Vera plugin if possible.

For this to work it would be nice if the sensors could present them self to the ArduinoSensorPlugin with all information needed to create them automatically in Vera (like Device/implementation descriptor files etc).

The sensors could the only has two types of messages:Presentation Data: Always sent when they are powered up. Contains all info needed to create the device in Vera including a unique Id to identify and transmit data to sensor (pipe-id).Sensor Data: Sent when sensor data is changed.

The VeraReceiver sketch will only relay messages coming on the radio bus to the usb-serial interface which is read by the ArduinoSensorPlugin in Vera.

So.. the question is.. Is it best to keep the different sensor in child devices of the ArduinoSensorPlugin... or is it better to real devices? As stated above.. I would lite to keep changes to a minimum in the VeraReceiverPlugin and move all logic (specific implementation details) to the "child" plugins. This way someone can create a new Arduino sketch for a new sensor and upload the corresponding device files for it in vera.

My initial thought would be to keep all Vera-specific service/device/JSON implementation within your distributed plugin, because your radio-accessed nodes are really very far removed from those implementation details. Instead, develop a spec for communicating metadata and data between your devices and to the plugin, and have the plugin you distribute translate that spec into Vera-specific glue code as the sensors are discovered and managed. I see the value in what you are proposing -- to have everything load up dynamically without ever needing plugin changes, but I think the reality is that this architecture calls for its own internal interface spec, while the plugin's sole job is to expose those devices in the Vera-specific way.

The analogy with Z-Wave is apt -- the Z-Wave nodes have their own protocol, but Vera translates it all into the single, unified Lua-UPnP interface.

I'm thinking the approach I used in the Nest and Ecobee thermostat plugins might fit your purposes well, where every polling cycle the plugin interrogates its web service for all the devices it knows, and the plugin will add or remove child devices based on that discovery (which then triggers a Luup restart). That way, no manual discovery step is needed, as long as the Arduino device that the plugin is dialoguing with is maintaining a current set of known sensors.

So you would have an "Arduino" device object -- the manager object -- and all sensor device objects would be created or destroyed as they appear or disappear from the set of sensors that the Arduino is aware of. The one "I_Arduino.xml" (or whatever you call it) implementation file would contain all the glue code and service implementations to translate how the Arduino reports its devices and what they know/can do, into the Lua-UPnP format required by Vera.

As I learned writing the Nest plugin, the Vera only has a single hierarchy of parent/child devices (not multiple levels), with the thought behind it being a manager/slaves model. So any nesting of sensors within sensors or the like really doesn't have an analogy in Vera. Complex interrelations between managed objects, like you might have in JMX or CIM, don't exist in Vera.

I know this misses the mark on having a completely self-describing and fully dynamic way of bringing new sensors online, but I think there would be so many other obstacles to pulling this off that you might be better off writing your spec (transmitted in JSON or some other easy format), and then having the plugin just focus on the glue logic.

I'm thinking the approach I used in the Nest and Ecobee thermostat plugins might fit your purposes well, where every polling cycle the plugin interrogates its web service for all the devices it knows, and the plugin will add or remove child devices based on that discovery (which then triggers a Luup restart). That way, no manual discovery step is needed, as long as the Arduino device that the plugin is dialoguing with is maintaining a current set of known sensors.

Most of my sensors will be sleeping most of the time to save battery (and I will turn off the radio). So I cannot contact them (poll). Isn't it better to let Vera keep the list of known devices (which will be the child devices). If a new sensor pops up it will present itself (fist message sent when started) which will create a new child device (and Luup restart). Don't really see the point of storing a list of devices in the receiving/inteface Arduino aswell (this will keep receiver sketch as simple as possible).

So you would have an "Arduino" device object -- the manager object -- and all sensor device objects would be created or destroyed as they appear or disappear from the set of sensors that the Arduino is aware of. The one "I_Arduino.xml" (or whatever you call it) implementation file would contain all the glue code and service implementations to translate how the Arduino reports its devices and what they know/can do, into the Lua-UPnP format required by Vera.

As I learned writing the Nest plugin, the Vera only has a single hierarchy of parent/child devices (not multiple levels), with the thought behind it being a manager/slaves model. So any nesting of sensors within sensors or the like really doesn't have an analogy in Vera. Complex interrelations between managed objects, like you might have in JMX or CIM, don't exist in Vera.I know this misses the mark on having a completely self-describing and fully dynamic way of bringing new sensors online, but I think there would be so many other obstacles to pulling this off that you might be better off writing your spec (transmitted in JSON or some other easy format), and then having the plugin just focus on the glue logic.

Ok, so a flat structure below receiver plugin then... Will use the altid to keep track of sub-child devices.

Thanks for your help and feedback.

Anyone else is also free to join in the discsussion.

------------

Code says more that 1000 words. This is an example sketch for a Temperature Sensor

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License version 2 as published by the Free Software Foundation.

DESCRIPTION The VeraReciever is quite dumb. Only sends out the data received from sensors on the serial bus (which will be picket upp by Vera and processed). So the logic is placed in Vera plugn and the sensors.

MESSAGE FORMAT The mesages sent by sensors has the following format. The data is a regualar ascii string (no binary data). End message with newline character "\n".

RadioId;Subid;Var1=Data1;Var2=Data2;...\n

Id = Unique if of sensor (uint64_t) - Same as pipe if sensor is awake and listening for commands Subid = If several senosrs ir reporting information from this device. This id is unque per sensor. Var1 = Data1, Var2 = Data2, ... Sensor data. Can be different for each type of sensor. Must be in sync with Vera plugin.

For the physical connection between the Vera and the Arduino, you're just using the USB cable that communicates a serial stream, correct? Does it matter which Arduino model you're using? Does it work with the Arduino UNO? I seem to recall that some Arduino models had an FTDI chip while others did not. I was curious what would work with the Vera 3.

I have been working on a similar idea for a while now. I decided to go with Teensy, an Arduino compatible device and XBees. I have a Raspberry Pi as a Ethernet to XBee gateway. This allows my Vera Lite to do simple communicate with my Teensys via TCP/IP and let the Raspberry handle the hard stuff.

My first device is an LED strip to light up my stairway. The Teensy which is at the bottom of the stairs, has a motion detector and ambient light sensor and controls the LED brightness via PWM and a mosfet to handle the power for the LEDS. At the top of the stairs I have a Z-Wave motion detector.

The Raspberry and Vera work together to handle lighting based on motion and time of day.

In the works is a soil moisture and temperature sensor for my garden.

Anyway, my point is I am letting the Raspberry handle of a lot of the work using PERL as my programming language, which is just easier for me, as apposed to LUA on the Vera Lite.

My idea was to create the cheapest possible wireless sensors and minimize the Vera plugin development. You could possibly reuse the arduino library I developed on your Teensy sensor if you use the same transceiver.

That bit is not quite ready yet... but sure it is possible. I will create a relay sketch when the stuff hardware arrives. It will accept commands from vera side (on/off) and ack that the command has reached the relay.

Note that the sensors that receives data probably cannot be battery driven as they will consume too much power when radio is always on.

@watouYes that would probably preferable. I don't think the Vera can have this logic in the plugin part. I'm a bit worried about having too large buffers with unsent data hanging around in the "attached nano" (hereafter called ArduinoGateway) though.

Maybe the ArduinoGateway could timeout messages after 2-3 minutes back to vera plugin.

And when a sleeping node wakes up it could probably poll the ArduinoGateway for new commands.