Porting MySensors to work with the RadioHead library

hek

we waiting for this

I'm waiting also. Please do the test @dzairo!

dzairo

sorry .. is possible make test with this module if you have it ?
I can compare only nrf24l01+ with cc1101 868mhz ..
in free area is possible with standard nrf24l01+ with good antenna from wifi get 200m .. pcb antenna give less then 30m . rfm69hw is good because is possible set lowe transfer speed less then in nrf24l01+ ..
if make test with CC1101 868mhz version with +14dB output power then no problem get distance in my house 3 floor ..

best regards

? Offline

@lafleur:
I only removed the "signer" out of the initialization and changed the line to the code above. I did not comment the whole line.

@kolaf:
To make the library work for the RFM69HW for me, I needed to change the radio pointer to an object amongst other things.., which combination did eventually do the trick, I do not know for sure.
I will summarize the changes I did to get connection between two nodes using the RFM69HWs.

The problem I had was that the radio would not start up for me. It was stuck at the RFM69.cpp initialization at:

do writeReg(REG_SYNCVALUE1, 0xAA); while (readReg(REG_SYNCVALUE1) != 0xAA);
do writeReg(REG_SYNCVALUE1, 0x55); while (readReg(REG_SYNCVALUE1) != 0x55);

So the changes I did were:

In MyTransportRF69.h:

@@ -37,7 +37,7 @@ public:
        uint8_t receive(void* data);
        void powerDown();
 private:
-       RFM69 *radio;
+       RFM69 radio;
        uint8_t _address;
 };

and in MyTransportRF69.cpp:

 MyTransportRF69::MyTransportRF69()
        :
        MyTransport(),
-       radio()
+       radio(10,2,true,0)  //I set the Pins manually (SPI SS 10, InterruptPin 2, IsHW = true, and InternalInterrupt 0)
 {
 }
 void MyTransportRF69::init() {
        // Start up the radio library
-    radio->initialize(FREQUENCY,_address,NETWORKID);
+    radio.initialize(FREQUENCY,2,NETWORKID); //I changed the node_ids manually for each node, see below for comment
+    radio.rcCalibration();
+    Serial.println("Radio init done");
 #ifdef IS_RFM69HW
-    radio->setHighPower(); //uncomment only for RFM69HW!
+    radio.setHighPower(); //uncomment only for RFM69HW!
 #endif
-    // radio->encrypt(ENCRYPTKEY);
+    radio.setPowerLevel(20); //I decreased the powerlevel a bit, since I had some troubles transmitting between two nodes on my desk before when using the full power.

of course change all the following "radio->" to "radio." with string replace.

Also I realized that the NODEID is not set properly using the _address argument, I had a serial println there and it always returned "0 (zero)", which should not be correct. So I set them manually for each node.
I also copied the latest version of Felix LowPowerRFM library into utils from here:
https://github.com/LowPowerLab/RFM69
(I do not know if they differ much, the diff is not very conclusive due to different formatting)

I am using an Arduino Buono UNO clone set with a switch to run at 3.3V with the RFM69HW connected via breadboard. With the changes above, all was compiled and started up.

But I had a major problem with the Dev branch that in general that no ACKs at all were send or at least received, even when using the NRF2401+. So that is why I did not continue with the RFM69HW at the moment. The master branch on the very same setup (using the standard radio) did work without any troubles.

I managed to get connection between the nodes (e.g. in the serial output of the gateway the request for parent was received, but all messages had a "failed" status). I last checked the dev-branch last week.
I am away over Easter, but am willing to try a bit more afterwards, if I get the Dev branch running in general with ACKs...

I got inspired by this project:
http://www.instructables.com/id/Uber-Home-Automation-w-Arduino-Pi/?ALLSTEPS
There is also a forum here:
http://homeautomation.proboards.com/board/2/openhab-rfm69-based-arduino
but eventually I turned here, since mysensors seems to have more active support and a already a bigger community and codebase. However there they have a RFM69 gateway running with nodes. So it might be worth to check it out how they did it (that is also how I got the RFM69 running in the first place).

Sorry for the long post..

Cheers!

hek

@daenny

Thanks for the analysis. The RFM69 code really need a loving hand after being almost untouched for months since ToSa disappeared. There shouldn't be any changes done to the LowPowerLab code (but it hasn't been updated either).

The question is if hardware acks i coming in but is just picked up wrongly from LowPowerLab-library?

I should really setup a test rig with those radios... But my time is limited.. If you're interested in helping out finding the root cause for the RFM69 ack-problems I would be super grateful.

