Porting MySensors to work with the RadioHead library
-
Since I have four moteino , I wanted to test your code. Unfortunately, I have made a mistake , because the compiler return this error :
In file included from My_Sensor.ino:2:
C:\Program Files (x86)\Arduino\libraries\MySensors/MySensor.h:32:1: warning: "debug" redefined
In file included from C:\Program Files (x86)\Arduino\libraries\MySensors/MySensor.h:16,
from My_Sensor.ino:2:
C:\Program Files (x86)\Arduino\libraries\MySensors/MyDriver.h:9:1: warning: this is the location of the previous definition
In file included from C:\Program Files (x86)\Arduino\libraries\MySensors/MyConfig.h:27,
from C:\Program Files (x86)\Arduino\libraries\MySensors/MySensor.h:17,
from My_Sensor.ino:2:
C:\Program Files (x86)\Arduino\libraries\MySensors/MyDriverRF69.h:40: error: ISO C++ forbids initialization of member 'radio'
C:\Program Files (x86)\Arduino\libraries\MySensors/MyDriverRF69.h:40: error: making 'radio' static
C:\Program Files (x86)\Arduino\libraries\MySensors/MyDriverRF69.h:40: error: invalid in-class initialization of static data member of non-integral type 'RFM69*' -
Hi I now have my first MySensor RFM69 node up and running in PiDome :-) :+1: This is great as with the NFR24L01 I battle to get coverage in my House. I put the RFm69 node in the farthest point in my house any it just work. To get the NFR24L01+ to work at the same location I have to use an repeater node. The other thing I like about the RFM69 solution like Moteino (https://lowpowerlab.com) or Anarduino (http://www.anarduino.com/miniwireless) is the size you don't have to use any wires to connected the radio and it comes fitted to the arduino board. So if you look for a small sensor I think that this is the way to go for automation.
-
Hi I now have my first MySensor RFM69 node up and running in PiDome :-) :+1: This is great as with the NFR24L01 I battle to get coverage in my House. I put the RFm69 node in the farthest point in my house any it just work. To get the NFR24L01+ to work at the same location I have to use an repeater node. The other thing I like about the RFM69 solution like Moteino (https://lowpowerlab.com) or Anarduino (http://www.anarduino.com/miniwireless) is the size you don't have to use any wires to connected the radio and it comes fitted to the arduino board. So if you look for a small sensor I think that this is the way to go for automation.
@Francois Cool! Is this compatible with RF24, as in, you can have RF24 based GW and other sensors, and "plug in" a RFM69 unit? With its better RF properties it sounds like an excellent candidate for use as repeater node as well.
Or is it required to set up a separate GW? -
@kolaf
I've been busy with other stuff for some time but looking at the driver separation now once again. With nRF24 working (even bootloader adjusted to pick the right header files etc.) and two Moteinos at hand (Moteino RFM69W 868/915), I compiled and flashed a serial gateway and a simple temperature sensor node. Both appear to work fine looking at the debug messages except the fact that they don't listen to eachother. Both are sending but none is receiving anything (2m distance).
I did not touch or even closely look at the RFM69 driver code yet but will try to do so over the weekend. Do you have any hint where to check first? -
I have the RFM69 setup working now with a couple of additional tweaks mainly for code optimization. Working fine for some time but stops after a few hours - I'll have a closer look the next couple of days.
Felix added three bytes to the payload (source address / destination address / control byte) to manage the acknowledge etc. in the lowpowerlab library. For our specific needs this is redundant as the current message format in development already includes this data. The three additional bytes are not that bad though and I'd propose to leave it like that for now and reconsider when we get to the revised message format :). -
I have the RFM69 setup working now with a couple of additional tweaks mainly for code optimization. Working fine for some time but stops after a few hours - I'll have a closer look the next couple of days.
Felix added three bytes to the payload (source address / destination address / control byte) to manage the acknowledge etc. in the lowpowerlab library. For our specific needs this is redundant as the current message format in development already includes this data. The three additional bytes are not that bad though and I'd propose to leave it like that for now and reconsider when we get to the revised message format :). -
RFM69 is stable now for >48h.
The OTA bootloader version for RFM69 is in progress. I'm stuck right now where the node debug messages show that it's sending a packet but the gateway doesn't receive anything... I moved the full initialization code back in that I thought would be ok to skip but still the same behavior. Only difference to the full blown driver at this point is that I don't attach the interrupt but that should not be relevant for tx as I'm polling the interrupt register for status (ready to send / send complete etc.). -
I had some time today to look at the bootloader code for RFM69 modules. Got the bootloader code to a point where it appears to be working fine - but the instability of the full MySensors RFM69 code is back - the serial gateway stops receiving packets after some time and it appears that the attempt to download a firmware by the bootloader just makes this problem more obvious due to the high volume of packets...
My prime suspect at the moment is the interrupt driven RFM69 library using a single packet buffer. As long is it's used sequentially everything should be fine but with e.g. submission or retrieval of ack messages it opens up the transceiver while the last packet was not fully processed yet potentially causing this... I'll go ahead and replace the routines in the library with the non-interrupt-driven version I coded for the bootloader just to see if this is the right place to dig deeper... -
@bbbio24 Hi
I am running into the same " ISO C++ forbids initialization of member 'radio'" error. Did you manage to solve this issue? am using IDE version 1.0.6. What version should I use?Update: I managed to get past this error.
By the way I am woring with the latest develpment branch that I downloaded from here https://github.com/mysensors/Arduino/archive/development.zip.
To get past this problem I changed in MyDriverRF69.h the lne 40 to
RFM69 *radio;// = NULL;
This resolved the problem in the arduino IDE 1.0.6. Admittedly I am very new to this whole thing and am not sure what I potentially broe by changing the line bt at least I can explore further. ;-) -
I used the Mysensors 1.4.1 library and managed to get a UNO with Ethernet shield and NRF24L01+PA+LNA working as an MQTT gateway.
I then changed the library to the latest development library (downloaded on 01.12.2014) and uploaded the MQTT gateway setch to the same hardware -> Also worked fine.
I then changed MyConfig.h to use the RF69 radio instead of NRF24 and just tried to compile. I got a lot of errors:
MQTT_Gateway_Compile_errors.txtI am using Arduino IDE 1.5.8
I am happy to help with testing, but I am afraid my programming skills are not good enough to assist with that.
-
@TOSA I just popped back into the forum to report on my experiences with instabilities using the current version of the RFM69 code only to find that you have already had the same experience. This makes me quite happy since it means that at least someone else have had a chance to think a bit about it. On a side note, I really wish this forum had some functionality to subscribe to topics, it is not a forum I visit regularly enough to catch everything that's happening.
I do not have any good information regarding why the microcontrollers stop responding, but I see it quite regularly in both the Gateway and in the sensors. For instance, I have a power measuring sensor that counts the blinks on my power meter and toggles a LED each time the power meter blinks. I have to reset this about every two days (sometimes more often) when I see that the LED no longer blinks. All my current sensors are running the first version of the code based on your rewritten radio obstructions.
Please let me know if there's anything I can do to help out with debugging this. The instability is starting to get quite frustrating, and I was actually considering to go back to my earlier prototype implementation based on the radiohead library. I did not experience any such instabilities using this library, so at least we know it is not a hardware problem. As such it shouldn't be too difficult to figure out. Maybe it is possible to discuss this with the lowpowerlabs guy who developed the library?
Unfortunately my experience with debugging microcontrollers is limited, but I will help out where I can.
-
@ToSa I am running this version and I don't have any problems with it so far. I only have one node up and running with a humility sensor. I order 5 more Anarduino units and hope to get them in Jan so will do more testing then. The humility node is up and running now for more than 3 weeks with out any resets.
-
RFM69 is stable now for >48h.
The OTA bootloader version for RFM69 is in progress. I'm stuck right now where the node debug messages show that it's sending a packet but the gateway doesn't receive anything... I moved the full initialization code back in that I thought would be ok to skip but still the same behavior. Only difference to the full blown driver at this point is that I don't attach the interrupt but that should not be relevant for tx as I'm polling the interrupt register for status (ready to send / send complete etc.). -
I used the Mysensors 1.4.1 library and managed to get a UNO with Ethernet shield and NRF24L01+PA+LNA working as an MQTT gateway.
I then changed the library to the latest development library (downloaded on 01.12.2014) and uploaded the MQTT gateway setch to the same hardware -> Also worked fine.
I then changed MyConfig.h to use the RF69 radio instead of NRF24 and just tried to compile. I got a lot of errors:
MQTT_Gateway_Compile_errors.txtI am using Arduino IDE 1.5.8
I am happy to help with testing, but I am afraid my programming skills are not good enough to assist with that.
@CARSTEN I got the same compile errors. It turns out Arduino IDE 1.5.7 and above have a new compiler which requires PROGMEM data to be const.
See this discussion: http://forum.arduino.cc/index.php?topic=277173.0I was able to resolve the compile errors by adding const where flagged by the compiler:
In MyMQTT.h:
. . . .
const char V_0[] PROGMEM = "TEMP"; //V_TEMP
etc . ..Then:
const char * const vType[] PROGMEM = {
V_0, V_1, . . . .You also need to change the getType function in MQTTGateway.ino to account for the change in type of vType[]
char *getType(char *b, const char * const *index) { . . . .Compiled with no errors for RFM69 on Arduino 1.5.8 after these changes.
I have not had a chance to upload and test on my Motineo's.
