Porting MySensors to work with the RadioHead library
-
The trouble with initialising the radio separately by the user is that it increases the complexity, which I think is one of @HEK's major points with the library. It definitely looks like the easiest way to support multiple radios, but the question is, is it good enough?
-
The trouble with initialising the radio separately by the user is that it increases the complexity, which I think is one of @HEK's major points with the library. It definitely looks like the easiest way to support multiple radios, but the question is, is it good enough?
@kolaf I understand @hek 's reservations.
Maybe we can add a function to MySensors that returns a static instance to the radio, all configured to use with MySensors.#include <MySensor.h> MySensor gw; void setup() { // Start MySensors and pass it the radio to use. Mysensors manages the instance // and configures the radio with defaults for us. // 'power users' can instantiate their own radio and configure it to their liking gw.begin( gw.createRadio() ); }How 'bout that?
http://yveaux.blogspot.nl
-
@kolaf I understand @hek 's reservations.
Maybe we can add a function to MySensors that returns a static instance to the radio, all configured to use with MySensors.#include <MySensor.h> MySensor gw; void setup() { // Start MySensors and pass it the radio to use. Mysensors manages the instance // and configures the radio with defaults for us. // 'power users' can instantiate their own radio and configure it to their liking gw.begin( gw.createRadio() ); }How 'bout that?
Now we're talking!
Really appreciate you're effort on RadioHead while still keeping it simple for the end-user.
I'm finalizing the documentation for 1.4 so we can release it and continue the work on RadioHead and the new protocol changes. As @Damme said somewhere, this might be enough for a 2.0 version :).
-
@kolaf I understand @hek 's reservations.
Maybe we can add a function to MySensors that returns a static instance to the radio, all configured to use with MySensors.#include <MySensor.h> MySensor gw; void setup() { // Start MySensors and pass it the radio to use. Mysensors manages the instance // and configures the radio with defaults for us. // 'power users' can instantiate their own radio and configure it to their liking gw.begin( gw.createRadio() ); }How 'bout that?
-
I have made some progress on the proposed initialisation routines and I am at the point where something works. The current initialisation for my sensor looks like this:
#include <MySensor.h> #include <RH_RF69.h> #include <SPI.h> RH_RF69 driver; MySensor gw; void setup() { if(gw.setRadio(&driver)) { driver.setFrequency(868); driver.setTxPower(14); gw.begin(); } }I stumbled upon a few snags on the way. For instance, when you initialise the manager (after giving it the driver) it sets up a bunch of defaults. This means that we have to override these defaults after the manager is initialised. This is why I split this out in a separate function setRadio. This function initialises the manager and returns true if this is successful. You may then set up your optional parameters and call begin.
A great benefit of having the radio include in the source file instead of in the library is that we now do not have to distribute it inside the MySensors library. We can now use a regular Radiohead installation in the Arduino environment. I have pushed this to my repository, let me know what you think.
-
The next challenge is sleeping. The different drivers sleep using different function calls.
-
I have made some progress on the proposed initialisation routines and I am at the point where something works. The current initialisation for my sensor looks like this:
#include <MySensor.h> #include <RH_RF69.h> #include <SPI.h> RH_RF69 driver; MySensor gw; void setup() { if(gw.setRadio(&driver)) { driver.setFrequency(868); driver.setTxPower(14); gw.begin(); } }I stumbled upon a few snags on the way. For instance, when you initialise the manager (after giving it the driver) it sets up a bunch of defaults. This means that we have to override these defaults after the manager is initialised. This is why I split this out in a separate function setRadio. This function initialises the manager and returns true if this is successful. You may then set up your optional parameters and call begin.
A great benefit of having the radio include in the source file instead of in the library is that we now do not have to distribute it inside the MySensors library. We can now use a regular Radiohead installation in the Arduino environment. I have pushed this to my repository, let me know what you think.
@kolaf said:
For instance, when you initialise the manager (after giving it the driver) it sets up a bunch of defaults.
Yes, I see it calls init() from the driver, which sucks...
I'll guess you want gw.setradio to initialize the manager then (which in turn initializes the driver)? This way you'll be able to modify the driver's parameters before MySensors starts. Not a very elegant way... (but I also don't have a better solution at the moment...) -
@kolaf said:
For instance, when you initialise the manager (after giving it the driver) it sets up a bunch of defaults.
Yes, I see it calls init() from the driver, which sucks...
I'll guess you want gw.setradio to initialize the manager then (which in turn initializes the driver)? This way you'll be able to modify the driver's parameters before MySensors starts. Not a very elegant way... (but I also don't have a better solution at the moment...) -
@kolaf Have you checked initialization of the managers for any radio communication taking place? If it does, your solution will not work as it will be executed using the default radio parameters...
@Yveaux I don't think there is any radio communication, it just initialises the radio chip and confirms that it is able to communicate with it. Otherwise you would have had real problems with trying to start every radio at the same time :-)
-
I just built my first nRF24L01+ setup using the RadioHead library running the nrf24_reliable_datagram_client and nrf24_reliable_datagram_server sketches on two Uno's.
Works like a charm, after I disconnected the interrupt line to the nRF24.
Don't know why yet (possibly an interrupt handler is 'secretly' installed by the library), but it took me some time to figure out...Also requires the driver to be constructed as RH_NRF24 driver(9, 10) when using the MySensors connection-scheme.
@Yveaux said:
Works like a charm, after I disconnected the interrupt line to the nRF24.
I went through the RadioHead code, looking for enabled INT0 interrupts, interrupts handlers etc. in nRF24 code.
Found none, so tested again today, with the interrupt line connected.Now it also works with interrupt connected...
Don't know what went wrong before.
-
@Yveaux said:
Works like a charm, after I disconnected the interrupt line to the nRF24.
I went through the RadioHead code, looking for enabled INT0 interrupts, interrupts handlers etc. in nRF24 code.
Found none, so tested again today, with the interrupt line connected.Now it also works with interrupt connected...
Don't know what went wrong before.
@Yveaux Good to hear that it is working out for you. I'm very curious to see whether you can get my version of the library working with your radio.
I have posted on the Radiohead group to see whether they can implement a generic sleep function in the driver or in the manager. This would make it much easier for us to put everything to sleep when required. Short of that the only reasonable solution I can see to fix this is to create a sleep function in the sensor source code and pass this as a parameter to the library. Alternatively we can build a different sleep functions in the library, but I guess this will cause the same problems as you talked about earlier with bringing in a lot of code we do not need.
-
@Yveaux Good to hear that it is working out for you. I'm very curious to see whether you can get my version of the library working with your radio.
I have posted on the Radiohead group to see whether they can implement a generic sleep function in the driver or in the manager. This would make it much easier for us to put everything to sleep when required. Short of that the only reasonable solution I can see to fix this is to create a sleep function in the sensor source code and pass this as a parameter to the library. Alternatively we can build a different sleep functions in the library, but I guess this will cause the same problems as you talked about earlier with bringing in a lot of code we do not need.
@kolaf said:
I have posted on the Radiohead group to see whether they can implement a generic sleep function in the driver or in the manager
Ah great! Let's see how flexible they are ;-)
Btw. I'm not totally dismissive of the idea of making small changes to the RadioHead library when it makes our life easier to get a clean interface for MySensors users. Indeed, we have to sync changes (which are almost on a daily basis right now, but that will settle over time) but when the changes to the original library are relatively small this won't be too hard.
Anyway, let's not give up yet and see if we can use the vanilla library.
-
I created a github repo containing the RadioHead sources, including change history. The code is commit using a script, so future updates can easily be added.
IMHO having the RadioHead library sourcecode under version control is a requrement for inclusion in MySensors and if we ever decide to make small changes to the library we can now easily fork from the original sourcecode.
Get it at https://github.com/Yveaux/RadioHead
-
@Yveaux Good to hear that it is working out for you. I'm very curious to see whether you can get my version of the library working with your radio.
I have posted on the Radiohead group to see whether they can implement a generic sleep function in the driver or in the manager. This would make it much easier for us to put everything to sleep when required. Short of that the only reasonable solution I can see to fix this is to create a sleep function in the sensor source code and pass this as a parameter to the library. Alternatively we can build a different sleep functions in the library, but I guess this will cause the same problems as you talked about earlier with bringing in a lot of code we do not need.
-
Are we talking here about
(1) each radio driver having its own full sleep library to put the processor to sleep (potentially in addition to the sleep library used by the main sketch), or
(2) just each radio driver having its own function to put its radio into low power mode with/without IRQ?
-
Just (2)
-
Good. Let's call it prepare-to-sleep or power-down or something rather than sleep.
-
@Zeph Fair enough.
Since I'm not getting any response on their mailing list, perhaps we should just go ahead and implement something. My plan is to create a virtualised powerdown in RHGenericDriver and then implement a reasonable default at least for the two radios we use. We can then expand this as we gain more experience. I know that for the RF69 driver this should be no more than five minutes work. Does anyone want to take care of your radios?
-
@Zeph Fair enough.
Since I'm not getting any response on their mailing list, perhaps we should just go ahead and implement something. My plan is to create a virtualised powerdown in RHGenericDriver and then implement a reasonable default at least for the two radios we use. We can then expand this as we gain more experience. I know that for the RF69 driver this should be no more than five minutes work. Does anyone want to take care of your radios?
If it works out, we can send them a patch :-)
