Porting MySensors to work with the RadioHead library
-
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 :-)
I am also happy to report that I just tried to compile the secret knock sensor without any difficulties :-)
Sketch uses 22,074 bytes (68%) of program storage space. Maximum is 32,256 bytes. Global variables use 1,241 bytes (60%) of dynamic memory, leaving 807 bytes for local variables. Maximum is 2,048 bytes. -
I am also happy to report that I just tried to compile the secret knock sensor without any difficulties :-)
Sketch uses 22,074 bytes (68%) of program storage space. Maximum is 32,256 bytes. Global variables use 1,241 bytes (60%) of dynamic memory, leaving 807 bytes for local variables. Maximum is 2,048 bytes. -
@kolaf What version of arduino IDE do you use? you should really use 1.5+
(But I'll fix so it works in older version) -
I have been thinking on how to extend the library to support different radios. As far as I can see there are two options.
-
Have a generic radio driver pointer (of the superclass type RHGenericDriver) and initialise this depending on an input parameter to the Gateway constructor. The trouble with this approach is that we have to static_cast every access to this variable to its appropriate subclass in order to access radio specific functions to set transmit power, et cetera. We also have to include a bunch of header files so that everything is available during runtime. This obviously increases footprint and complexity for the maintainer.
-
Use a define in the sensor application and Gateway application to determine which radio is to be used, e.g. "#define DRH_RF69" to select the radio I am using. With an include #ifdef directives in the header and my sensor source files to include only the necessary driver headers and choose the correct set of initialisation functions for the radio. Most of this would go into the setupRadio function.
I think that the second approach is the easiest to implement. It also requires a single addition to any client application, namely the correct define at the top of the configurations header file. We can leave this as a default radio value, and the knowledgeable user can change this if he uses a different chipset. Does this make sense?
-
-
I have been thinking on how to extend the library to support different radios. As far as I can see there are two options.
-
Have a generic radio driver pointer (of the superclass type RHGenericDriver) and initialise this depending on an input parameter to the Gateway constructor. The trouble with this approach is that we have to static_cast every access to this variable to its appropriate subclass in order to access radio specific functions to set transmit power, et cetera. We also have to include a bunch of header files so that everything is available during runtime. This obviously increases footprint and complexity for the maintainer.
-
Use a define in the sensor application and Gateway application to determine which radio is to be used, e.g. "#define DRH_RF69" to select the radio I am using. With an include #ifdef directives in the header and my sensor source files to include only the necessary driver headers and choose the correct set of initialisation functions for the radio. Most of this would go into the setupRadio function.
I think that the second approach is the easiest to implement. It also requires a single addition to any client application, namely the correct define at the top of the configurations header file. We can leave this as a default radio value, and the knowledgeable user can change this if he uses a different chipset. Does this make sense?
-
-
@kolaf said:
I think that the second approach is the easiest to implement
Agree. Pointers to instances makes more sense when radios have to be switched dynamically or when multiple radios have to be supported.
For this application having a #define in a configuration file makes perfect sense. -
I am also happy to report that I just tried to compile the secret knock sensor without any difficulties :-)
Sketch uses 22,074 bytes (68%) of program storage space. Maximum is 32,256 bytes. Global variables use 1,241 bytes (60%) of dynamic memory, leaving 807 bytes for local variables. Maximum is 2,048 bytes.@kolaf said:
Sketch uses 22,074 bytes (68%) of program storage space. Maximum is 32,256 bytes.
Global variables use 1,241 bytes (60%) of dynamic memory, leaving 807 bytes for local variables. Maximum is 2,048 bytes.These are very acceptable numbers IMHO.
No need to worry about flash/ram usage! -
@kolaf said:
I think that the second approach is the easiest to implement
Agree. Pointers to instances makes more sense when radios have to be switched dynamically or when multiple radios have to be supported.
For this application having a #define in a configuration file makes perfect sense.@Yveaux said:
Pointers to instances makes more sense when radios have to be switched dynamically or when multiple radios have to be supported.
Yes, defines certainly make sense now! But it would be cool to have gateway-nodes between different radio models in the future ;)
-
@Yveaux said:
Pointers to instances makes more sense when radios have to be switched dynamically or when multiple radios have to be supported.
Yes, defines certainly make sense now! But it would be cool to have gateway-nodes between different radio models in the future ;)
@hek Maybe, but I have yet to see a valid usecase for this. You can always use 2 Arduino's running the default serial gateway and tie them together ;-)
I haven't looked into the radiohead interface yet (have to admit you guys got me curious, though) but isn't there simply one base class defining the interface and every radio derives from it? That would definately make things simple!http://yveaux.blogspot.nl
-
@hek Maybe, but I have yet to see a valid usecase for this. You can always use 2 Arduino's running the default serial gateway and tie them together ;-)
I haven't looked into the radiohead interface yet (have to admit you guys got me curious, though) but isn't there simply one base class defining the interface and every radio derives from it? That would definately make things simple! -
@Yveaux said:
Maybe, but I have yet to see a valid usecase for this
Yeah, the use case is a bit strained and theoretical. But you know how it is... eventually someone want to try to mix different brand radio units. ;)
-
I'm getting a bunch of errors when I compile the mqtt gateway source related to the initial list of constants. The error messages look like this:
D:\Home control\Arduino\libraries\MySensors\MyMQTT.cpp:14:15: error: variable 'broker' must be const in order to be put into read-only section by means of '__attribute__((progmem))' char broker[] PROGMEM = MQTT_BROKER_PREFIX; ^ D:\Home control\Arduino\libraries\MySensors\MyMQTT.cpp:16:12: error: variable 'S_0' must be const in order to be put into read-only section by means of '__attribute__((progmem))' char S_0[] PROGMEM = "Temperature"; //V_TEMP ^ D:\Home control\Arduino\libraries\MySensors\MyMQTT.cpp:17:12: error: variable 'S_1' must be const in order to be put into read-only section by means of '__attribute__((progmem))' char S_1[] PROGMEM = "Humidity"; //V_HUMMy current solution is to just delete these two files since I only care about the serial gateway, but it would be good to have everything working :-).
-
@hek Maybe, but I have yet to see a valid usecase for this. You can always use 2 Arduino's running the default serial gateway and tie them together ;-)
I haven't looked into the radiohead interface yet (have to admit you guys got me curious, though) but isn't there simply one base class defining the interface and every radio derives from it? That would definately make things simple!@Yveaux said:
I haven't looked into the radiohead interface yet (have to admit you guys got me curious, though) but isn't there simply one base class defining the interface and every radio derives from it? That would definately make things simple!
Unfortunately it is not as simple as that. Each radio driver has a constructor which is completely different from the others, and they have different concepts.
For instance, the RF 69 library requires an interrupt pin and a select pin, while the NRF 24 library uses a select pin and an enable pin. They also have completely different notions of frequency versus channel, modem modulation versus data rate, and so forth.
I think we should expand the setupRadio function to configure some useful defaults for every radio, and then we can expose the specific radio driver so that the power user can set more complex options such as a different modulation, data rate, channel, et cetera.
Make sense?
-
@kolaf said:
I think we should expand the setupRadio function to configure some useful defaults for every radio
Can't you wrap the radio setup and some more stuff in a class for every radio type, derived from a single interface class?
I hope in the actual mesh layer etc. you don't have to distinguish between different radio types anymore.... -
@kolaf said:
I think we should expand the setupRadio function to configure some useful defaults for every radio
Can't you wrap the radio setup and some more stuff in a class for every radio type, derived from a single interface class?
I hope in the actual mesh layer etc. you don't have to distinguish between different radio types anymore....@Yveaux said:
@kolaf said:
I think we should expand the setupRadio function to configure some useful defaults for every radio
Can't you wrap the radio setup and some more stuff in a class for every radio type, derived from a single interface class?
I hope in the actual mesh layer etc. you don't have to distinguish between different radio types anymore....I guess I could do that, but it sounds like more work :-). For now I will stick to a define section for each radio that configures the defaults. After all, most of the radio settings for the original version of the library also relies on defines.
I think the RF 69 configuration of the library is ready for testing by others, and I have also verified that the NRF 24 version of the library compiles. I do not have any hardware for this one, so maybe someone else wants to test to see if it works? I have forked the original repository, and my current progress can be found in the following branch (Radiohead_port):
-
If you want to test, be aware that the default pins for the constructor set up to match the RF 69 radio. You have to specify the select and enable pins in the constructor explicitly.
-
I just had a quick look at the RadioHead implementation.
All drivers are derived from RHGenericDriver (from http://www.airspayce.com/mikem/arduino/RadioHead/classRHGenericDriver.html):
If you pass an instance of RHGenericDriver in e.g. the c'tor of MySensors you're done.... But maybe I had a too-quick look ;-)
-
It is not that simple because all the different specific drivers implement a bunch of their own functions which are not virtualised. This means that you need to static cast or dynamic cast the driver every time you want to use it which is a real pain.
On the other hand, each driver seems to come with a relatively intelligent set of defaults, so I think it is quite easy to cater for the generic case, and then we can expose the internals for those who really want to get into the specifics. Still, if you want to try to generalise it in a different way, feel free :-)
-
It is not that simple because all the different specific drivers implement a bunch of their own functions which are not virtualised. This means that you need to static cast or dynamic cast the driver every time you want to use it which is a real pain.
On the other hand, each driver seems to come with a relatively intelligent set of defaults, so I think it is quite easy to cater for the generic case, and then we can expose the internals for those who really want to get into the specifics. Still, if you want to try to generalise it in a different way, feel free :-)
@kolaf said:
It is not that simple because all the different specific drivers implement a bunch of their own functions which are not virtualised. This means that you need to static cast or dynamic cast the driver every time you want to use it which is a real pain.
Are those driver-specific functions needed during normal operation, or are they only for non-default setup? (eg: frequency, bandwidth, etc)
-
What about packet size? I'm guessing that the idea is to use the 32 byte limit of the nRF24L01+ for all radios (even if they have larger packet options) right?
(This approach is frequently called "least common denominator", tho the actual mathematical concept being misreferenced is actually the greatest common denominator)