The ack-problems you're seeing on NRF24L01 will investigate by me.

kolaf

@daenny I've started playing with it now, and the first fix for your pointer problem is to initialise the radio pointer correctly which is not done in the current implementation. I simply added the following line to the beginning of init:

radio=new RFM69();

No further changes were then necessary to the pointers.

kolaf

I have two devices talking to each other, but I'm a bit rusty, so can't immediately see what's happening from the output. This is the sensor side:

req id
send: 3-3-0-0 s=255,c=3,t=3,pt=0,l=0,sg=0,st=fail:
send: 3-3-0-0 s=255,c=0,t=17,pt=0,l=5,sg=0,st=fail:1.4.1
send: 3-3-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,st=fail:0
sensor started, id=3, parent=0, distance=1
send: 3-3-0-0 s=255,c=3,t=11,pt=0,l=12,sg=0,st=fail:Power sensor
send: 3-3-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,st=fail:1.0
send: 3-3-0-0 s=1,c=0,t=13,pt=0,l=5,sg=0,st=fail:1.4.1
send: 3-3-0-0 s=2,c=0,t=6,pt=0,l=5,sg=0,st=fail:1.4.1
find parent
send: 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,st=bc:

And this is the gateway side:

0;0;3;0;9;gateway started, id=255, parent=0, distance=1
0;0;3;0;14;Gateway startup complete.
0;0;3;0;9;read: 3-3-255 s=255,c=3,t=7,pt=0,l=0,sg=0:
3;255;3;0;7;
0;0;3;0;9;read: 3-3-255 s=255,c=3,t=7,pt=0,l=0,sg=0:
3;255;3;0;7;
0;0;3;0;9;read: 3-3-255 s=255,c=3,t=7,pt=0,l=0,sg=0:
3;255;3;0;7;

Can anyone tell me what is happening here? I'm using a sensor I configured a long time ago, so it is already received its ID from the gateway previously.

kolaf

Okay, I have done some digging.

The gist of my last post was that it received no response for any of the messages sent directly to the Gateway, they never even arrived at the gateway. The only message that arrived was the broadcast message.

The first hints for me was the initialisation string from the gateway. It indicates that it is initialised with the address 255. This is a bit weird, since the Gateway source code provides a value of 0 to gw.begin(). Looking into the source for this it turns out that the value provided here is never stored in the node configuration, and thus is never used as the address for the node. I made some changes to store the address in the node configuration, and suddenly the Gateway started to respond to the messages from the sensor.

As for the acknowledgements, it turns out that ACKRequested never seems to return true even if we use sendWithRetries. If we assume this to be true and transmit acknowledgements regardless (which is correct since we always use send with retries) the status of all the send messages from the sensor revert to "ok".

I guess that this fixed to the acknowledgements issue is good enough for now, but I am definitely not sure about the issues with the Gateway node id. Any thoughts on this would be very welcome.

diff --git a/libraries/MySensors/MySensor.cpp b/libraries/MySensors/MySensor.cpp
index 91644e0..d5badb3 100755
--- a/libraries/MySensors/MySensor.cpp
+++ b/libraries/MySensors/MySensor.cpp
@@ -142,6 +142,13 @@ void MySensor::begin(void (*_msgCallback)(const MyMessage &), uint8_t _nodeId, b
 			// Try to fetch node-id from gateway
 			requestNodeId();
 		}
+	} else {
+				if (_nodeId != AUTO) {
+			// Set static id
+			nc.nodeId = _nodeId;
+			// Save static id in eeprom
+			hw_writeConfig(EEPROM_NODE_ID_ADDRESS, _nodeId);
+			}
 	}
 
 	setupNode();
