Arduino Due as a sensor

[ricott]

Hi,

Im new to the arduino plattform but starting to dig in. I intend to build the usual sensors to monitor power, water, temp, wind, etc - this seems rather straight forward thanks to all your work.
I have two challenges

• IVT air->water heater rego800
• Visonic Powermaster alarm

The IVT rego800 I have already solved, hopefully the hard part, using an Arduino due and a can board, it is then capable of the can bus protocol. Decoding can bus IDs thankfully other people had already done so I can now check 8 different temperature sensors and 9 "relays" that I would like to report the status on.
How would you go about hooking up the due as a sensor? Would the NRF24L01+ radio work with the due and the rest of the mysensors code?

The second challenge, which I haven't started to look at yet, is the powermaster alarm. I know there is a vera plugin for controlling the alarm so there is one place to start. This I will probably save for last so no rush here.

And for controller I haven't decided. I want good graph support since most of my sensors will just log data.

Regards,
Richard

[Zeph]

The TMRh20 rf24 library used by MySensors is supposed to work on the Due, and I suspect the rest of the library should work as is or with little effort - but that's not a fact until tested.

[epierre]

@ricott said:

nd for controller I haven't decided. I want good graph support since most of my sensors will just log data.

same opinion, I managed to make it running in Mega, radio pins are a little bit different, gateway initialisation a little bit different...

[ricott]

Spent some time programming my own (yet another?) mysensors -> mysql using java. Seems to work fine for temp and humidity that I have tested.

Regarding Due as a sensor, seems there is a show stopper - there is no EEPROM on the Due.
Will probably look into, due -> mini/nano with mysensors, anyone tried this with good result?

[Yveaux]

@ricott said:

seems there is a show stopper - there is no EEPROM on the Due.

Correct me if I'm wrong @hek, but Eeprom is used to store parent Id and node Id. If you can live with fixed ids or ids that are not persistent over power cycles then you can do without eeprom.

[hek]

@Yveaux

Yes. Should work fine. But do enable repeaterMode, it won't work.

[ricott]

Thanks, will perhaps give that a go anyways then.
Right now Im' doing I2C between the Due and a Nano. Struggling with sending float values, plain strings are fine. Cant tell if it is related to difference in number of bytes used to represent a float/double, Due use 8 bytes. I'll use strings and convert back to float on the nano before sending it to mysensors.

[Yveaux]

@ricott make both float. Float and double are 4 bytes on AVR.

[ricott]

@Yveaux Sorry for my sloppy wording. Float and double are 8 bytes on the Due (64 bit), but as you say 4 bytes on the other platforms. http://arduino.cc/en/Reference/Double

Is there some limitation to how many sensors a single node / radio can have? Thinking of limits in performance somehow and dropped messages.
I have I2C working now and have 19 sensors (child-sensor-id) defined. But I have some problems with radio not presenting all sensors to the gateway. Distance between sensor and gateway doesn't seem to matter since it doesn't work when they are 1 meter apart. To try and solve it I started fiddling with delays in the setup method.
Now all sensors are always presented but I see that they are not presented in the correct order (0->18), at least not to the serial port. I guess one shouldn't use delay in the setup method?

Now leaning towards using a cable for this particular sensor due to its nature, not really a standard one.

[Yveaux]

@ricott said:

Float and double are 8 bytes on the Due (64 bit)

Don't think so... Float is 4 bytes on due, double is 8 according to the arduino site (when in doubt, print a sizeof(double))

I don't think there's a limit on the number of sensors, except for the unique number of sensor id's you can assign.
What I can imagine is that some of the presentation messages get lost and are therefore not seen by the gateway. They can get lost due to bad reception, or maybe the due just sends them too fast for the gateway.

Is the list of sensors reported different each time you restart your sensor node?

[ricott]

Thanks for your time on this
Clearing eeprom and reflashing both gateway and sensor gave this on a fresh start. So perhaps there were some corruption before.
No Due involved, no delay in setup method. I see my second reply (remember I coded gw by myself) to the unit request is not immediately after the request, could this be a problem? I have an async (FIFO queue) handler for what is coming in on the serial port - didn't want this to be the bottle neck due to db updates. All printouts below, except for the replies, are however before message is passed to the async handler - straight off serial port.

