Porting MySensors to work with the RadioHead library

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

[A Former User]

@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

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

[A Former User]

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

[kolaf]

I narrowed it down even further. It appears that there is no appropriate interrupt and present to handle when the watchdog fires. I have no idea why this is the case, and I do not know if this fix is correct, but by a placing this code somewhere in MySensors.cpp everything works nicely:

ISR( WDT_vect ) {
    /* dummy */
}

[hek]

@kolaf

Ok, strange. Would be nice to know why this fixes the problem,

It should probably be placed here if it's atmega328 related (and only need to be called once):
https://github.com/mysensors/Arduino/blob/development/libraries/MySensors/MyHwATMega328.h#L22

[kolaf]

@hek
As far as I know the function is the interrupt routine that is called by the watchdog when the time expires. I guess it doesn't matter where it is defined so it should be fine to move it. It is not called explicitly anywhere in the code, but by the watchdog. As such, I don't think it should be defined as is done in the header file for the other functions.

My question is why is it not working for me without this code, I assume it has been working for everyone else?

[hek]

Ah.. doh..

Moved parts of the low-power library into MyHwATMega328 and forgot the ISR-thingie.

https://github.com/mysensors/Arduino/blob/master/libraries/MySensors/utility/LowPower.cpp#L850

Good catch.

[kolaf]

Glad I could help :-). I guess my prize will be that you patch this so that I do not have to create a pull request

[kolaf]

I might as well continue while I'm at it

Another weird issue I'm having is that every node requests a new ID whenever it starts, but it does not switch to the new ID it receives. It just continues with the old ID it already had.

When I wipe the ROM it requests a new ID as expected, and this time it is saved and used for subsequent communication. Why is it requesting a new ID when it boots, when it already has one?

[hek]

@kolaf

Should not happen. Will look at it later tonight.

[hek]

Ok, finally got the thumbs out and actually tested the RFM69 code using a couple of Moteinos. They seem to communicate just fine.

Tested with SerialGateway<->RelayActuator-Example.

[reddy11]

I can also report success and things look pretty good. Had to change the line:

//MyTransportRFM69 transport;
MyTransportRFM69 transport(RFM69_FREQUENCY, RFM69_NETWORKID, RF69_SPI_CS, RF69_IRQ_PIN, true, RF69_IRQ_NUM);

So that the rfm69HW could be supported.

Now, on to see if I can get the MQTT working.

[kolaf]

@reddy11 I had to do the same, although I did the change in the default parameters for the function definition since all my radios are HW :-).

I'm not using the MQTT gateway, I'm using the serial gateway together with a Perl script someone here made which functions as a MQTT gateway, and which I modified to handle node ID assignments.

[kolaf]

@hek You didn't see any extra node ID requests when the sensor booted?

[tekka]

@kolaf are you using the OTA bootloader?

[kolaf]

@tekka said:

@kolaf are you using the OTA bootloader?

No, I haven't figured out that part yet. I'm not even sure if I have available flash memory for this, nor if this is expected to work with the rf69 radios.

[tekka]

@kolaf ok, i was asking because there is an issue wIth the ID assignment and the OTA bl in the dev branch resulting in the scenario you described.

[A Former User]

Thanks everybody for the nice work! My initial tests also work out of the box with a serial gateway and humidity node. I will let it run over the weekend to see if there are any issues coming up.

[lafleur]

I have serial gateway running on a MoteinoMega and a node running on a Moteino with RFM69HW radios... Using the 2April2015 build of the development arm... with the addition of the :

//MyTransportRFM69 transport;
MyTransportRFM69 transport(RFM69_FREQUENCY, RFM69_NETWORKID, RF69_SPI_CS, RF69_IRQ_PIN, true, RF69_IRQ_NUM);

and the correct pin-out for the radios and LED for these boards...

I needed to mod the MsTimer2.cpp file to add 'AVR_ATmega1284P ' to each of the #ifdef line to support the Mega

As I do not yet have a controller running, I see the gateway output as below when the node TX's:

0;0;3;0;9;read: 255-255-0 s=255,c=3,t=3,pt=0,l=0,sg=0:255;255;3;0;3;

[lafleur]

I need a simple controller that can plot data that can be viewed on a web server... Mac/Pi or ??
want hr/day/week/mo/yr plots..

what do you recommend??

[reddy11]

@kolaf I gave up on getting the MQTT gateway working. I just dont think there is enough memory in my moteino to use the rf69 and the uipethernet library. I was able to get it to work, but it would crash after a few min. When I updated to the latest UIPEthernet library for the 1.5 series, It was too large to upload. So....anyway...can you elaborate on, or point me to the serial-mqtt script you were referring to?
Thanks!