diff --git a/libraries/MySensors/MyTransportRF69.cpp b/libraries/MySensors/MyTransportRF69.cpp
index b55ce14..3874773 100644
--- a/libraries/MySensors/MyTransportRF69.cpp
+++ b/libraries/MySensors/MyTransportRF69.cpp
@@ -29,7 +29,7 @@ uint8_t MyTransportRF69::getAddress() {
 
 bool MyTransportRF69::send(uint8_t to, const void* data, uint8_t len) {
 	// Make sure radio has powered up
-	return radio->sendWithRetry(to,data,len);
+	return radio->sendWithRetry(to,data,len,5,200);
 }
 
 bool MyTransportRF69::available(uint8_t *to) {
@@ -45,9 +45,13 @@ uint8_t MyTransportRF69::receive(void* data) {
 		// data[i]= (void)radio->DATA[i];
 	// }
 	memcpy(data,(const void *)radio->DATA, radio->DATALEN);
-	if (radio->ACKRequested())
+	if (radio->ACKRequested() || 1)
     {
+      Serial.println("Acknowledgement requested");
       radio->sendACK();
+      Serial.println("Sent acknowledgement");
+    } else {
+    	Serial.println("Not wanting acknowledgement");
     }
 	return radio->DATALEN;
 }

hek

@kolaf

Thanks! I will have a look at the id=0 problem tonight.

? Offline

@kolaf
Nice work, I am new completely new to the MySensors code, so I could not dig into it deep enough to see how everything is build up.
I completely overlooked that the pointer is not initialized properly, but your fix is definitively easier :).

@hek
My guess is that the problem with the ACKs and Gateway ID could be the same for the nrf radio, which might explain the troubles I had with the dev branch?

kolaf

@hek
Great. In the meantime I'm doing some stability testing of the current code base.

hek

@kolaf

:thumbsup:

hek

Ok, tried to clean up some of the mess in RFM69 (and gw node id).

I have a hard time to do any verification tonight here (the family sleeping too near the "lab room"). Would be great to get some feedback if you have your gears setup and ready for tests.

reddy11

@hek
Thank you for taking a look at the RFM69 code. I downloaded the development branch. While I was able to get it to compile, it does not seem to work, but Im note sure if it is something I am doing.
Background:
I had the RFM69 radio working with code from the development branch I downloaded in early Jan. I have a few sensors that and a serial gateway using the Jan code.

After downloading the latest development branch I tried to update my serial gateway, assuming it would still be able to read the sensors with the older code.

Observations:
Currently I cannot see any of the older nodes that I have. I have not tried to update any of the nodes yet, so I don't know if my problem is with the current code or not.
Currently there is not a myconfig.h option to set the RFM69HW option

I have been stumbing around the code trying to get a feel for it, and I am not and expert but am wondering if Line 137 of Mysensor.h has anything to do with the problem?

	MySensor(MyTransport &radio =*new MyTransportNRF24(), MyHw &hw=*new MyHwDriver()

Should there be something that would define MyTransportRFM69 instead?

Thoughts?

Would love to get this working and ultimately figure out the MQTT server options.

Thanks!

hek

Yes, it differs a bit. You can now initialise the transport using RFM69 like this (see constructor default values in https://github.com/mysensors/Arduino/blob/development/libraries/MySensors/MyTransportRFM69.h.
5:th argument is the one you're looking for. I Might add a default for this in MyConfig as well if this is something people change often.

#include <MyTransportRFM69.h>
#include <MySensor.h>

MyTransportRFM69 transport(freqBand, networkId,  slaveSelectPin, interruptPin, isRFM69HW, interruptNum);

MySensors gw(transport);

kolaf

@hek I updated with your latest changes and refreshed my node and gateway (which I am happy to report has run stable since yesterday). Things seem to work out of the box now which is good. There is a small issue, I think, where you could use the GATEWAY_ADDRESS a few more places for consistency, but apart from that I'm quite happy :-).

diff --git a/libraries/MySensors/MySensor.cpp b/libraries/MySensors/MySensor.cpp
index 70d3680..4a87e33 100755
--- a/libraries/MySensors/MySensor.cpp
+++ b/libraries/MySensors/MySensor.cpp
@@ -101,9 +101,9 @@ void MySensor::begin(void (*_msgCallback)(const MyMessage &), uint8_t _nodeId, b
 
 	if (isGateway) {
 		// Set configuration for gateway
-		nc.parentNodeId = 0;
+		nc.parentNodeId = GATEWAY_ADDRESS;
 		nc.distance = 0;
-		nc.nodeId = 0;
+		nc.nodeId = GATEWAY_ADDRESS;
 	} else {
 		// Read settings from eeprom
 		hw_readConfigBlock((void*)&nc, (void*)EEPROM_NODE_ID_ADDRESS, sizeof(NodeConfig));

hek

@kolaf
Sound good.

? Offline

@kolaf and @hek
Thanks for the great work. I will try to setup a test node and gateway by tomorrow and let it run over the Easter weekend. Hopefully it still runs when I am back :)

kolaf

@hek I tried setting up a second sensor (temperature and power supply voltage) with the updated library. I wiped eeprom, uploaded the sketch, and fired it up.

It requested a node ID from the gateway, which it received, and everything seemed to go smoothly until it had transmitted the first data point. After that it immediately enters a request for a new node ID, which it receives, and things go in an endless loop. Here is the log:

find parent
send: 255-255-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,st=bc:
read: 0-0-255 s=255,c=3,t=8,pt=1,l=1,sg=0:0
parent=0, d=1
req id
send: 255-255-0-0 s=255,c=3,t=3,pt=0,l=0,sg=0,st=ok:
read: 0-0-255 s=255,c=3,t=4,pt=0,l=1,sg=0:1
send: 1-1-0-0 s=255,c=0,t=17,pt=0,l=5,sg=0,st=ok:1.4.1
send: 1-1-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,st=ok:0
id=1
send: 1-1-0-0 s=255,c=0,t=17,pt=0,l=5,sg=0,st=ok:1.4.1
send: 1-1-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,st=ok:0
sensor started, id=1, parent=0, distance=1
send: 1-1-0-0 s=255,c=3,t=11,pt=0,l=20,sg=0,st=ok:Temperature basement
send: 1-1-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,st=ok:1.0
send: 1-1-0-0 s=1,c=0,t=6,pt=0,l=5,sg=0,st=ok:1.4.1
send: 1-1-0-0 s=2,c=0,t=13,pt=0,l=5,sg=0,st=ok:1.4.1
1023send: 1-1-0-0 s=2,c=1,t=38,pt=7,l=5,sg=0,st=ok:5.4
send: 1-1-0-0 s=255,c=3,t=0,pt=1,l=1,sg=0,st=ok:102
send: 1-1-0-0 s=1,c=1,t=0,pt=7,l=5,sg=0,st=ok:20.6
req id
send: 1-1-0-0 s=255,c=3,t=3,pt=0,l=0,sg=0,st=ok:
read: 0-0-1 s=255,c=3,t=4,pt=0,l=1,sg=0:3
send: 1-1-0-0 s=255,c=0,t=17,pt=0,l=5,sg=0,st=ok:1.4.1
send: 1-1-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,st=ok:0
sensor started, id=1, parent=0, distance=1
send: 1-1-0-0 s=255,c=3,t=11,pt=0,l=20,sg=0,st=ok:Temperature basement
send: 1-1-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,st=ok:1.0
send: 1-1-0-0 s=1,c=0,t=6,pt=0,l=5,sg=0,st=ok:1.4.1
send: 1-1-0-0 s=2,c=0,t=13,pt=0,l=5,sg=0,st=ok:1.4.1
955send: 1-1-0-0 s=2,c=1,t=38,pt=7,l=5,sg=0,st=ok:5.0
send: 1-1-0-0 s=255,c=3,t=0,pt=1,l=1,sg=0,st=ok:95
send: 1-1-0-0 s=1,c=1,t=0,pt=7,l=5,sg=0,st=ok:20.7
req id
send: 1-1-0-0 s=255,c=3,t=3,pt=0,l=0,sg=0,st=ok:
read: 0-0-1 s=255,c=3,t=4,pt=0,l=1,sg=0:3
send: 1-1-0-0 s=255,c=0,t=17,pt=0,l=5,sg=0,st=ok:1.4.1
send: 1-1-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,st=ok:0
sensor started, id=1, parent=0, distance=1
send: 1-1-0-0 s=255,c=3,t=11,pt=0,l=20,sg=0,st=ok:Temperature basement
send: 1-1-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,st=ok:1.0
send: 1-1-0-0 s=1,c=0,t=6,pt=0,l=5,sg=0,st=ok:1.4.1
send: 1-1-0-0 s=2,c=0,t=13,pt=0,l=5,sg=0,st=ok:1.4.1
956send: 1-1-0-0 s=2,c=1,t=38,pt=7,l=5,sg=0,st=ok:5.0
send: 1-1-0-0 s=255,c=3,t=0,pt=1,l=1,sg=0,st=ok:95
send: 1-1-0-0 s=1,c=1,t=0,pt=7,l=5,sg=0,st=ok:20.7

As far as I can see this should be caused by the node ID still being AUTO, but this shouldn't be the case since it appears to be correctly stored in ROM?

kolaf

Please disregard my previous "analysis"/guess. It turns out that the repeating behaviour that was caused by a program crash. The trigger for this crash is MyHwATMega328::sleep(ms) . I'm running a RFM69HW radio on a anarduino board, which should be using the ATMega 328 chip, same as the moteino.

By replacing the call to this function in MySensor::sleep(unsigned long ms) with a simple delay(ms), the crashes no longer occur.

kolaf

My current guess is that the watchdog timer resets the chip after the time period instead of throwing an interrupt to wake the system...?

Porting MySensors to work with the RadioHead library

8

11.7k

11.2k

113.0k