No reset or anything, don't know why it started a second round of presentation, and this second time stopped on id 14.

Seen on controller serial port
<code>
INFO: 0;0;3;0;9;read: 255-255-255 s=255,c=3,t=7,pt=0,l=0:
INFO: 0;0;3;0;9;send: 0-0-255-255 s=255,c=3,t=8,pt=1,l=1,st=fail:0
INFO: 0;0;3;0;9;read: 255-255-0 s=255,c=3,t=3,pt=0,l=0:
INFO: 255;255;3;0;3;
INFO: About to send: 255;255;3;0;4;1 (sent from async handler)
INFO: 0;0;3;0;9;send: 0-0-255-255 s=255,c=3,t=4,pt=0,l=1,st=fail:1
INFO: 0;0;3;0;9;read: 1-1-0 s=255,c=0,t=17,pt=0,l=3:1.4
INFO: 1;255;0;0;17;1.4
INFO: 0;0;3;0;9;read: 1-1-0 s=255,c=3,t=6,pt=1,l=1:255
INFO: 1;255;3;0;6;255
INFO: About to send: 1;255;3;0;6;M (sent from async handler)
INFO: 0;0;3;0;9;read: 1-1-0 s=255,c=3,t=11,pt=0,l=10:IVT Sensor
INFO: 1;255;3;0;11;IVT Sensor
INFO: 0;0;3;0;9;send: 0-0-1-1 s=255,c=3,t=6,pt=0,l=1,st=ok:M
INFO: 0;0;3;0;9;read: 1-1-0 s=255,c=3,t=12,pt=0,l=3:1.0
INFO: 1;255;3;0;12;1.0
INFO: 0;0;3;0;9;read: 1-1-0 s=0,c=0,t=6,pt=0,l=3:1.4
INFO: 1;0;0;0;6;1.4
INFO: 0;0;3;0;9;read: 1-1-0 s=1,c=0,t=6,pt=0,l=3:1.4
INFO: 1;1;0;0;6;1.4
INFO: 0;0;3;0;9;read: 1-1-255 s=255,c=3,t=7,pt=0,l=0:
INFO: 0;0;3;0;9;send: 0-0-1-1 s=255,c=3,t=8,pt=1,l=1,st=ok:0
INFO: 0;0;3;0;9;read: 1-1-0 s=2,c=0,t=6,pt=0,l=3:1.4
INFO: 1;2;0;0;6;1.4
INFO: 0;0;3;0;9;read: 1-1-0 s=3,c=0,t=6,pt=0,l=3:1.4
INFO: 1;3;0;0;6;1.4
INFO: 0;0;3;0;9;read: 1-1-0 s=4,c=0,t=6,pt=0,l=3:1.4
INFO: 1;4;0;0;6;1.4
INFO: 0;0;3;0;9;read: 1-1-0 s=5,c=0,t=6,pt=0,l=3:1.4
INFO: 1;5;0;0;6;1.4
INFO: 0;0;3;0;9;read: 1-1-0 s=6,c=0,t=6,pt=0,l=3:1.4
INFO: 1;6;0;0;6;1.4
INFO: 0;0;3;0;9;read: 1-1-0 s=7,c=0,t=6,pt=0,l=3:1.4
INFO: 1;7;0;0;6;1.4
INFO: 0;0;3;0;9;read: 1-1-0 s=8,c=0,t=6,pt=0,l=3:1.4
INFO: 1;8;0;0;6;1.4
INFO: 0;0;3;0;9;read: 1-1-0 s=9,c=0,t=6,pt=0,l=3:1.4
INFO: 1;9;0;0;6;1.4
INFO: 0;0;3;0;9;read: 1-1-0 s=10,c=0,t=3,pt=0,l=3:1.4
INFO: 1;10;0;0;3;1.4
INFO: 0;0;3;0;9;read: 1-1-0 s=11,c=0,t=3,pt=0,l=3:1.4
INFO: 1;11;0;0;3;1.4
INFO: 1;12;0;0;3;1.4
INFO: 0;0;3;0;9;read: 1-1-0 s=13,c=0,t=3,pt=0,l=3:1.4
INFO: 1;13;0;0;3;1.4
INFO: 0;0;3;0;9;read: 1-1-0 s=14,c=0,t=3,pt=0,l=3:1.4
INFO: 1;14;0;0;3;1.4
INFO: 0;0;3;0;9;read: 1-1-0 s=15,c=0,t=3,pt=0,l=3:1.4
INFO: 1;15;0;0;3;1.4
INFO: 0;0;3;0;9;read: 1-1-0 s=16,c=0,t=3,pt=0,l=3:1.4
INFO: 1;16;0;0;3;1.4
INFO: 0;0;3;0;9;read: 1-1-0 s=17,c=0,t=3,pt=0,l=3:1.4
INFO: 1;17;0;0;3;1.4
INFO: 0;0;3;0;9;read: 1-1-0 s=18,c=0,t=3,pt=0,l=3:1.4
INFO: 1;18;0;0;3;1.4
INFO: 0;0;3;0;9;read: 1-1-0 s=255,c=0,t=17,pt=0,l=3:1.4
INFO: 1;255;0;0;17;1.4
INFO: 0;0;3;0;9;read: 1-1-0 s=255,c=3,t=6,pt=1,l=1:0
INFO: 1;255;3;0;6;0 <<<------ Second unit request
INFO: 0;0;3;0;9;read: 1-1-0 s=255,c=3,t=11,pt=0,l=10:IVT Sensor
INFO: 1;255;3;0;11;IVT Sensor
INFO: 0;0;3;0;9;read: 1-1-0 s=255,c=3,t=12,pt=0,l=3:1.0
INFO: 1;255;3;0;12;1.0
INFO: 0;0;3;0;9;read: 1-1-0 s=0,c=0,t=6,pt=0,l=3:1.4
INFO: 1;0;0;0;6;1.4
INFO: 0;0;3;0;9;read: 1-1-0 s=1,c=0,t=6,pt=0,l=3:1.4
INFO: 1;1;0;0;6;1.4
INFO: 0;0;3;0;9;read: 1-1-0 s=2,c=0,t=6,pt=0,l=3:1.4
INFO: 1;2;0;0;6;1.4
INFO: 0;0;3;0;9;read: 1-1-0 s=3,c=0,t=6,pt=0,l=3:1.4
INFO: 1;3;0;0;6;1.4
INFO: 0;0;3;0;9;read: 1-1-0 s=4,c=0,t=6,pt=0,l=3:1.4
INFO: 1;4;0;0;6;1.4
INFO: 0;0;3;0;9;read: 1-1-0 s=5,c=0,t=6,pt=0,l=3:1.4
INFO: 1;5;0;0;6;1.4
INFO: About to send: 1;255;3;0;6;M (sent from async handler)
INFO: 0;0;3;0;9;read: 1-1-0 s=6,c=0,t=6,pt=0,l=3:1.4
INFO: 1;6;0;0;6;1.4
INFO: 0;0;3;0;9;read: 1-1-0 s=7,c=0,t=6,pt=0,l=3:1.4
INFO: 1;7;0;0;6;1.4
INFO: 0;0;3;0;9;read: 1-1-0 s=8,c=0,t=6,pt=0,l=3:1.4
INFO: 1;8;0;0;6;1.4
INFO: 0;0;3;0;9;read: 1-1-0 s=9,c=0,t=6,pt=0,l=3:1.4
INFO: 1;9;0;0;6;1.4
INFO: 0;0;3;0;9;read: 1-1-0 s=10,c=0,t=3,pt=0,l=3:1.4
INFO: 1;10;0;0;3;1.4
INFO: 0;0;3;0;9;read: 1-1-0 s=11,c=0,t=3,pt=0,l=3:1.4
INFO: 1;11;0;0;3;1.4
INFO: 0;0;3;0;9;read: 1-1-0 s=12,c=0,t=3,pt=0,l=3:1.4
INFO: 1;12;0;0;3;1.4
INFO: 0;0;3;0;9;read: 1-1-0 s=13,c=0,t=3,pt=0,l=3:1.4
INFO: 1;13;0;0;3;1.4
INFO: 0;0;3;0;9;read: 1-1-0 s=14,c=0,t=3,pt=0,l=3:1.4
INFO: 1;14;0;0;3;1.4
INFO: 0;0;3;0;9;read: 1-1-0 s=15,c=0,t=3,pt=0,l=3:1.4
</code>