[kolaf]

@reddy11 Sure, you can find it here: https://github.com/Yveaux/MySensors_MQTTGateway

You will want to use version 2 of the script.

It does simple note ID assignments by keeping a list of all ids it has seen and choosing the first ID not in this list when receiving an ID request.

There are some dependencies, but you will notice that as you start the script

[nikorun]

Hi,

i've tried to scroll back many of the pages of this thread, to find out how to use the Radiohead version of mysensors but with no success, considering that i don"t understand many of those things said here ...

Is there someone that can help me a little and give me a minimalist modop ? i've used Radiohead on its own with 3 moteinos but mooving to MySensors seem to be the best way to integrate them in a standard domotix architecture ... i currently use Jeedom for a year now.

Of course, you'll have my feedbacks ...

Nicolas

[hek]

Use the development branch (https://github.com/mysensors/Arduino/tree/development/libraries/MySensors)
and enable MyTransportRFM69 transport layer in gateway and sensor.

Uncomment this line for gateway (and use the same setup for sensor):
https://github.com/mysensors/Arduino/blob/development/libraries/MySensors/examples/SerialGateway/SerialGateway.ino#L63

[nikorun]

Hello Hek,

Thanks for your answer, I will try this as soon as I'll be back home.

When you say* "uncomment this line ..."* , do I have to comment the previous one (MyTransportNRF24 transport(RF24_CE_PIN, RF24_CS_PIN, RF24_PA_LEVEL_GW);) ?
Furthermore, as described in your exemple, the line to be uncommented has no argument but in a previous post reddy11 has to add several ones:
MyTransportRFM69 transport(RFM69_FREQUENCY, RFM69_NETWORKID, RF69_SPI_CS, RF69_IRQ_PIN, true, RF69_IRQ_NUM);

Is it only due to the "H" version of the module ?

Again, thanks for your time. I really think Radiohead is a impressive library as well as MySensor si very smart , the both should be terrible !!!

Nicolas

[hek]

Yes, disable or remove the MyTransportNRF24 transport line.

If you write

MyTransportRFM69 transport;

It will use default constructor arguments defined here:
https://github.com/mysensors/Arduino/blob/development/libraries/MySensors/MyTransportRFM69.h#L33
and here:
https://github.com/mysensors/Arduino/blob/development/libraries/MySensors/MyConfig.h#L129-L133

[nikorun]

Hello,

Well ... things are not going the way I expected. i have done a fresh install of Arduino 1.6.4 on my Windows PC, then Downloaded the zip from devellopment branch and extracted it in the Sketch directory.
Then I have opened the .\libraries\MySensors\examples\SerialGateway\SerialGateway.cpp (wich also opens GatewayUtil.h).
Then I compiled it :

• The first error was : "... \MyHwATMega328.cpp:22:22: fatal error: LowPower.h: No such file or directory" , I solved it by copying the requested files in the MySensor directory
• The second error then was : " .... LowPower.h:4:6: error: multiple definition of 'enum period_t'", I solved it by deleting the corresponding def in LowPower.h

Other errors happened so I thought that there was probably another problem, in my install or something else.

I also tried with 1.0.5 but it failed too.

I don't want to spend much off all your time but as you hepled me, I'm must at least inform you of what happens with my experience .... of course if some of you have a luminous idea about what is going on with my install, I'm (very) interested.

Nicolas

Rq : I have tried to search some help in this thread and on google but I guess if a lot of little problems are coming up, it must be a global problem with my PC .

Bye

[hek]

LowPower library shouldn't be needed any more if you're using the latest code in development branch.

[Francois]

@kolaf Do you run any of your node off batteries if you do what is you current consumption?

[nikorun]

Hi,

Just wanna say that I've finaly compiled the sketch, on another computer....
I've tested it succesfully with SerialGateway and LightSensor.
As I have a high power module, I had to change the transport declaration as mentionned before:
MyTransportRFM69 transport(RFM69_FREQUENCY, RFM69_NETWORKID, RF69_SPI_CS, RF69_IRQ_PIN, true, RF69_IRQ_NUM)
it works well for me but I had to change the RFM69 frequency in Myconfig.h, by uncommenting
#define RFM69_FREQUENCY RF69_433MHZ
and of course commenting
//#define RFM69_FREQUENCY RF69_868MHZ

To use LightSensor , I changed some declarations in LighSensor.ino. Instead of simply have :
MySensor gw;

I had to declarations before to use the RFM69 module :
MyTransportRFM69 radio;
MyHwATMega328 hw;
MySensor gw(radio, hw);

I tested it with the excellent Windos GUI Controller made by tekka and found here

Again thanks for your help, I'm now trying to use it with Jeedom, It doesn't work yet but ... it's another story ...:-)

Bye

[nagelc]

Does anyone have a MQTT gateway working with the RFM69?
I've been using a MQTT gateway with the W5100 / NRF24 (soft SPI) from the MySensors 1.4 branch -- works well.
I have a RFM69 serial gateway working from the development branch.
My first attempt at an MQTT gateway with the RFM69 (soft SPI) and W5100 hangs up in the gw.begin() function. I wasn't sure what to do about the RFM69 interrupt line. Before digging any deeper, I was hoping someone might have worked this out already.

[kolaf]

I'm still having some problems with the sensors being a bit unreliable. For instance, I have a Power sensor that detects LED blinks off my power meter and switches its own LED at every blink so that I can actually see if anything is happening. This works fine for several days, and power usage reports are sent to the gateway at regular intervals (two minutes), but then suddenly the power reports stop. The LED keeps blinking, indicating that the sketch is actually doing what it is supposed to, but for some reason the radio stops doing anything.

I have also had this happen on the gateway, the radio stopped responding after some time even though the sketch seems to be running. This is both on the moteino and anarduino with the RF 69 radios.

I have no idea what is causing this, but my best guess is that some kind of buffer is overrun, or maybe a counter?

Not really sure how to debug a problem like this, but I think the first attempt will be to try to reinitialise the radio after a specific amount of time to see if this clears the problem. The time before the issues occur can vary from 10 hours to 5 days, though, so it is a bit difficult to test...

[rvendrame]

@kolaf, how are you powering the radio? Cheap phone chargers usually introduce noise into the power line, which drives the radio crazy. A capacitor between radio VCC / GND help in some circumstances: :

http://www.mysensors.org/build/connect_radio

[kolaf]

The radio is integrated into the Arduino board, so it is difficult for me to do anything with the radio VCC line. Anyway, the gateway is powered directly by the computer, home of the power sensor is powered by a Samsung charger which should be relatively good quality?

[rvendrame]

@kolaf, maybe you could replace the charger by another one, just to see if something changes. The radio is really sensitive to power fluctuations (while arduino itself isn't).

[Francois]

@kolaf I run the same setup now for more than a 2 month and don't have this issue. For now I am running the power sensor of battery as my meter is outside my house as there is no 220 plug to run it off power supply. I still have a very small RF69 sensor network. I have 10 NRF24 sensor that I am now converting to RF69. Can this issue that you experience be to the size of your sensor network?

Here is some data from my power sensor for this week:

[kolaf]

Thanks for the suggestions, and for the proof that can actually work long-term :-).

I have now replaced the 220 V adapter with another one, so let's see how it goes now.

@Francois: I assume youre figures are from domoticz or something similar? How do you like it? I have used openhab for quite some time before I tried to switch to domoticz for a few months. I found that adding new sensors and displaying data was much easier in domoitcz, but the rule and persistence system of openhab is much better, as much so as to outweigh the benefits of domoticz. I switched back to Openhab a few weeks ago.

BTW, you don't want to see my power Usage numbers, they average around 5000W with a peak at nearly 15 kilowatts, Depending on what is running. This covers a full farm with two houses, a big barn, and some other stuff, but still...

[Francois]

@kolaf yes I am running domoticz as it is easy to add sensor. I never had any luck with getting openhab to run. I am wait for the release of openhab2. BTW I am running my rf69 via a serial gateway. Do you the have 3 phase power to your farm?

[kolaf]

I'm also using the serial Gateway via a mqtt perl script to send recorded values to the broker, and then a is the mqtt binding in openhab to communicate with the sensor network.

Yes, we have a three phase power, into the building, as was going out to both the bon and the secondary house. I've been looking into getting one of these clamp power meters, but I'm not sure if these can deal with a three-phase power. I would very much like to be able to measure the amount of power that is consumed by the secondary house so that I can get an exact amount he should pay for the electricity bill :-).

Do you have any experience with using clamp power meters on three-phase power?

[Francois]

@kolaf sorry no I didn't play with clamp power probes yet

[luisgcu]

Hello folks.
There is any plan to include into mysensors the LoRa RFM95 ,96? I am currently testing one those modules at 433mhz with RadioHead library. I had conducted some test in suburban environment and getting around 1.8 miles range. I pretend to apply this for remote water pump control monitoring in farms. I still want to try the rfm69 and see how much range I can cover . Any advice will be highly appreciated.
Regards