Porting MySensors to work with the RadioHead library

[kolaf]

@Damme Thanks for your input. I have had a chance to debug a bit more this evening and it turned out that I was not initialising the radio correctly.

I now have a version which is working with the RF 69 radio soldered to my Arduinos. Currently it should be easy to change the radio driver by changing the driver that is initialised and changing the appropriate include files.

I have achieved a successful communication from a sensor implementation to the serial gateway implementation where it requests a node ID. This is using the RHMesh manager implementation which handles a dynamic mesh network in the background.

I have not tested return communication yet because am frankly not quite sure what the correct command would be to assign a node ID. I guess all figure this out tomorrow, unless someone cares to give me an example?

With the debug enabled the gateway and simple sensor (simply sending a message every five seconds) amounts to the following when building..

Gateway:

Sketch uses 22,674 bytes (70%) of program storage space. Maximum is 32,256 bytes.
Global variables use 1,424 bytes (69%) of dynamic memory, leaving 624 bytes for local variables. Maximum is 2,048 bytes.

Sensor:

Sketch uses 19,854 bytes (61%) of program storage space. Maximum is 32,256 bytes.
Global variables use 1,141 bytes (55%) of dynamic memory, leaving 907 bytes for local variables. Maximum is 2,048 bytes.

[hek]

Great, sounds like your doing real progress.

[Zeph]

@kolaf
How big is the flash and RAM footprint of an equivalently limited nRF24L01+ implementation? The RadioHead library sounds heavier.

---

As I'm understanding you, a node is using the RadioHead RF69 mesh network to send a request to the hub for a MySensors node id. Doesn't the mesh network have its own equivalent node id? How are you integrating those two? (eg: does your node use id 255 temporarily within the RadioHead addressing, then change it a hub assigned ID, or...?)

I'm not really clear enough about the logical layering of the two networks, and how you are mixing and matching the layers.

[kolaf]

@Damme @Zeph I took a quick stab at dumping the free run by uncommenting the serial.write command in debugPrint. I didn't get anything, so I will look into it later.

Anyway, I was finally able to send a node ID response from the serial gateway back to the sensor, and is responded with a bunch of interesting data :-). This means that every thing seems to work, and I think the implementation is in a state where I can actually use it to build sensors. The challenge now is to have the self-discipline to generalise this so that others may use it to ;).

Based on all your comments and worries about flash and RAM space, I have been thinking that maybe my approach was not the best. I have ripped out everything related to routing so that I rely completely on the RadioHead for anything related to the link and network level. This means that we get support for quite a complex dynamic sensor networks at the cost of reduced available memory for useful stuff. May be a hybrid approach would have been better, relying on the reliable datagram manager from the library and using the mysensors routing functionality. Perhaps this would yield a smaller footprint, I don't know.

As for node addressing, there is a function in the new radio library that allows me to set the node address. I can therefore use the existing node address discovery to set everything up. I've included the message sequence I get when performing this initialisation below. The first line is the node assignment sent from the gateway to the sensor. There is some extra debug garbage in the printout which I had to add when trying to get this to work.

255;255;4;0;3;1
0;0;3;9;send: 0-255 s=255,c=3,t=4,pt=0,l=1,st=302:1
0;0;3;9;sent: 0-255 s=255,c=3,t=4,pt=0,l=1,st=295:1
0;0;3;9;Available
0;0;3;9;read: 1 s=255,c=3,t=11,pt=0,l=11:Dust Sensor
1;255;3;11;Dust Sensor
0;0;3;9;Available
0;0;3;9;read: 1 s=255,c=3,t=12,pt=0,l=3:1.1
1;255;3;12;1.1
0;0;3;9;Available
0;0;3;9;read: 1 s=3,c=0,t=0,pt=0,l=15:1.4b1 (18848a2)
1;3;0;0;1.4b1 (18848a2)
0;0;3;9;Available
0;0;3;9;read: 1 s=3,c=1,t=16,pt=2,l=2:1
1;3;1;16;1
0;0;3;9;Available
0;0;3;9;read: 1 s=3,c=1,t=16,pt=2,l=2:1
1;3;1;16;1

I'm wondering since we now have a working prototype version, perhaps I could be allowed to push my branch to your repository? Of course we don't merge anything yet, but it will allow others more easy access to it for further testing. By only changing a few lines to account for different radios the current version should support most of the moteino and anarduino variations with our different radio chipsets, I think.

[kolaf]

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_HUM

My 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 :-).

[kolaf]

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.

[Damme]

@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)

[kolaf]

@Damme said:

@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)

1.5.7

[kolaf]

I have been thinking on how to extend the library to support different radios. As far as I can see there are two options.

1. 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.

2. 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?

[hek]

@kolaf

Tried to open a chat (see the icon at the bottom of the screen)

[Yveaux]

@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]

@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!

[hek]

@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]

@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!

[hek]

@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. ;)

[Yveaux]

@hek Nah, f*ck 'em :-1:

[Damme]

@kolaf I was unable to repreduce those errors, When trying to fix it to const the compiler moved the array-table to sram instead >.< I hate progmem (and Harvard architecture)

[kolaf]

@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?

[Yveaux]

@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]

@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):

https://github.com/kolaf/Arduino/tree/radiohead_port