As seen on the sensors serial port
<code>
sensor started, id 1
send: 1-1-0-0 s=255,c=0,t=17,pt=0,l=3,st=ok:1.4
send: 1-1-0-0 s=255,c=3,t=6,pt=1,l=1,st=ok:0
send: 1-1-0-0 s=255,c=3,t=11,pt=0,l=10,st=ok:IVT Sensor
send: 1-1-0-0 s=255,c=3,t=12,pt=0,l=3,st=ok:1.0
send: 1-1-0-0 s=0,c=0,t=6,pt=0,l=3,st=ok:1.4
send: 1-1-0-0 s=1,c=0,t=6,pt=0,l=3,st=ok:1.4
send: 1-1-0-0 s=2,c=0,t=6,pt=0,l=3,st=ok:1.4
send: 1-1-0-0 s=3,c=0,t=6,pt=0,l=3,st=ok:1.4
send: 1-1-0-0 s=4,c=0,t=6,pt=0,l=3,st=ok:1.4
send: 1-1-0-0 s=5,c=0,t=6,pt=0,l=3,st=ok:1.4
send: 1-1-0-0 s=6,c=0,t=6,pt=0,l=3,st=ok:1.4
send: 1-1-0-0 s=7,c=0,t=6,pt=0,l=3,st=ok:1.4
send: 1-1-0-0 s=8,c=0,t=6,pt=0,l=3,st=ok:1.4
send: 1-1-0-0 s=9,c=0,t=6,pt=0,l=3,st=ok:1.4
send: 1-1-0-0 s=10,c=0,t=3,pt=0,l=3,st=ok:1.4
send: 1-1-0-0 s=11,c=0,t=3,pt=0,l=3,st=ok:1.4
send: 1-1-0-0 s=12,c=0,t=3,pt=0,l=3,st=ok:1.4
send: 1-1-0-0 s=13,c=0,t=3,pt=0,l=3,st=ok:1.4
send: 1-1-0-0 s=14,c=0,t=3,pt=0,l=3,st=ok:1.4
send: 1-1-0-0 s=15,c=0,t=3,pt=0,l=3,st=ok:1.4
send: 1-1-0-0 s=16,c=0,t=3,pt=0,l=3,st=ok:1.4
send: 1-1-0-0 s=17,c=0,t=3,pt=0,l=3,st=ok:1.4
send: 1-1-0-0 s=18,c=0,t=3,pt=0,l=3,st=ok:1.4
read: 0-0-1 s=255,c=3,t=6,pt=0,l=1:M
</code>

