Skip to content
  • MySensors
  • OpenHardware.io
  • Categories
  • Recent
  • Tags
  • Popular
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo
  1. Home
  2. Development
  3. Porting MySensors to work with the RadioHead library

Porting MySensors to work with the RadioHead library

Scheduled Pinned Locked Moved Development
portingradiohead
288 Posts 24 Posters 187.4k Views 12 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • K Offline
    K Offline
    kolaf
    Hero Member
    wrote on last edited by kolaf
    #236

    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.

    1 Reply Last reply
    0
    • K Offline
      K Offline
      kolaf
      Hero Member
      wrote on last edited by kolaf
      #237

      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;
       }
      
      hekH 1 Reply Last reply
      0
      • K 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;
         }
        
        hekH Offline
        hekH Offline
        hek
        Admin
        wrote on last edited by
        #238

        @kolaf

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

        K 1 Reply Last reply
        0
        • ? Offline
          ? Offline
          A Former User
          wrote on last edited by
          #239

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

          1 Reply Last reply
          0
          • hekH hek

            @kolaf

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

            K Offline
            K Offline
            kolaf
            Hero Member
            wrote on last edited by
            #240

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

            hekH 1 Reply Last reply
            0
            • K kolaf

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

              hekH Offline
              hekH Offline
              hek
              Admin
              wrote on last edited by
              #241

              @kolaf

              :thumbsup:

              1 Reply Last reply
              0
              • hekH Offline
                hekH Offline
                hek
                Admin
                wrote on last edited by
                #242

                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.

                R 1 Reply Last reply
                0
                • hekH 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.

                  R Offline
                  R Offline
                  reddy11
                  wrote on last edited by
                  #243

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

                  1 Reply Last reply
                  0
                  • hekH Offline
                    hekH Offline
                    hek
                    Admin
                    wrote on last edited by
                    #244

                    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);
                    
                    1 Reply Last reply
                    0
                    • K Offline
                      K Offline
                      kolaf
                      Hero Member
                      wrote on last edited by
                      #245

                      @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));
                      
                      1 Reply Last reply
                      0
                      • hekH Offline
                        hekH Offline
                        hek
                        Admin
                        wrote on last edited by
                        #246

                        @kolaf
                        Sound good.

                        K 1 Reply Last reply
                        0
                        • ? Offline
                          ? Offline
                          A Former User
                          wrote on last edited by
                          #247

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

                          1 Reply Last reply
                          0
                          • hekH hek

                            @kolaf
                            Sound good.

                            K Offline
                            K Offline
                            kolaf
                            Hero Member
                            wrote on last edited by kolaf
                            #248

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

                            1 Reply Last reply
                            0
                            • K Offline
                              K Offline
                              kolaf
                              Hero Member
                              wrote on last edited by
                              #249

                              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.

                              1 Reply Last reply
                              0
                              • K Offline
                                K Offline
                                kolaf
                                Hero Member
                                wrote on last edited by
                                #250

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

                                1 Reply Last reply
                                0
                                • K Offline
                                  K Offline
                                  kolaf
                                  Hero Member
                                  wrote on last edited by
                                  #251

                                  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 */
                                  }
                                  
                                  hekH 1 Reply Last reply
                                  0
                                  • K 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 */
                                    }
                                    
                                    hekH Offline
                                    hekH Offline
                                    hek
                                    Admin
                                    wrote on last edited by
                                    #252

                                    @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

                                    K 1 Reply Last reply
                                    0
                                    • hekH 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

                                      K Offline
                                      K Offline
                                      kolaf
                                      Hero Member
                                      wrote on last edited by kolaf
                                      #253

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

                                      1 Reply Last reply
                                      0
                                      • hekH Offline
                                        hekH Offline
                                        hek
                                        Admin
                                        wrote on last edited by
                                        #254

                                        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.

                                        1 Reply Last reply
                                        0
                                        • K Offline
                                          K Offline
                                          kolaf
                                          Hero Member
                                          wrote on last edited by
                                          #255

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

                                          1 Reply Last reply
                                          0
                                          Reply
                                          • Reply as topic
                                          Log in to reply
                                          • Oldest to Newest
                                          • Newest to Oldest
                                          • Most Votes


                                          14

                                          Online

                                          11.7k

                                          Users

                                          11.2k

                                          Topics

                                          113.0k

                                          Posts


                                          Copyright 2019 TBD   |   Forum Guidelines   |   Privacy Policy   |   Terms of Service
                                          • Login

                                          • Don't have an account? Register

                                          • Login or register to search.
                                          • First post
                                            Last post
                                          0
                                          • MySensors
                                          • OpenHardware.io
                                          • Categories
                                          • Recent
                                          • Tags
                                          • Popular