Hub for 433 MHz and nRF24L01 - Page 1
Forum section: electronics / projects

author: brainwash
author_rank: Frequent Contributor
timestamp: June 07, 2015, 12:36:56 am
content: I'm trying to read several 433 weather sensors and remote controls and output control signals for those RC sockets. Would also like to have nRF24L01 connectivity, it might prove useful. All this should be connected to a generic Linux board (rPi, bPi, ...).I did manage to get everything connected but there are some scalability and usability issues and since this is an on-off project I don't want to invest useless time if there are some ready-made solutions.Summary:- what is the best way to interface to generic 433 communication - hopeRF modules connected to the Linux board or uC boards connected to cheap modules (requires real-time) feeding data via serial/SPI?- any suggestions of having auto-negotiable addresses for nRF24? Would hate to have to assign addresses for each board/node or run a scan. Or perhaps there is a way to run a fast (1-5 min) scan once every few hours- how to feed data into the rPi? Was thinking of either a bash script that read data from tty and feeds into a file then a 'tail' process feeds that into a server- speaking of servers, played a bit with MQTT, are there better alternatives to providing a stream of data that can be processed and fed into other modules?- logging/graphing of node data?- triggers - examples: RF PIR sensor triggering play on a SqueezeBox which would then time out after ~20 mins of no motion. Pinging a smartphone IP address to check if someone (specific) is in the house- devices to show the state and perhaps interact: like an android tablet showing the weather outside, status inside and allowing to turn on/off lights, music, .... Nice if it would be an auto-updating Kindle.I know it's quite a list but I wouldn't want to invent the wheel since this stuff appears quite often so I assume people have already built similar things.I know it's also not fully electronics-related, but here's the hardware sitting around: >3 Arduino Nano boards, 3 esp8266 (dip header) boards, 3 Linux boards, >3 pairs of 433 Modules, one hopeRF TX/RX SPI 433 module, >3 nRF24 modules, >3 MSP430, >3 Stellaris Launchpads, >3 DS18B20, 3 digispark boards, >3 5110 LCDs, several Android devices, hackable routers, 3G Kindle, ...Just shout out your best ideas, or, even better, example or what you've already implemented.

author: nfmax
author_rank: Super Contributor
timestamp: June 07, 2015, 09:45:29 am
content: Hi,I have been active in just this technology for a while now. In my opinion, the best approach is to buy an RFXCOM RFXtrx433Ehttp://www.rfxcom.comwhich is a USB interfaced transceiver. This includes a microcontroller which is programmed to understand a huge variety of 433 MHz device protocols (hundreds!), which is currently actively supported and re-flashable as new devices are added. Many home automation 'domotics' software packages support it.However if you are already looking at MQTT (and you are right, it is very good way of handling data like this) and you are using a Linux module like a Raspberry Pi or a BeagleBoard Black, then Christmas has arrived early for you! Download a copy of Node-REDhttp://nodered.org/and install my node set for the RFXCOM, node-red-contib-rfxcom. This supports a wide variety of weather sensors, and remote control sockets, and using Node-RED it is really easy to graphically 'wire up' a flow to do things like control solenoid valves based on temperature sensors. There is a community of users doing exactly this - take a look at the discussion list.Node-RED was developed in the same group at IBM where MQTT was invented, so naturally the two play well together. Both have the concept of messages, with 'topics' and 'payloads', though in Node-RED a message can be arbitrarily extended. There are MQTT input and output nodes for Node-RED. The graphical IDE runs in a browser, and the server runs anywhere that runs node.js.I should also add there is another device, the Teldus Tellstick Duo, which is similar to the RFXCOM and has a supporting node, though I have no experience with these. Both devices support OOK/pulse modulation only, not the FM transmission used by a few of the longer range 433MHz devices.

author: brainwash
author_rank: Frequent Contributor
timestamp: August 10, 2015, 11:14:10 am
content: I thought I replied here but cannot see my previous reply.Anyway, thank you nfmax for the suggestion, I looked into the rfxcom module at that time. Unfortunately on the supported devices list it was missing some of my own. In the end I started rewriting the rc-switch library for Arduino to decode my own devices and made some really good progress with that.It seems that in the end I will implement my own pluggable module (via UART) even though the human cost of doing so will far outweigh the cost of the RFXCOM.The problem with these devices is that you have to spend time uploading firmware and testing decoders. It seems like the best thing to do is to do the signal discrimination on a small uC and feed that raw data into a bigger board. By discrimination I mean low-pass filtering with basic protocol recognition: the small uC senses when the 433RX goes high/low for a longer amount of time, records the signal changes into a buffer and sends the signal durations to the big uC.I've seen a project concerned with home automation or weather sensors where they did the discrimination through an ATTiny8, but it was only doing low-pass filtering - basically ignoring all the changes less than x ms. The RPi still had to do the basic IO operations. This ties up a lot of resources and is not guaranteed to work under heavy load. My solution - of feeding the UART buffer with signal delays(timings) as they are processed - should make the small uC work in realtime while the other part could also make use of its hardware UART buffer. Plus it adds the benefit of making it possible to use an UART-USB bridge.

author: nfmax
author_rank: Super Contributor
timestamp: August 10, 2015, 12:34:49 pm
content: brainwash,Your concept of using a hard-real-time 'front end' micro to provide a set of pulse timings as input to a decoder library on a more capable RPi sounds like a good one. Have you looked at the Beaglebone Black? It is similar to the RPi in concept, but the TI chip it uses has two of what are described as 'programmable real-time units' as well as the main ARM core. These are basically simple, dedicated microprocessors that can be programmed independently of the main ARM for tasks exactly like pulse timing.It's also worth checking the current state of the RFXCOM software. It is updated about once a month, most recently on 2015-07-24, each time adding new devices.Finally, even if you decide to roll your own front end, Node-RED is a great way to implement the logic and control to wire the sensors and relays together.Good luck, have fun!

author: brainwash
author_rank: Frequent Contributor
timestamp: August 10, 2015, 05:14:20 pm
content: Thank you again for the feedback and I fully agree.The signal discriminator however would be useful for other use-cases as well. I have a friend who is trying to build a (very-)low-power low-cost 433 base station and perhaps the knowledge can be reused. But that's another topic for this forum...Node-red will indeed be my choice for the flow.I'm not dismissing RFXCOM yet, but just trying to play with the hobby stuff, for now. If I decide to throw in the towel then that would be my first choice.

author: brainwash
author_rank: Frequent Contributor
timestamp: August 11, 2015, 10:25:06 am
content: Regarding the BBB, it indeed has fast almost-realtime IO but only 10 people on the planet know how to use the PRU. A uC is almost always better for this job since there you have guaranteed real-time.Some more benefits of the separate board approach: UART is universal, so it could be connected to an ESP8266 unit or similar and you can have a UART to TCP bridge. The same unit can be taken to a computer, an Arduino-like board or an RPi-like board. Using the BBB ties you to that board. Using a USB solution throws away the Arduino and ESP8266 compatibility.