[ricott]

Hmmmm, clicking reset on sensor shows this as a start

INFO: 1;15;0;0;3;1.4
INFO: 0;0;3;0;9;read: 1-1-0 s=16,c=0,t=3,pt=0,l=3:1.4
INFO: 1;16;0;0;3;1.4
INFO: 0;0;3;0;9;read: 1-1-0 s=17,c=0,t=3,pt=0,l=3:1.4
INFO: 1;17;0;0;3;1.4
INFO: 0;0;3;0;9;read: 1-1-0 s=18,c=0,t=3,pt=0,l=3:1.4
INFO: 1;18;0;0;3;1.4

Meaning what was missing from last presentation.

plus rest of messages that was supposed to be seen, minus id 18 only this time.
Clicking reset again shows id 18 in first batch of next messages.

Bugs in serial port driver, gateway not releasing messages correctly to controller. Im on windows (now when developing), I guess I could try it on my ubuntu server - where I will deploy once developed.

[ricott]

Sorry for spamming, but this was nagging me so I had to solve it

Stupidly I trusted the code from http://playground.arduino.cc/interfacing/java, which was using a BufferedReader - suspected this already yesterday when I noticed the behaviour. Using more code of my own reading straight off input stream and handling message termination myself solved problem. Now I see the expected on the serial input, in the correct sequence.

[ricott]

Im a happy camper

A beer later and a yield call in wrong place. Some more delays added on the Due side when sending data over I2C to the Nano, which is acting as a node for these 19 sensors, and all works fine. Without delays on the Due for the wire code I was always missing some values.
No delays in the mysensors code needed for handling 19 sensors on a single radio.