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.
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.
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.
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>
@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.
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.
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?
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
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