Porting MySensors to work with the RadioHead library
-
It is great to see that something is still happening. I wonder if I can build a packet sniffer for the RF69 radios? I guess it shouldn't be that difficult since they receive everything that is sent...
The reason for my lack of progress late the has several reasons.
- I have a version of the library networks for my simplifications. This means that I can start building small sensors instead of spending all my time on the library :-)
- My kids think I spent way too much time on this project already :-(
- I'm waiting for some kind of consensus to emerge.
My hope has been to get this new radio library thing to a point where the community would adopt it so that I would not have to do any specific maintenance to keep my copy up to date with the official version. Based on this very long discussion thread there seems to be interest among you guys to achieve this, so I hope we will be able to get there at some point. However, we need to agree on how it is to be done, how much of the Radiohead library we want to use (or maybe even use a different library?). This obviously depends mostly on resource constraints considerations, and I'm not the best to judge this since I have not used MySensors extensively.
It is great to see effort being spent on trying to reduce the footprint, and as an experiment it makes sense to do this. Once we have seen how small it is possible to make it, then we can perhaps agree on what features we want (everything, or just the device interface, maybe with RHDatagram manager class (without acknowledgements)).
I'm holding back on developing any more this until we have reached some kind of consensus since I do not really have time to play around too much without being a relatively sure that the results will be useful.
-
@Yveaux said:
So, anyone still developing on RadioHead integration, or did all of you just give up? ;-)
no progress on my end - but that's rather related to the fact that this was my first week back in the office after vacation...
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
That way it would be rather easy to make use of other radios and other network topologies - could be RH or something else. I've taken a shot at that (a lot of this based on what Kolaf and Yveaux did adjusting MySensors to RH) and will provide a link once it compiles and is tested and I hope I can keep the overhead small enough to be acceptable for the gained flexibility.
@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. -
Care to share any details on which parts you took from where? Is it basically the Radiohead drivers with the MySensors network layer? Or did you make more effort on trying to split everything up to a larger extent
-
Care to share any details on which parts you took from where? Is it basically the Radiohead drivers with the MySensors network layer? Or did you make more effort on trying to split everything up to a larger extent
@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. -
@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...
