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. Bug Reports
  3. Sleep() with interrupt only works with level "LOW"

Sleep() with interrupt only works with level "LOW"

Scheduled Pinned Locked Moved Bug Reports
18 Posts 6 Posters 4.6k Views 5 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.
  • AWIA Offline
    AWIA Offline
    AWI
    Hero Member
    wrote on last edited by AWI
    #1

    Concluding from @Yveaux 's thorough analysis of sleep() in combination with interrupts there is a lot of chatching up to do. My experiments currently (2.1.1.) show a consistent erratic behaviour when using sleep() in conjunction with FALLING/ RISING/ CHANGE. HIGH is not possible with the atmega328 so only LOW remains... (not documented in the API yet). Previously usign CHANGE was common practice in MySensors and 'seemed' to be functioning.
    Unless there is a solution we need to change the API description and examples (i.e motion detector) and create awareness.
    Or are there other ways to get back to our common practice?

    YveauxY 1 Reply Last reply
    0
    • D Offline
      D Offline
      DavidZH
      wrote on last edited by
      #2

      I've been following that development. And I think it's good that MySensors follows the rules as set by Atmel.

      To be able to use more interrupt pins at the same time I have been looking into pin change interrupts. Those are triggered as the designated pin changes state, either LOW->HIGH or the other way round.

      I think by changing MyHWAVR.cpp (and the comparable files for other hardware) a little, my sensors is capable of using PCI's to wake the node. There is always a negative, and in this case I think its the amount of code needed to see what pin caused the interrupt. The work done by GreyGnome with the EnableInterrupt library shows that very well. The lib is also huge because of the way they use enabling and disabling of the pins with software to emulate the other modes(RISING, FALLING, HIGH and LOW).

      This is not THE solution. It's only one of the ways to be able to use the other modes with a pin.

      1 Reply Last reply
      1
      • AWIA AWI

        Concluding from @Yveaux 's thorough analysis of sleep() in combination with interrupts there is a lot of chatching up to do. My experiments currently (2.1.1.) show a consistent erratic behaviour when using sleep() in conjunction with FALLING/ RISING/ CHANGE. HIGH is not possible with the atmega328 so only LOW remains... (not documented in the API yet). Previously usign CHANGE was common practice in MySensors and 'seemed' to be functioning.
        Unless there is a solution we need to change the API description and examples (i.e motion detector) and create awareness.
        Or are there other ways to get back to our common practice?

        YveauxY Offline
        YveauxY Offline
        Yveaux
        Mod
        wrote on last edited by
        #3

        @AWI I agree the code & examples need some work on the sleeping topic.
        Following the ATMega specs will indeed only allow to wake on LOW level, while e.g. PIRs will generally produce a HIGH level on motion.
        Ofcourse this can be fixed in hardware, but I'd prefer to first have a look at pinchange ints as @DavidZH suggests.
        I'm not sure if including the suggested library is the way to go; we have to look into that.

        http://yveaux.blogspot.nl

        AWIA 1 Reply Last reply
        0
        • YveauxY Yveaux

          @AWI I agree the code & examples need some work on the sleeping topic.
          Following the ATMega specs will indeed only allow to wake on LOW level, while e.g. PIRs will generally produce a HIGH level on motion.
          Ofcourse this can be fixed in hardware, but I'd prefer to first have a look at pinchange ints as @DavidZH suggests.
          I'm not sure if including the suggested library is the way to go; we have to look into that.

          AWIA Offline
          AWIA Offline
          AWI
          Hero Member
          wrote on last edited by AWI
          #4

          @Yveaux Pigheaded as I am... (AVR made some more mistakes in their documentation) .. I got 12 different atmega328p processors from different sources on the test bench (custom, TQFP & DIL, pro-mini 3.3 /5V) and was not able to produce proof of : 0_1490897465883_upload-4a1e7b13-42e2-49bb-b132-1927b9dd669d.
          I got consistent behaviour with using CHANGE, RISING, FALLING and LOW using the SLEEP_FOREVER mode of the low power library.

          "RISING"
          0_1490898088157_upload-3fd4332e-59a0-466c-b5c5-6e33ec8ff117
          and similar for "CHANGE"
          0_1490898242474_upload-f8afe558-13bb-4fd4-a2d8-b6e512c70888
          So "the question": out of spec :neutral_face: - or - invalid spec :worried:

          YveauxY 1 Reply Last reply
          4
          • AWIA AWI

            @Yveaux Pigheaded as I am... (AVR made some more mistakes in their documentation) .. I got 12 different atmega328p processors from different sources on the test bench (custom, TQFP & DIL, pro-mini 3.3 /5V) and was not able to produce proof of : 0_1490897465883_upload-4a1e7b13-42e2-49bb-b132-1927b9dd669d.
            I got consistent behaviour with using CHANGE, RISING, FALLING and LOW using the SLEEP_FOREVER mode of the low power library.

            "RISING"
            0_1490898088157_upload-3fd4332e-59a0-466c-b5c5-6e33ec8ff117
            and similar for "CHANGE"
            0_1490898242474_upload-f8afe558-13bb-4fd4-a2d8-b6e512c70888
            So "the question": out of spec :neutral_face: - or - invalid spec :worried:

            YveauxY Offline
            YveauxY Offline
            Yveaux
            Mod
            wrote on last edited by
            #5

            @AWI Nice investigation!
            Just curious: Are the results the same with the MySensors library?

            http://yveaux.blogspot.nl

            AWIA 1 Reply Last reply
            0
            • YveauxY Yveaux

              @AWI Nice investigation!
              Just curious: Are the results the same with the MySensors library?

              AWIA Offline
              AWIA Offline
              AWI
              Hero Member
              wrote on last edited by
              #6

              @Yveaux Not really.. since 2.1.1 I'm losing it... :blush: Still in the process of finding differences with the previous version...

              YveauxY 2 Replies Last reply
              0
              • AWIA AWI

                @Yveaux Not really.. since 2.1.1 I'm losing it... :blush: Still in the process of finding differences with the previous version...

                YveauxY Offline
                YveauxY Offline
                Yveaux
                Mod
                wrote on last edited by
                #7

                @AWI Could be that Atmel copied the datasheet from the ATMega8. See this topic where the LOW-only wake from sleep seems to be acknowledged for ATMega8, and your findings match theirs for ATMega328.

                http://yveaux.blogspot.nl

                1 Reply Last reply
                0
                • AWIA AWI

                  @Yveaux Not really.. since 2.1.1 I'm losing it... :blush: Still in the process of finding differences with the previous version...

                  YveauxY Offline
                  YveauxY Offline
                  Yveaux
                  Mod
                  wrote on last edited by
                  #8

                  @AWI There goes my pleed:

                  0_1490901898593_upload-682ef4f5-a21b-4fbe-822c-339d0e3db1a7

                  Source: http://gammon.com.au/interrupts

                  Back to the drawing board then...

                  http://yveaux.blogspot.nl

                  AWIA 1 Reply Last reply
                  4
                  • YveauxY Yveaux

                    @AWI There goes my pleed:

                    0_1490901898593_upload-682ef4f5-a21b-4fbe-822c-339d0e3db1a7

                    Source: http://gammon.com.au/interrupts

                    Back to the drawing board then...

                    AWIA Offline
                    AWIA Offline
                    AWI
                    Hero Member
                    wrote on last edited by
                    #9

                    @Yveaux Good find! and good news ;-)

                    YveauxY 1 Reply Last reply
                    0
                    • AWIA AWI

                      @Yveaux Good find! and good news ;-)

                      YveauxY Offline
                      YveauxY Offline
                      Yveaux
                      Mod
                      wrote on last edited by
                      #10

                      @AWI Took me a day of debugging, datasheet reading and searching the internet, but It looks like I fixed the sleep with external interrupts issues in the MySensors library!
                      Main issue was this one: https://github.com/mysensors/MySensors/issues/811
                      If an interrupt was pending (if it had been registered before actually sleeping the AVR) it would immediately wake the AVR again, just 2ms after sleeping it. It didn't matter if this interrupt was registered just before calling sleep or 1 hour ago...
                      Furthermore https://github.com/mysensors/MySensors/issues/812 and https://github.com/mysensors/MySensors/issues/809 were also fixed, but have minor impact.

                      I tested it on a ProMini with ATMega328P @ 8MHz, powered directly by 2xAA battery -- a 'standard' sleeping sensor processor setup.
                      I verified sleeping modes LOW, CHANGE, RISING & FALLING to work Ok. This confirms your findings and Nick Gammon's.

                      Sidenote: Mode HIGH is mapped onto CHANGE in Arduino ATMega328P port (duh!). The library can therefore not distinguish between the two and will use CHANGE in both situations.

                      The bugs are solved in development branch, so please give it a try!

                      http://yveaux.blogspot.nl

                      ileneken3I AWIA 2 Replies Last reply
                      4
                      • YveauxY Yveaux

                        @AWI Took me a day of debugging, datasheet reading and searching the internet, but It looks like I fixed the sleep with external interrupts issues in the MySensors library!
                        Main issue was this one: https://github.com/mysensors/MySensors/issues/811
                        If an interrupt was pending (if it had been registered before actually sleeping the AVR) it would immediately wake the AVR again, just 2ms after sleeping it. It didn't matter if this interrupt was registered just before calling sleep or 1 hour ago...
                        Furthermore https://github.com/mysensors/MySensors/issues/812 and https://github.com/mysensors/MySensors/issues/809 were also fixed, but have minor impact.

                        I tested it on a ProMini with ATMega328P @ 8MHz, powered directly by 2xAA battery -- a 'standard' sleeping sensor processor setup.
                        I verified sleeping modes LOW, CHANGE, RISING & FALLING to work Ok. This confirms your findings and Nick Gammon's.

                        Sidenote: Mode HIGH is mapped onto CHANGE in Arduino ATMega328P port (duh!). The library can therefore not distinguish between the two and will use CHANGE in both situations.

                        The bugs are solved in development branch, so please give it a try!

                        ileneken3I Offline
                        ileneken3I Offline
                        ileneken3
                        wrote on last edited by
                        #11

                        @Yveaux

                        The new version didn't seem to help with my scenario - a vibration sensor where I only want to send one message per "event". (A vibration detected within a few seconds, or more). Using the default handling:

                        switch ( sleep(digitalPinToInterrupt(DIGITAL_INPUT_SENSOR), CHANGE, SLEEP_TIME) )
                          {
                            case MY_WAKE_UP_BY_TIMER:
                              sendHeartbeat();
                              break;
                            case MY_SLEEP_NOT_POSSIBLE:
                              Serial.println("Unable to sleep ;-(");
                              break;
                            default:
                              Serial.println("Sending a message with value = 1 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!");
                              send(msg.set(1));
                        
                        }
                        

                        There are always 2 messages sent. This happens even if I add a sleep either before or after the send().

                        My workaround has been to add this after the send():

                          while (sleep(digitalPinToInterrupt(DIGITAL_INPUT_SENSOR), CHANGE, 2000) != MY_WAKE_UP_BY_TIMER ) {
                            Serial.println("Clearing interrupts");
                          }
                        

                        I'm not sure the workaround is a good idea - because it may cause other problems. Any other ideas? Or is this correct?

                        Thanks!

                        AWIA mfalkviddM 2 Replies Last reply
                        0
                        • YveauxY Yveaux

                          @AWI Took me a day of debugging, datasheet reading and searching the internet, but It looks like I fixed the sleep with external interrupts issues in the MySensors library!
                          Main issue was this one: https://github.com/mysensors/MySensors/issues/811
                          If an interrupt was pending (if it had been registered before actually sleeping the AVR) it would immediately wake the AVR again, just 2ms after sleeping it. It didn't matter if this interrupt was registered just before calling sleep or 1 hour ago...
                          Furthermore https://github.com/mysensors/MySensors/issues/812 and https://github.com/mysensors/MySensors/issues/809 were also fixed, but have minor impact.

                          I tested it on a ProMini with ATMega328P @ 8MHz, powered directly by 2xAA battery -- a 'standard' sleeping sensor processor setup.
                          I verified sleeping modes LOW, CHANGE, RISING & FALLING to work Ok. This confirms your findings and Nick Gammon's.

                          Sidenote: Mode HIGH is mapped onto CHANGE in Arduino ATMega328P port (duh!). The library can therefore not distinguish between the two and will use CHANGE in both situations.

                          The bugs are solved in development branch, so please give it a try!

                          AWIA Offline
                          AWIA Offline
                          AWI
                          Hero Member
                          wrote on last edited by
                          #12

                          @Yveaux great work :+1:

                          1 Reply Last reply
                          0
                          • ileneken3I ileneken3

                            @Yveaux

                            The new version didn't seem to help with my scenario - a vibration sensor where I only want to send one message per "event". (A vibration detected within a few seconds, or more). Using the default handling:

                            switch ( sleep(digitalPinToInterrupt(DIGITAL_INPUT_SENSOR), CHANGE, SLEEP_TIME) )
                              {
                                case MY_WAKE_UP_BY_TIMER:
                                  sendHeartbeat();
                                  break;
                                case MY_SLEEP_NOT_POSSIBLE:
                                  Serial.println("Unable to sleep ;-(");
                                  break;
                                default:
                                  Serial.println("Sending a message with value = 1 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!");
                                  send(msg.set(1));
                            
                            }
                            

                            There are always 2 messages sent. This happens even if I add a sleep either before or after the send().

                            My workaround has been to add this after the send():

                              while (sleep(digitalPinToInterrupt(DIGITAL_INPUT_SENSOR), CHANGE, 2000) != MY_WAKE_UP_BY_TIMER ) {
                                Serial.println("Clearing interrupts");
                              }
                            

                            I'm not sure the workaround is a good idea - because it may cause other problems. Any other ideas? Or is this correct?

                            Thanks!

                            AWIA Offline
                            AWIA Offline
                            AWI
                            Hero Member
                            wrote on last edited by AWI
                            #13

                            @ileneken3 Could it be that your sensor is better handled with a RISING or FALLING interrupt? CHANGE fires on both edges. Else post your whole sketch and debug log.

                            1 Reply Last reply
                            0
                            • ileneken3I ileneken3

                              @Yveaux

                              The new version didn't seem to help with my scenario - a vibration sensor where I only want to send one message per "event". (A vibration detected within a few seconds, or more). Using the default handling:

                              switch ( sleep(digitalPinToInterrupt(DIGITAL_INPUT_SENSOR), CHANGE, SLEEP_TIME) )
                                {
                                  case MY_WAKE_UP_BY_TIMER:
                                    sendHeartbeat();
                                    break;
                                  case MY_SLEEP_NOT_POSSIBLE:
                                    Serial.println("Unable to sleep ;-(");
                                    break;
                                  default:
                                    Serial.println("Sending a message with value = 1 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!");
                                    send(msg.set(1));
                              
                              }
                              

                              There are always 2 messages sent. This happens even if I add a sleep either before or after the send().

                              My workaround has been to add this after the send():

                                while (sleep(digitalPinToInterrupt(DIGITAL_INPUT_SENSOR), CHANGE, 2000) != MY_WAKE_UP_BY_TIMER ) {
                                  Serial.println("Clearing interrupts");
                                }
                              

                              I'm not sure the workaround is a good idea - because it may cause other problems. Any other ideas? Or is this correct?

                              Thanks!

                              mfalkviddM Offline
                              mfalkviddM Offline
                              mfalkvidd
                              Mod
                              wrote on last edited by mfalkvidd
                              #14

                              @ileneken3 for how long did you sleep when trying to use sleep to debounce the interrupt after sending? If you used a number less than 15, could you try with 15 or above? The sleep function does not work very well with small sleep times. or replace that sleep with wait.

                              ileneken3I 1 Reply Last reply
                              0
                              • ileneken3I Offline
                                ileneken3I Offline
                                ileneken3
                                wrote on last edited by
                                #15

                                @AWI

                                Tried all suggestions. Here is the whole code:

                                /**
                                   The MySensors dev version
                                   **/
                                #define MY_NODE_ID 89 
                                #define MY_PARENT_NODE_ID 88 // Main floor repeater
                                #define CHILD_ID 88  // Id of the sensor child
                                
                                #define MY_RF24_PA_LEVEL RF24_PA_HIGH // Attempt to get radio to work
                                #define MY_BAUD_RATE 9600
                                #define MY_RADIO_NRF24
                                #define MY_DEBUG    // Enables debug messages
                                #include <MySensors.h>
                                unsigned long SLEEP_TIME = 360000; // 6 minutes between heartbeats
                                
                                #define DIGITAL_INPUT_SENSOR 3 // The digital input attached to vibration sensor.
                                
                                // Initialize  message
                                MyMessage msg(CHILD_ID, V_TRIPPED);
                                
                                void setup()
                                {
                                  Serial.begin(9600); // 9600 needed for 1MHZ
                                
                                  pinMode(DIGITAL_INPUT_SENSOR, INPUT);      // sets the motion sensor digital pin as input
                                  pinMode(DIGITAL_INPUT_SENSOR, INPUT_PULLUP);
                                
                                  wait(100);
                                  Serial.println("Sending a message with value = 1 to get things started");
                                  send(msg.set(1));
                                }
                                
                                void presentation()  {
                                  // Send the sketch version information to the gateway and Controller
                                  sendSketchInfo("Mailbox Sensor 1Mhz", "1.5");
                                
                                  // Register all sensors to gw (they will be created as child devices)
                                  present(CHILD_ID, S_MOTION);
                                }
                                
                                void loop()
                                {
                                  // Sleep until woken by sensor, or timeout
                                  // Tried with FALLING and RISING also.
                                  switch ( sleep(digitalPinToInterrupt(DIGITAL_INPUT_SENSOR), CHANGE, SLEEP_TIME) )
                                  {
                                    case MY_WAKE_UP_BY_TIMER:
                                      Serial.println("Woke up after SLEEP_TIME seconds so sending heartbeat");
                                      sendHeartbeat();
                                      break;
                                    case MY_SLEEP_NOT_POSSIBLE:
                                      Serial.println("Unable to sleep ;-(");
                                      break;
                                    default:
                                      Serial.println("Sending a message with value = 1 !!!!!!");
                                      // Tried with sleep(15), sleep(1000), sleep(10000). delay(1000) and wait(4000)
                                      wait(4000);
                                #ifdef SHOULD_NOT_BE_NEEDED
                                      while (sleep(digitalPinToInterrupt(DIGITAL_INPUT_SENSOR), CHANGE, 2000) != MY_WAKE_UP_BY_TIMER ) {
                                        Serial.println("Clearing interrupts");
                                      }
                                #endif
                                      break;
                                  }
                                }
                                
                                

                                Here is the debug log:
                                0 MCO:BGN:INIT NODE,CP=RNNNA---,VER=2.2.0-beta
                                49 TSM:INIT
                                65 TSF:WUR:MS=0
                                81 TSM:INIT:TSP OK
                                114 TSM:INIT:STATID=89
                                131 TSF:SID:OK,ID=89
                                163 TSM:FPAR
                                212 TSF:MSG:SEND,89-89-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
                                737 TSF:MSG:READ,0-0-89,s=255,c=3,t=8,pt=1,l=1,sg=0:0
                                786 TSF:MSG:FPAR OK,ID=0,D=1
                                1179 TSF:MSG:READ,88-88-89,s=255,c=3,t=8,pt=1,l=1,sg=0:1
                                1245 TSF:MSG:FPAR PREF
                                1261 TSF:MSG:FPAR OK,ID=88,D=2
                                1294 TSM:FPAR:OK
                                1327 TSM:ID
                                1343 TSM:ID:OK
                                1359 TSM:UPL
                                1376 TSF:MSG:SEND,89-89-88-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
                                3473 TSM:UPL
                                3489 TSF:MSG:SEND,89-89-88-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
                                3571 TSF:MSG:READ,0-88-89,s=255,c=3,t=25,pt=1,l=1,sg=0:2
                                3637 TSF:MSG:PONG RECV,HP=2
                                3670 TSM:UPL:OK
                                3686 TSM:READY:ID=89,PAR=88,DIS=2
                                3735 TSF:MSG:SEND,89-89-88-0,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
                                3817 TSF:MSG:READ,0-88-89,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
                                3899 TSF:MSG:SEND,89-89-88-0,s=255,c=0,t=17,pt=0,l=10,sg=0,ft=0,st=OK:2.2.0-beta
                                3997 TSF:MSG:SEND,89-89-88-0,s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=OK:88
                                6111 TSF:MSG:SEND,89-89-88-0,s=255,c=3,t=11,pt=0,l=19,sg=0,ft=0,st=OK:Mailbox Sensor 1Mhz
                                6225 TSF:MSG:SEND,89-89-88-0,s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=OK:1.5
                                6324 TSF:MSG:SEND,89-89-88-0,s=88,c=0,t=1,pt=0,l=0,sg=0,ft=0,st=OK:
                                6406 MCO:REG:REQ
                                6422 TSF:MSG:SEND,89-89-88-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2
                                6504 TSF:MSG:READ,0-88-89,s=255,c=3,t=27,pt=1,l=1,sg=0:1
                                6586 MCO:PIM:NODE REG=1
                                6602 MCO:BGN:STP
                                Sending a message with value = 1 to get things started
                                6766 TSF:MSG:SEND,89-89-88-0,s=88,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:1
                                6881 MCO:BGN:INIT OK,TSP=1
                                6897 MCO:SLP:MS=360000,SMS=0,I1=1,M1=1,I2=255,M2=255
                                6963 TSF:TDI:TSL
                                6995 MCO:SLP:WUP=1
                                7012 TSF:TRI:TSB
                                Sending a message with value = 1 !!!!!!
                                11059 MCO:SLP:MS=360000,SMS=0,I1=1,M1=1,I2=255,M2=255
                                11108 TSF:TDI:TSL
                                11141 MCO:SLP:WUP=1
                                11157 TSF:TRI:TSB
                                Sending a message with value = 1 !!!!!!
                                15204 MCO:SLP:MS=360000,SMS=0,I1=1,M1=1,I2=255,M2=255
                                15253 TSF:TDI:TSL

                                I always get at least two messages, sometimes more.

                                Here is the sensor:

                                https://www.aliexpress.com/item/normally-closed-type-vibration-sensor-module-Alarm-sensor-module-Vibration-switch-SW-420/32552946060.html?ws_ab_test=searchweb0_0,searchweb201602_1_10065_10130_10068_10136_10137_10138_10060_10062_10141_10056_10055_10054_10059_10099_129_10103_10102_10096_10148_10052_10053_10050_10107_10142_10051_10143_10084_10083_10119_10080_10082_10081_10110_10111_10112_10113_10114_10037_10032_10078_10079_10077_10073_10070_10123_10120_10124-10120,searchweb201603_4,afswitch_1_afChannel,ppcSwitch_5,single_sort_0_default&btsid=ad1187d9-117e-4c3a-b352-613dbf796c4f&algo_expid=761b80f8-c1bc-4235-8891-522e2e83f548-10&algo_pvid=761b80f8-c1bc-4235-8891-522e2e83f548

                                1 Reply Last reply
                                0
                                • mfalkviddM mfalkvidd

                                  @ileneken3 for how long did you sleep when trying to use sleep to debounce the interrupt after sending? If you used a number less than 15, could you try with 15 or above? The sleep function does not work very well with small sleep times. or replace that sleep with wait.

                                  ileneken3I Offline
                                  ileneken3I Offline
                                  ileneken3
                                  wrote on last edited by
                                  #16

                                  @mfalkvidd

                                  I did try many combinations of sleep,wait,delay. I always get at least 2 messages sent.
                                  Below, I posted the code and the debug log.

                                  Thanks again.

                                  1 Reply Last reply
                                  0
                                  • gohanG Offline
                                    gohanG Offline
                                    gohan
                                    Mod
                                    wrote on last edited by
                                    #17

                                    Remove the MY_PARENT_NODE_ID and set pa_level to min

                                    ileneken3I 1 Reply Last reply
                                    0
                                    • gohanG gohan

                                      Remove the MY_PARENT_NODE_ID and set pa_level to min

                                      ileneken3I Offline
                                      ileneken3I Offline
                                      ileneken3
                                      wrote on last edited by
                                      #18

                                      @gohan
                                      I tried. Unfortunately, it didn't seem to matter with either or both those changes :(

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


                                      18

                                      Online

                                      11.7k

                                      Users

                                      11.2k

                                      Topics

                                      113.1k

                                      Posts


                                      Copyright 2025 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