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?
@Anticimex said:
Ok. I'd like to have something more precise in my home. Otherwise my automatic sentry gun might target the wrong area
LOL....good one!
If I miss with the .45 ACP, and my wife misses with her .38, and the dogs don't rip the baddies to pieces, it's likely the cats will claw them to death and leave the bits in their litter boxes, so I'm not worried.
With 7 sensors spread around the house, which I've built all myself and which include thermostat (https://github.com/chaeron/thermostat), and MySensors-based temp, humidity, barometer and water level sensors, my own little Skynet will soon be ready for the Singularity! 
I want a pre-made sound-based glass break sensor, so that actually makes it easier, since then it comes pre-calibrated and all you get out the back end is a "tripped" signal that can go on a single Arduino pin.
As I said, the Glasstrek unit might be usable for such an interface. You can get them under $20 each, and a couple or three would cover the whole house.
How would that help? Unless you attach it to the glass, which means I would need a few dozen for all the glass in my house, and that ain't happenin'.....too much hassle and looks ugly as well.
I was hoping to find a pre-made sonic glass break sensor and just interface it to the arduino.
Might try to rework a Glasstrek 456 sensor and see if it can be tied to a microprocessor like the duino with an RF radio attached. It has relay outputs, and if those don't work, maybe tie into an indicator LED for an output signal.
I should have mentioned that I was looking for a sound-based glass break sensor, since then one sensor can cover many windows/doors.
A vibration sensor won't cut it for what I'm trying to do, but thanks for the link. Interesting application.
Has anyone implemented a glass break sensor?
I'ld like to implement a few for my home, but haven't found any info on how to do this with an Arduino as the microcontroller, nor what kind of sensor to use for this.
Thanks!
Thanks for the explanation of inclusion mode. Much appreciated.
I thought some of the gateway sketches did allocate node id's....but that for some reason the MQTT Client gateway didn't.
No big deal....I don't want to use a 3rd party controller, so will just hard code the id's for now.
Clarification: I'm using the MQTT ESP8266 Client gateway sketch with an external MQTT broker running on a Pi.
Not sure why it doesn't support allocation of node ids....
I have a few questions about gateways that I haven't managed to find answers to.
What is "inclusion mode"?
I'm running an MQTT Gateway on an ESP8266. It seems to be running fine and communicating with my Humidity sensor. However, I had to hardcode the MY_NODE_ID on the sensor. Does the MQTT ESP8266 gateway sketch not support automatic allocation of node ids?
Thanks all!
True enough on using MS a bit differently than most.
But, IMO, that does not excuse the lack of documentation on the actual on the wire messages and protocols (message sequences from sender to recipient). The most important thing is not always the implementation (sketches, pre-done code, examples), but documentation of the underlying protocols, so that you can integrate other capabilities and approaches.
'nuff said on that.
Check out the thermostat project that I built with a Raspberry Pi 2 and the new 7" touchscreen....this is what has gotten me interested in IoT, and the sensor world:
https://github.com/chaeron/thermostat
The code could be better (what code couldn't), but given it's a personal project and time was limited, I think the docs and the code is pretty decent and easy to figure out if you have the right background (Python, Kivy UI framework, etc.). Been running flawlessly for about a month now. Even emits detailed logging info over MQTT....and accepts a few commands over MQTT.
Once I get my home sensor network built and running, based on MS and arduinos, I'm gonna use the secondary Pi to reformat the sensor MQTT messages to something a bit more semantically useful (room designators instead of numbers for temperature sensors around the house), and maybe implement some sort of weighted averaging for HVAC control of house temperatures.
All fun stuff!
As for why I don't want an extra gateway, I explained that in my original post, though that is the path I'm going down for now.
There are some techniques that you can use on the Pi and some libraries (using DMA techniques) that can overcome the mutitasking issue.
"Code is documentation"?
Interesting concept....extremely rarely found in the wild.
I've been in the software business for more decades than most of the people on this board who are hacking sensors and such, I'll bet. And most code is abysmal to read. People use short identifiers (a, b, c, xyz) instead of more informative ones. Control structures look more like spaghetti than anything comprehensible, and comments, if any, are usually useless.
It's been said that working on someone else's code is like wearing someone else's used underwear, and just about as pleasant!
But that is what I'll have to do...just to understand the MQTT messages as well, though those are simpler from what I've seen of the API and serial protocol documentation.
Thanks...but that is not what I'm looking for. The document you mentioned (Serial API) I was aware of. This documents the protocol/messages between the Gateway and the Controller over a serial connection.
What I am looking for is are the message definitions and protocols for sensor to Gateway communications!
Looking like I'll have to reverse engineer this from the code. <sigh>
Is there any documentation on the communications protocol used between the sensors and a gateway?
That is, messages, typical flow (eg. request/response), etc?
Or do I have to figure out the protocol by reading the code that implements this?
Reason I ask is that I want to eliminate the need for a separate Arduino-based gateway between the sensors and my Raspberry Pi 2. It seems silly to have an extra piece of hardware in the middle (more to go wrong and more latency), when you can easily connect a NRF24L01+ to a rPi. Don't want a full-blown controller....just a gateway that talks MQTT on the back end.
Basically what I want is an ESP8266 Wifi MQTT gateway, but running on an rPi, not an ESP8266.
I'm willing to write such a gateway for the rPi (likely in Python). Having the specs for the sensor to gateway protocol would go a long way to making that happen.
Thanks!
