Sensor to Gateway protocol documentation?
-
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!
-
Hi!
Is this what you are looking for? http://www.mysensors.org/download/serial_api_15
Also have a look here: http://forum.mysensors.org/topic/2437/step-by-step-procedure-to-connect-the-nrf24l01-to-the-gpio-pins-and-use-the-raspberry-as-a-serial-gateway
-
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>
-
I'm curious why you're against having a gateway. One of the good reasons to use one is that the RPI is not a real time OS and has a non-trivial chance of losing radio messages since the process to read from the radio may or may not be running while the messages come in. The more applications you start on the pi, the more likely you'll be too lose messages which will be frustrating and hard to debug, especially since it will be intermittent. A gateway is a cheap, easy way to avoid this.
If you read the docs http://www.mysensors.org/download/sensor_api_15, the library API is the MyMessage class. The class is the protocol. For an example (using v1.5), look at MySensor::sendWrite() and you'll see it calls radio.send( &message, ... ) so it's sending the message class as the data over the radio link.
-
"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.
-
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.
-
I would phrase it a little differently. You're trying to use MS in a way for which it wasn't constructed. MS docs are good, provided you follow the path the system was designed for. It shouldn't surprise you that you'll have to start going through the code since you're trying to build something new. I'm sure no one will mind if you write a lot of good documentation in the areas you find deficient and put in a pull request :smiley:
ps: As someone who works on a multi-decade software project, I completely agree with you on the state of the arduino code and that includes the libraries and most user code. It appalls me every time I have to look through the arduino standard libraries to see the lack of a standard style, documentation requirements, test cases, etc.
-
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! ;-)
