Porting MySensors to work with the RadioHead library
-
@ToSa said:
I think we should do one thing first: decouple the "network layer" from the "application layer" in MySensors:
- not having MySensors derived from RF24
- have a "generic" interface between MySensors and the radio
Initial version - tested with a simple DallasTemperatureSensor setup successfully here
Note that this fork/branch does not include the "1.4 update 1" changes for nodeID / CRLF.Overhead is limited (~150b flash / ~20b ram):
Sketch uses 20,426 bytes (66%) of program storage space. Maximum is 30,720 bytes.
Global variables use 575 bytes (28%) of dynamic memory, leaving 1,473 bytes for local variables. Maximum is 2,048 bytes. -
@kolaf it's only splitting the MySensor application layer form the underlying network layer. Still using the MySensor tree network topology and the RF24 driver. It's adding the framework to allow others to easily integrate other topologies (e.g. mesh) and other radio modules (e.g. RF69). The interface expects a reliable submission - no matter if that's achieved by software (like radiohead) or hardware (nRF24).
The MyDriver header file includes a short description of the routines and it should be fairly easy to attach it to radiohead. The main benefit is that the original MySensor tree setup still works as before if wished. -
@kolaf click the "here" in my post above - or use this:
https://github.com/ToSa27/Arduino/commit/328757d5bdb2681257326761fe1a0d90cdc3eba3
-
@kolaf click the "here" in my post above - or use this:
https://github.com/ToSa27/Arduino/commit/328757d5bdb2681257326761fe1a0d90cdc3eba3
@ToSa Got it. My apologies for being slow, it was getting late ;).
Itlooks like this should be quite easy to work with. For the RF69 driver, maybe I could even use the unreliable datagram service from Radiohead And Configure the Driver to Use Hardware Acknowledgements (I Believe They Exist).
I will make an effort in this direction during the next few days, I hope. I'm curious to see how much space this requires compared to the NRF24 solution
-
@kolaf click the "here" in my post above - or use this:
https://github.com/ToSa27/Arduino/commit/328757d5bdb2681257326761fe1a0d90cdc3eba3
@ToSa I was trying to fork your repository in order to build the driver for the RF69 based on Radiohead. It does not seem to work, maybe because I already have a fork of the main mysensors repository?
Maybe I can just check out your code, add the necessary files and be allowed to push it back to you?
-
@ToSa I was trying to fork your repository in order to build the driver for the RF69 based on Radiohead. It does not seem to work, maybe because I already have a fork of the main mysensors repository?
Maybe I can just check out your code, add the necessary files and be allowed to push it back to you?
@kolaf said:
maybe because I already have a fork of the main mysensors repository?
yes - Git doesn't allow two forks with the same base name (Arduino) for one user. We are about to move the changes into the mysensors/development branch. That way you can pick it up from there...
-
@kolaf said:
maybe because I already have a fork of the main mysensors repository?
yes - Git doesn't allow two forks with the same base name (Arduino) for one user. We are about to move the changes into the mysensors/development branch. That way you can pick it up from there...
-
It has been implemented, but I won't bother testing it until your changes have been merged with development, I don't want to mess up my existing development environment. My biggest uncertainty is whether this set up will allow the Radiohead library to be installed as a regular library in the "libraries" folder or if it has to be put directly into the MySensors folder.
-
Hi guys,
I have received my Moteinos and anarduinos with RFM69HW radios. The anarduino webpage recommends a radio library called RadioHead which supports multiple radio tips and provides a common API for communication. http://www.airspayce.com/mikem/arduino/RadioHead/
It even supports quite complex things such as mesh networks. It currently supports the following radios:
- RH_RF22 Works with Hope-RF RF22B and RF23B based transceivers, and compatible chips and modules, including the RFM22B transceiver module. Supports GFSK, FSK and OOK. Access to other chip features such as on-chip temperature measurement, analog-digital converter, transmitter power control etc is also provided.
- RH_RF69 Works with Hope-RF RF69B based radio modules, such as the RFM69 module, (as used on the excellent Moteino and Moteino-USB boards from LowPowerLab http://lowpowerlab.com/moteino/) and compatible chips and modules such as RFM69W, RFM69HW, RFM69CW, RFM69HCW (Semtech SX1231, SX1231H). Also works with Anarduino MiniWireless -CW and -HW boards http://www.anarduino.com/miniwireless/ including the marvellous high powered MinWireless-HW (with 20dBm output for excelent range). Supports GFSK, FSK.
- RH_NRF24 Works with Nordic nRF24 based 2.4GHz radio modules, such as nRF24L01 and others. Also works with Hope-RF RFM73 and compatible devices (such as BK2423). nRF24L01 and RFM73 can interoperate with each other.
- RH_NRF905 Works with Nordic nRF905 based 433/868/915 MHz radio modules.
- RH_RF95 Works with Semtech SX1276/77/78 and HopeRF RFM95/96/97/98 and other similar LoRa capable radios. Supports Long Range (LoRa) with spread spectrum frequency hopping, large payloads etc. FSK/GFSK/OOK modes are not (yet) supported.
- RH_ASK Works with a range of inexpensive ASK (amplitude shift keying) RF transceivers such as RX-B1 (also known as ST-RX04-ASK) receiver; TX-C1 transmitter and DR3100 transceiver; FS1000A/XY-MK-5V transceiver; HopeRF RFM83C / RFM85. Supports ASK (OOK).
- RH_Serial Works with RS232, RS422, RS485, RS488 and other point-to-point and multidropped serial connections, or with TTL serial UARTs such as those on Arduino and many other processors, or with data radios with a serial port interface. RH_Serial23 provides packetization and error detection over any hardware or virtual serial connection.
- RH_TCP For use with simulated sketches compiled and running on Linux. Works with tools/etherSimulator.pl to pass messages between simulated sketches, allowing testing of Manager classes on Linux and without need for real radios or other transport hardware.
``
Seeing as the radio that is currently supported by MySensors is also supported by RadioHead I was wondering if anyone was interested in helping me porting MySensors to work with the RadioHead library. This will greatly increase the versatility of the MySensors library and magically allow it to work with a range of different radios :-).
I have briefly looked at the MySensors source code and it looks like most of the changes have to be done in MySensors.h and .cpp files.
I am willing to take a stab at it, but as everyone else I am limited on time. Still, it looks like it should not be a very difficult task. As discussed in another thread, it should be sufficient either to subclass the new radio library and replace a bunch of function calls, or drop the subclassing altogether and simply use the radio library as a regular included library.
The obvious difficulty comes soon as MySensors requires a function that is not available in the new radio library. However, seeing as MySensors is a pretty high-level library, and the API support from radioHead seems quite good, I suspect it should be possible to get around any such problems.
Anyway, I'm thinking of creating a branch of the library and spending a few hours trying to port it and get some basic functionality to work. Is anyone else is any value in this it would be great to have some help :-)
Is there any progress of merging into the development branch? I'm currently holding off of building anything definitive for in-house deployment until we have settled on a relatively stable base for the code.
On a side note, I'm currently deploying Z wave actuators for all the lights in my house (we're refurbishing the entire electric system, anyway), and I must say that I am not very happy with the closed nature of the Z wave network management. I have gotten to the point where I believe that if I were to replace all the Z wave components with MySensors components I would get a much more stable system. Unfortunately I will get in trouble with the authorities if I try this :(
-
@hek It looks to me that all the activity that happen on getting the RFM69 integrated as part of the Mysensor ecosystem is dying. Can we not see if we can talk to Felix from Lowpower (https://lowpowerlab.com/) to see if he is not willing to get his Moteino integters as part of the MySensor ecosystem. Here is the tread on his forum where I asked him about this. https://lowpowerlab.com/forum/index.php/topic,542.0.html
-
The integration has not stopped. It is just a bit slow as we all have lots on our plate ;)
Felix has actually sent me a couple of Moteinos that arrived a few days ago.
But the first step is to separate radio code from the rest of the library. @ToSa has begun this work and is nearly finished. Guess he is swamped with work as I haven't heard from him the last couple of weeks.
https://github.com/mysensors/Arduino/pull/36Then we can create a new driver for the RFM69.
-
I am waiting for the new radio separation code to be merged into the development branch. I have a working implementation (I think) of the RadioHead RFM69 library using his new code. I don't mind the wait, though, because I have lots of other things to do in the meantime and I can still build sensors using my own version of the library :-)
-
I am waiting for the new radio separation code to be merged into the development branch. I have a working implementation (I think) of the RadioHead RFM69 library using his new code. I don't mind the wait, though, because I have lots of other things to do in the meantime and I can still build sensors using my own version of the library :-)
-
Working on it, fighting git about a rolled back rebase...
-
I managed to resolve my git problem, but I'm now back to a problem we have discussed before.
The problem is with how I should include the driver in order to use it without having to modify the header of every driver file. Can't seem to find what we landed on last time...
-
I mean that I have to place the RadioHead library inside the main my sensors folder for everything to work. If I were to place it in the "utility" folder, I would have to change every include inside the library to use" instead of brackets.
Anyway, I have gotten it to compile, and there is some radio communication going on. Trouble is that there seems to be some issues with the buffer sizes (I guess?).
Here was what the sensor is sending:
find parent
send: 1-1-255-255 s=255,c=3,t=7,pt=0,l=0,st=bc:And this is what the Gateway is receiving (with an additional debug message from me):
0;0;3;0;9;read: 0-0-0 s=255,c=3,t=6,pt=1,l=1:0
0;0;3;0;9;version: 0
0;0;3;0;9;version mismatchObviously something is getting mangled along the way...
-
I got something working with a new library. Requesting node ID, and sending all initialisation stuff seems to work correctly. I was not able to place the libraries in the correct place this time either, but perhaps you can move them and re-factor the code?
I created a pulled request so that you can look at it.
This is happening in the gateway with the new code:
0;0;3;0;14;Gateway startup complete.
0;0;3;0;9;read: 1-1-255 s=255,c=3,t=7,pt=0,l=0:
0;0;3;0;9;send: 0-0-1-1 s=255,c=3,t=8,pt=1,l=1,st=ok:0
0;0;3;0;9;read: 0-1-1 s=255,c=3,t=8,pt=1,l=1:0
0;0;3;0;9;send: 0-0-0-1 s=255,c=3,t=8,pt=1,l=1,st=fail:0
0;0;3;0;9;read: 1-1-0 s=255,c=3,t=6,pt=1,l=1:0
1;255;3;0;6;0
0;0;3;0;9;read: 1-1-0 s=255,c=3,t=11,pt=0,l=13:Wave switch 3
1;255;3;0;11;Wave switch 3
0;0;3;0;9;read: 1-1-0 s=255,c=3,t=12,pt=0,l=3:1.1
1;255;3;0;12;1.1
0;0;3;0;9;read: 1-1-0 s=1,c=0,t=3,pt=0,l=3:1.4
1;1;0;0;3;1.4
0;0;3;0;9;read: 1-1-0 s=3,c=0,t=6,pt=0,l=3:1.4
1;3;0;0;6;1.4
0;0;3;0;9;read: 1-1-0 s=2,c=2,t=2,pt=0,l=3:1.4
1;2;2;0;2;1.4
0;0;3;0;9;read: 1-1-0 s=1,c=1,t=2,pt=2,l=2:0
1;1;1;0;2;0
0;0;3;0;9;read: 1-1-0 s=3,c=1,t=0,pt=7,l=5:23.2
1;3;1;0;0;23.2
0;0;3;0;9;read: 1-1-0 s=3,c=1,t=0,pt=7,l=5:23.3
1;3;1;0;0;23.3
