Preferred connection method - USB, Ethernet or GPIO?
-
(recreated from google cache)
Just a quick question here. It may not be entirely clear to most people how MySensors is supposed to work with the RPi. The website currently seems to suggest that GPIO is the way to go for future cloud services, but 3rd-party developers on the other hand are pointed towards the USB serial gateway interface. Ethernet does not seem to be the preferred method even though it is possibly the most ingenious. Personally I'm a bit confused by all of this. If we are to plan for the future, how do we do that?
I have my RPi connected to a Arduino Nano serial gateway (PA LNA) and that seems to work very well given the limited testing I've done. It does free up a lot of GPIO pins that I need for other things and power supply does not seem to be a problem (I'm feeding TP1/TP2 directly). If at all possible I'd like to have both cloud support and local software (like Domoticz or similar in the future as support becomes available) working at the same time. To make things more interesting I have my RPi hanging high on the outside of the house built primarily as a surveillance camera in a very tight housing that has both the camera module, serial gatway, pilight receiver/transmitter/filter and a much too bulky power over ethernet converter.
On a separate note, does anyone else have compiling issues with the gateway code when compiling on the Pi directly? I fiddled around a lot but ended up with a bunch of weird errors (can't recall what it was) at least with the 1.4b1-branch. As the RPi is physically inaccessible I eventually had to compile the code on the Windows IDE, upload the .hex-file to the RPi and flash. No big deal, especially since compiling on the Pi is pretty slow.
-
@bjornhallberg I agree with you that creating a gateway using the Raspberry (or any other computer) is best done with an Arduino Nano with USB because:
- People using MySensors are already experienced with Arduino so one more Arduino should be no problem
- GPIO is more difficult than USB
- the Arduino Mini can run time critical functions that can not be run by Raspberry as it is a general purpose board with no guaranteed response times.
That said, I also do not really see problem with GPIO, it saves one component in the chain and mysensor gateway code is likely not so time-critical.
Ethernet can be nice if the gateway is far away (>5 m) from the Raspberry but apart from that I see no real advantages.
What I would hope for is a clearly OSI or HTTP/IP/Ethernet-like layered software stack that can be split on boundary of every layer so you can make your own choice on where to put every layer and what kind of interface you use between the layers.
-
I am using serial gateway for simple reason. I have simple script in node.js to manage serial messages. Gateway is powered from RPi, and it's working just ok.
-
I used to be pro GPIO ... until I actually tried it. I mean, using an Arduino (especially a dedicated one that does this and nothing else) for IO is just more reliable. With the RPi, you never know what is going to happen. I.e. will the camera module ruin timings? Will a temperature sensor work if you also have something else on the GPIO? Googling he topic provided a lot of horror stories. Of course, you could have a Pi for doing just one thing, just like the Arduino gateway, but that just seems like overkill.
Since we talked about scripts communicating with a MQTT broker in the Home Automation thread, perhaps that is something we could do here, and skip the GPIO if possible. Having one script that is maintained by the MySensors staff that can read data from serial and send it to (1) the MySensors cloud, (2) a MQTT broker (like Mosquitto and then on to OpenHAB or Domoticz). I really don't know. This is all pretty new to me.
-
Many Raspberry Pi Linux distributions use a so-called PREEMPT-RT kernel. This means that the linux kernel has been patched on a significant amount of places to allow 'near-realtime' performance of user(-space) programs.
This requires some nifty tricks in the programs (e.g. memory locking, stack pre-faulting) but it allows you to get quite deterministic behaviour of your code.
OSADL continuously runs a number of benchmarks for different CPU/Board architectures. In one of the racks there's actually a Raspberry Pi under test (https://www.osadl.org/Latency-plot-of-system-in-rack-b-slot.qa-latencyplot-rbs3.0.html). The chart in the link tells us that for that hardware/kernel combination on the RPi the average latency is around 50us, and worst-case around 150us. Latency can simply be describes as 'reaction time to an event', e.g. an interrupt.
These times will definiately shorter on an Arduino (when handled using interrupts, not necessarily by loop()-runs) but still these reaction times are pretty good and IMHO very well usable.
Of course it all depends on the application and to some extent load of the RPi, but running the gateway software on a RPi with the radio directly connected using GPIO should be no problem at all.
-
@bjornhallberg said:
Since we talked about scripts communicating with a MQTT broker in the Home Automation thread, perhaps that is something we could do here, and skip the GPIO if possible.
MQTT and weather to use GPIO, USB or Ethernet are not linked to my opinion, they are at different levels of the stack.
MQTT is a messaging protocol for use on top of the TCP/IP protocol, so OSI level 5+ while the choice for GPIO, USB or Ethernet are about the layers 1, 2 and possibly layer 3.
But yes, I would love to see an open protocal like MQTT or, better, MQTT For Sensor Networks (MQTT-SN) used to publish the sensor data.
-
@Yveaux Interesting info! But in my case, with other things being connected to the Pi, like the camera, pilight sender and prefilter, DHT22 to keep track of humidity inside the outdoor case etc I still wouldn't trust the Pi. Add to that some Home Automation software and a MQTT broker possibly and it seems like a ripe mix for malfunction and a troubleshooting nightmare. Plus I almost forgot, the Arduino hanging off USB so that I can get local home automation to work and not just cloud support.
If JUST an Arduino via serial would do just as well or better I'd prefer not to have to use the GPIO. But that is just personal preferences ... and I guess some of my own irrational fears
I guess the whole point of this thread was to figure out how the cloud support would eventually work ... and if I'd have to effectively run two NRF24L01 modules (one via USB/Arduino and one on GPIO) on the same Pi to get both cloud and local support working.
-
@daulagari I am currently implementing minimal version of MQTT for mysensors. It will be runned as a broker on a Ethernet gateway directly . using version 3.1 http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-v3r1.html
The development just halted because I was uncareful with my PoE adapter,fried the shield completely. but I'll try order one from UK (2-3 days shipping)It has been tested with openhab but I suppose others will work as good. (Will need some testing)
-
@damme: Good to know and yes, for that using an Ethernet gateway looks quite nice to me, having also WiFi near to my cubieboard and AP I do not like the gateway to be too close to it and USB is not really nice for longer distances.
I am currently using Domotiga and I see it has some MQTT support but no support to subscribe to topics publishing sensor data yet is seems.
NB: How did you fry the shield? Or better discuss that in this thread.
-
Another thing. How about the CPU load on the RPi when having a the NRF-module hanging off of GPIO directly? Has anyone tried that? Or if it will clog up IO on the thing. I mean, recall what happened to pilight and why they came up with their "prefilter" (basically an attiny45/85 that processes the 433MHz stuff before sending it on to the Pi). Wihout the prefilter the CPU load is like 40% at least. With the filter the load is around 4%. But I guess the NRF-module is better at filtering stuff out?
-
@bjornhallberg RPi is connected to nRF24 usinf SPI. The Broadcom chip on the RPi has special SPI peripherals which can use DMA to transfer from/to RPi memory.
This causes SPI transfers to hardly influence the CPU, so I doubt you will even notice when nRF radio communication is going on in the background.
-
@Yveaux Ok thanks. So there is no reason to think that the NRF itself will pick up a bunch of interference in the 2.4GHz band and pass it on to the Pi indiscriminately like my 433MHz receivers will?
-
@bjornhallberg you were talking about CPU load and now you're switching to interference?! That's two difference things....
-
@Yveaux said:
@bjornhallberg RPi is connected to nRF24 usinf SPI. The Broadcom chip on the RPi has special SPI peripherals which can use DMA to transfer from/to RPi memory.
This causes SPI transfers to hardly influence the CPU, so I doubt you will even notice when nRF radio communication is going on in the background.I'm surprised at that. The nRF library does a lot of individual register manipulation; for 1-3 bytes of SPI transaction at each step, I'd think setting up DMA would be slower than just doing it. When you get to loading or unloading the packet data from the nRF's FIFO (say 10+ bytes of payload), then setting up DMA might help a little bit.
Real different than reading sectors of a SD card, for example.
Not doubting you if that's your actual experience, just surprised.
-
@Zeph On a second read, I think to understand from @bjornhallberg post that the 433MHz transceivers do not decode the bitstream by themselves, but just pass it on to the RPi and have the RPi cpu decode it (but don't shoot me if I'm wrong).
If this is true, it will cause an enormous CPU load as the CPU has to continuously scan the 200KBit/s bitstream for packets.
The nRF24 does this decoding on its own and is connected via SPI, for which DMA transfer can be used to speed up the transfers even more. The RPi cpu will only have to trigger retrieval of the payloads and interpret them.
-
@Yveaux Yes that is what I was getting at. I just wanted to know that I wasn't going to end up in the same pit as with the 433MHz modules ... and I know virtually nothing of the workings of the NRF chip. Thank you for reassuring me
