I upgraded my home sensor network to MySensors 2.1.1 last week.
Prior to that I was having connectivity issues....I would lose nodes from the network fairly regularly.
I'm happy to say that 2.1.1 resolved all those issues and everything looks rock solid now. Haven't dropped a node since. Yay!
Would have been nice to know about the change in startup sequence for 2.1.1 (new before() method), but other than that, a very solid release.
Well done!
I upgraded my home sensor network to MySensors 2.1.1 last week.
Prior to that I was having connectivity issues....I would lose nodes from the network fairly regularly.
I'm happy to say that 2.1.1 resolved all those issues and everything looks rock solid now. Haven't dropped a node since. Yay!
Would have been nice to know about the change in startup sequence for 2.1.1 (new before() method), but other than that, a very solid release.
Well done!
@rejoe2 said in 
Temperature Sensor:
@chaeron I assume, you used an old version of the sketch.
That is correct....the original code was written over a year ago. Trying to run it under 2.1.1 caused it to fail.
Your question most likely is related to a change in the order of the initialisation. This has changed in Version 2.2: from
setup()=>presentation()
to
before()=>presentation()=>setup().
So where was this rather major change documented? It would probably have broken any 1-Wire examples, including the temperature one.
So also the initialisation of sensors had to be reviewed accordingly (eg. to get the number of devices).
So I figured out....I went looking for documentation on this rather significant change and was not able to find it noted anywhere.
I just upgraded to the MYS 2.1.1 version.
My OneWire temperature sensors were not detected!
I moved the sensors.begin() from setup() to before(), and that seems to have fixed things, and my temp sensors are being detected and read now.
Anyone know why the OneWire library has to be initialized before MySensors setup?
Thanks!
Yes....I"m using NRF24 radios at both ends.
Didn't realize they had a 3 message buffer only. That might explain it. Delays seem to help out, and since the sensors only send stuff intermittently, don't affect anything.
Sensor nodes are all based on Pro Mini's running at 3.3v, 8mhz.
I found that sending two messages consecutively, with no code between (battery % and voltage in my case) could have similar symptoms....2nd send fails. Adding a short delay seems to help this.
Thanks!
Hi:
I've got a remote sensor with 3 child sensors....temp, humidity and battery voltage.
Gateway is a ESP6266 running the MQTT sketch.
Both sensor and GW are running the latest 2.0.0 stable code base.
When the sensor node powers up it registers fine....but only successfully sends the first two presentation requests. The 3rd request (for multimeter voltage) fails for some reason.
If I put a 500 ms delay between the presentation of the 2nd and 3rd sensors, it succeeds.
Any idea what might be causing this? Is the gateway just not responding fast enough to the first two requests?
Here is the debug log from the sensor node startup, without delays, so the 3rd presentation fails. Interesting that the first registration request also fails.
Starting sensor (RNNNA-, 2.0.0)
TSM:INIT
TSM:RADIO:OK
TSP:ASSIGNID:OK (ID=104)
TSM:FPAR
TSP:MSG:SEND 104-104-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSP:MSG:READ 0-0-104 s=255,c=3,t=8,pt=1,l=1,sg=0:0
TSP:MSG:FPAR RES (ID=0, dist=0)
TSP:MSG:PAR OK (ID=0, dist=1)
TSM:FPAR:OK
TSM:ID
TSM:CHKID:OK (ID=104)
TSM:UPL
TSP:PING:SEND (dest=0)
TSP:MSG:SEND 104-104-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=ok:1
TSP:MSG:READ 0-0-104 s=255,c=3,t=25,pt=1,l=1,sg=0:1
TSP:MSG:PONG RECV (hops=1)
TSP:CHKUPL:OK
TSM:UPL:OK
TSM:READY
TSP:MSG:SEND 104-104-0-0 s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=ok:0100
TSP:MSG:SEND 104-104-0-0 s=255,c=0,t=17,pt=0,l=5,sg=0,ft=0,st=ok:2.0.0
TSP:MSG:SEND 104-104-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=ok:0
TSP:MSG:READ 0-0-104 s=255,c=3,t=15,pt=6,l=2,sg=0:0100
TSP:MSG:SEND 104-104-0-0 s=255,c=3,t=11,pt=0,l=20,sg=0,ft=0,st=ok:DHT-22 Humidity-Temp
TSP:MSG:SEND 104-104-0-0 s=255,c=3,t=12,pt=0,l=4,sg=0,ft=0,st=ok:1.04
TSP:MSG:SEND 104-104-0-0 s=0,c=0,t=7,pt=0,l=0,sg=0,ft=0,st=ok:
TSP:MSG:SEND 104-104-0-0 s=1,c=0,t=6,pt=0,l=0,sg=0,ft=0,st=ok:
!TSP:MSG:SEND 104-104-0-0 s=200,c=0,t=30,pt=0,l=0,sg=0,ft=0,st=fail:
Request registration...
!TSP:MSG:SEND 104-104-0-0 s=255,c=3,t=26,pt=1,l=1,sg=0,ft=1,st=fail:2
TSP:MSG:SEND 104-104-0-0 s=255,c=3,t=26,pt=1,l=1,sg=0,ft=2,st=ok:2
TSP:MSG:READ 0-0-104 s=255,c=3,t=27,pt=1,l=1,sg=0:1
Node registration=1
Init complete, id=104, parent=0, distance=1, registration=1
Thanks!
Thanks! I'll use that approach for all my house sensors, since right now all I send is battery percentage..
...at least until/if they add support for a I_Battery_Voltage internal value. 
Adding I_BATTERY_VOLTAGE to complement the existing I_BATTERY_LEVEL, along with a convenience function to send the voltage would be a real nice to have!
How are you sending the voltage?
Sensor = S_MULTIMETER and value = V_VOLTAGE in a normal message?
Thx!
Thanks Rod, good price on that generic unit.
The specs say the output is 28VDC....so wouldn't I have to add a circuit to drop the voltage to 5v or 3.3 V before tying it into a 'duino pin?