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. OpenHardware.io
  3. 💬 MySensors NRF5 Platform

💬 MySensors NRF5 Platform

Scheduled Pinned Locked Moved OpenHardware.io
contest2017nrf52mysensorsnrf5nrf51
210 Posts 20 Posters 42.9k Views 18 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.
  • NeverDieN Offline
    NeverDieN Offline
    NeverDie
    Hero Member
    wrote on last edited by NeverDie
    #85

    The last I heard, from @d00616 , we had to supply code such as:

        // Enable interrupt
      NVIC_SetPriority(RTC0_IRQn, 15);
      NVIC_ClearPendingIRQ(RTC0_IRQn);
      NVIC_EnableIRQ(RTC0_IRQn);
    
    

    and

    // This must be in one line
    extern "C" { void RTC0_IRQHandler(void) {rtcInterruptCounter++; NRF5_RESET_EVENT(NRF_RTC0->EVENTS_OVRFLW); NRF_RTC0->EVENTS_OVRFLW=0; }}
    

    to get interrupts to work. Even with that approach, though, I haven't gotten it to support any interrupts in addition to a timed sleeping, though I have gotten it to support one interrupt that's separate from a timed sleeping (basically, sleeps indefinitely until the interrupt happens).

    1 Reply Last reply
    0
    • NeverDieN Offline
      NeverDieN Offline
      NeverDie
      Hero Member
      wrote on last edited by NeverDie
      #86

      OK, I just now tried:

        sleep(3,CHANGE,3000);
      

      and, as I suspected, it does nothing but sleep for 3 seconds. It's not responsive to any changes on pin P03 on an nRF52.

      @scalz Are you getting a different result? It seems like there's a strong disconnect somewhere between what you're recommending and what I am experiencing.

      scalzS 1 Reply Last reply
      0
      • NeverDieN NeverDie

        OK, I just now tried:

          sleep(3,CHANGE,3000);
        

        and, as I suspected, it does nothing but sleep for 3 seconds. It's not responsive to any changes on pin P03 on an nRF52.

        @scalz Are you getting a different result? It seems like there's a strong disconnect somewhere between what you're recommending and what I am experiencing.

        scalzS Offline
        scalzS Offline
        scalz
        Hardware Contributor
        wrote on last edited by scalz
        #87

        @NeverDie said in 💬 MySensors NRF5 Platform:

        @scalz Are you getting a different result? It seems like there's a strong disconnect somewhere between what you're recommending and what I am experiencing.

        I didn't give any recommandation, you misread. I just said the regular way to use sleep feature in mysensors, for users, is with sleep(..). But I agree, I misread you too! when you were asking for the specific nrf52 case I guess :)

        That said, I got this working when I made my recessed node for door (accelerometer and hall effect sensor with sleeping). Maybe things have changed in the lib?? or not. I'm struggling between different version of the lib, and some are different from the dev branch.. I'll recheck this asap (not sure for this evening).

        1 Reply Last reply
        0
        • NeverDieN Offline
          NeverDieN Offline
          NeverDie
          Hero Member
          wrote on last edited by NeverDie
          #88

          I tried toying around with it a bit, and I got a useful result:

          #define MY_CORE_ONLY
          
          #include <nrf.h>
          #include <MySensors.h>
          
          
          const byte ledPin = LED_BUILTIN;
          const byte interruptPin = 3;
          volatile byte state = LOW;
          
          void blinkityBlink(uint8_t pulses, uint8_t repetitions) {
            for (int x=0;x<repetitions;x++) {
              for (int i=0;i<pulses;i++) {
                digitalWrite(LED_BUILTIN,HIGH);
                wait(20);
                digitalWrite(LED_BUILTIN,LOW);
                wait(100);
              }    
                wait(500);
            }
          }
          
          void setup() {
            hwPinMode(LED_BUILTIN,OUTPUT_D0H1);
            hwPinMode(interruptPin, INPUT);
            attachInterrupt(digitalPinToInterrupt(interruptPin), blink, RISING);
            blinkityBlink(2,1);  //signify power-on and start of main loop
          }
          
          volatile bool buttonPressed=false;
          void loop() {
            state = !state;
            digitalWrite(ledPin, state);
            sleep(digitalPinToInterrupt(interruptPin), RISING, 3000);
            wait(20);  //wait 20 milliseconds for button to debounce if it was pressed
            if (digitalRead(interruptPin)) { //if button is pressed
              blinkityBlink(2,1);
            }
            if (buttonPressed) {
              buttonPressed=false;
              blinkityBlink(20,1);
            }
          }
          
          void blink() {
            buttonPressed=true;
          }
          

          So, with this approach, pushing the button on pin 3 does wake up the nRF52 from sleep, whereupon the button press can still be detected and serviced, but it also demonstrates that the ISR per se isn't working.

          Anyhow, with this I'm able to get the PIR or leak sensor or magnet sensor or light sensor doing useful things in a timely manner, even if it isn't ideal. That puts me further ahead than I was before. :)

          rmtuckerR 1 Reply Last reply
          0
          • NeverDieN NeverDie

            I tried toying around with it a bit, and I got a useful result:

            #define MY_CORE_ONLY
            
            #include <nrf.h>
            #include <MySensors.h>
            
            
            const byte ledPin = LED_BUILTIN;
            const byte interruptPin = 3;
            volatile byte state = LOW;
            
            void blinkityBlink(uint8_t pulses, uint8_t repetitions) {
              for (int x=0;x<repetitions;x++) {
                for (int i=0;i<pulses;i++) {
                  digitalWrite(LED_BUILTIN,HIGH);
                  wait(20);
                  digitalWrite(LED_BUILTIN,LOW);
                  wait(100);
                }    
                  wait(500);
              }
            }
            
            void setup() {
              hwPinMode(LED_BUILTIN,OUTPUT_D0H1);
              hwPinMode(interruptPin, INPUT);
              attachInterrupt(digitalPinToInterrupt(interruptPin), blink, RISING);
              blinkityBlink(2,1);  //signify power-on and start of main loop
            }
            
            volatile bool buttonPressed=false;
            void loop() {
              state = !state;
              digitalWrite(ledPin, state);
              sleep(digitalPinToInterrupt(interruptPin), RISING, 3000);
              wait(20);  //wait 20 milliseconds for button to debounce if it was pressed
              if (digitalRead(interruptPin)) { //if button is pressed
                blinkityBlink(2,1);
              }
              if (buttonPressed) {
                buttonPressed=false;
                blinkityBlink(20,1);
              }
            }
            
            void blink() {
              buttonPressed=true;
            }
            

            So, with this approach, pushing the button on pin 3 does wake up the nRF52 from sleep, whereupon the button press can still be detected and serviced, but it also demonstrates that the ISR per se isn't working.

            Anyhow, with this I'm able to get the PIR or leak sensor or magnet sensor or light sensor doing useful things in a timely manner, even if it isn't ideal. That puts me further ahead than I was before. :)

            rmtuckerR Offline
            rmtuckerR Offline
            rmtucker
            wrote on last edited by
            #89

            @NeverDie
            This is a test program that wakes up from either that i was using some time ago.

            /**
               The MySensors Arduino library handles the wireless radio link and protocol
               between your home built sensors/actuators and HA controller of choice.
               The sensors forms a self healing radio network with optional repeaters. Each
               repeater and gateway builds a routing tables in EEPROM which keeps track of the
               network topology allowing messages to be routed to nodes.
            
               Created by Henrik Ekblad <henrik.ekblad@mysensors.org>
               Copyright (C) 2013-2015 Sensnology AB
               Full contributor list: https://github.com/mysensors/Arduino/graphs/contributors
            
               Documentation: http://www.mysensors.org
               Support Forum: http://forum.mysensors.org
            
               This program is free software; you can redistribute it and/or
               modify it under the terms of the GNU General Public License
               version 2 as published by the Free Software Foundation.
            
             *******************************
            
               REVISION HISTORY
               Version 1.0 - Henrik EKblad
            
               DESCRIPTION
               This sketch provides an example how to implement a distance sensor using HC-SR04
               Use this sensor to measure KWH and Watt of your house meeter
               You need to set the correct pulsefactor of your meeter (blinks per KWH).
               The sensor starts by fetching current KWH value from gateway.
               Reports both KWH and Watt back to gateway.
            
               Unfortunately millis() won't increment when the Arduino is in
               sleepmode. So we cannot make this sensor sleep if we also want
               to calculate/report watt-number.
               http://www.mysensors.org/build/pulse_power
            */
            
            // Enable debug prints
            #define MY_DEBUG
            
            // Enable and select radio type attached
            //#define MY_RADIO_NRF24
            #define MY_RADIO_NRF5_ESB
            //#define MY_RADIO_RFM69
            //#define MY_RADIO_RFM95
            
            #include <MySensors.h>
            #include <Wire.h> // must be included here so that Arduino library object file references work
            #include <RtcDS3231.h>
            RtcDS3231<TwoWire> Rtc(Wire);
            
            #define DIGITAL_INPUT_SENSOR 2  // The digital input you attached your light sensor.  (Only 2 and 3 generates interrupt!)
            #define PULSE_FACTOR 1000       // Nummber of blinks per KWH of your meeter
            //#define SLEEP_MODE false        // Watt-value can only be reported when sleep mode is false.
            #define MAX_WATT 10000          // Max watt value to report. This filetrs outliers.
            #define CHILD_ID 1              // Id of the sensor child
            
            unsigned long SEND_FREQUENCY = 20000; // Minimum time between send (in milliseconds). We don't wnat to spam the gateway.
            double ppwh = ((double)PULSE_FACTOR) / 1000; // Pulses per watt hour
            //bool pcReceived = false;
            volatile unsigned long pulseCount = 0;
            volatile unsigned long lastBlink = 0;
            volatile unsigned long watt = 0;
            volatile unsigned long kwh = 0;
            unsigned long oldWatt = 0;
            double oldKwh;
            unsigned long lastSend;
            MyMessage wattMsg(CHILD_ID, V_WATT);
            MyMessage kwhMsg(CHILD_ID, V_KWH);
            
            
            void setup()
            {
              Serial.begin(115200);
              Rtc.Begin();
              Rtc.Enable32kHzPin(false);
              Rtc.SetSquareWavePinClockFrequency(DS3231SquareWaveClock_1Hz);
              Rtc.SetSquareWavePin(DS3231SquareWavePin_ModeClock);
            
              // Use the internal pullup to be able to hook up this sketch directly to an energy meter with S0 output
              // If no pullup is used, the reported usage will be too high because of the floating pin
              hwPinMode(DIGITAL_INPUT_SENSOR, INPUT_PULLUP);
            
              attachInterrupt(digitalPinToInterrupt(DIGITAL_INPUT_SENSOR), onPulse, FALLING);
              //pcReceived = true;
              lastSend = millis();
            }
            
            void presentation()
            {
              // Send the sketch version information to the gateway and Controller
              sendSketchInfo("Energy Meter", "1.0");
            
              // Register this device as power sensor
              present(CHILD_ID, S_POWER);
            }
            
            void loop()
            {
              unsigned long now = millis();
              // Only send values at a maximum frequency or woken up from sleep
              bool sendTime = now - lastSend > SEND_FREQUENCY;
              if (sendTime) {
                // New watt value has been calculated
                if (watt != oldWatt) {
                  // Check that we dont get unresonable large watt value.
                  // could hapen when long wraps or false interrupt triggered
                  if (watt < ((unsigned long)MAX_WATT)) {
                    send(wattMsg.set(watt));  // Send watt value to gw
                  }
                  Serial.print("Watt:");
                  Serial.println(watt);
                  oldWatt = watt;
                }
            
                // Pulse count has changed
                //kwh = pulseCount;
                //double kwh = ((double)pulseCount / ((double)PULSE_FACTOR));
                send(kwhMsg.set(pulseCount));  // Send kwh value to gw
                Serial.print("Wh = ");
                Serial.println(pulseCount);
                pulseCount = 0;
                lastSend = now;
              }
              sleep(SEND_FREQUENCY);
            }
            
            void receive(const MyMessage &message)
            {
            }
            
            void onPulse()
            {
              unsigned long newBlink = micros();
              unsigned long interval = newBlink - lastBlink;
              if (interval < 50000L) { // Sometimes we get interrupt on RISING
                return;
              }
              watt = (3600000000.0 / interval) / ppwh;
              lastBlink = newBlink;
              pulseCount++;
            }
            
            1 Reply Last reply
            1
            • NeverDieN Offline
              NeverDieN Offline
              NeverDie
              Hero Member
              wrote on last edited by NeverDie
              #90

              Well, that's interesting. In the sketch I posted, I invoked sleep with:

                sleep(digitalPinToInterrupt(interruptPin), RISING, 3000);
              

              which caused the mcu to wake up immediately after I press the button, but it didn't process the ISR.

              Using an invocation like yours in the sketch you just posted above:

                sleep(3000);
              

              the ISR executes and then terminates when I press the button, but the MCU doesn't wake and continue with the loop as it did with the prior incantation. Instead, it has to wait for the timer cycle to finish.

              What I want is for it to wake up, do the ISR, and continue with the loop where it left off until it is explicitly put back to sleep again. How do I do that?

              1 Reply Last reply
              0
              • d00616D Offline
                d00616D Offline
                d00616
                Contest Winner
                wrote on last edited by
                #91

                @NeverDie I have checked the sleep routine in all three variants. It's working with my setup.

                There is no API stopping the sleep() by another ISR. Sleep only ends at one of the given conditions.

                When you use the MY_CORE_ONLY define, please add "hwInit();" into the setup() routine.

                NeverDieN 1 Reply Last reply
                0
                • d00616D d00616

                  @NeverDie I have checked the sleep routine in all three variants. It's working with my setup.

                  There is no API stopping the sleep() by another ISR. Sleep only ends at one of the given conditions.

                  When you use the MY_CORE_ONLY define, please add "hwInit();" into the setup() routine.

                  NeverDieN Offline
                  NeverDieN Offline
                  NeverDie
                  Hero Member
                  wrote on last edited by
                  #92

                  @d00616 said in 💬 MySensors NRF5 Platform:

                  @NeverDie I have checked the sleep routine in all three variants. It's working with my setup.

                  There is no API stopping the sleep() by another ISR. Sleep only ends at one of the given conditions.

                  When you use the MY_CORE_ONLY define, please add "hwInit();" into the setup() routine.

                  Would you please post the three demo code examples that you tested?

                  1 Reply Last reply
                  0
                  • NeverDieN Offline
                    NeverDieN Offline
                    NeverDie
                    Hero Member
                    wrote on last edited by
                    #93

                    @d00616 said in 💬 MySensors NRF5 Platform:

                    add "hwInit();" into the setup() routine.

                    OK, I just now did that, but I'm not getting any difference in the results.

                    1 Reply Last reply
                    0
                    • NeverDieN Offline
                      NeverDieN Offline
                      NeverDie
                      Hero Member
                      wrote on last edited by
                      #94

                      In any case, I'm sure the question will ultimately turn from "How do I wake up based on a pin change?" to "How do I wake up based on the LPCOMP output, which has that pin as its input?" The reason: as covered earlier in this thread, much lower current consumption while sleeping if doing it via LPCOMP rather than the more straightforward pin monitoring.

                      d00616D 1 Reply Last reply
                      0
                      • NeverDieN NeverDie

                        In any case, I'm sure the question will ultimately turn from "How do I wake up based on a pin change?" to "How do I wake up based on the LPCOMP output, which has that pin as its input?" The reason: as covered earlier in this thread, much lower current consumption while sleeping if doing it via LPCOMP rather than the more straightforward pin monitoring.

                        d00616D Offline
                        d00616D Offline
                        d00616
                        Contest Winner
                        wrote on last edited by
                        #95

                        @NeverDie said in 💬 MySensors NRF5 Platform:

                        In any case, I'm sure the question will ultimately turn from "How do I wake up based on a pin change?" to "How do I wake up based on the LPCOMP output, which has that pin as its input?" The reason: as covered earlier in this thread, much lower current consumption while sleeping if doing it via LPCOMP rather than the more straightforward pin monitoring.

                        It's a good question about, how to design the API to do this. I have no good idea.
                        Until an API, you can set MY_HW_RTC->CC[0] to (MY_HW_RTC->COUNTER+2). This ends sleep with some latency.

                        1 Reply Last reply
                        1
                        • NeverDieN Offline
                          NeverDieN Offline
                          NeverDie
                          Hero Member
                          wrote on last edited by NeverDie
                          #96
                          This post is deleted!
                          1 Reply Last reply
                          0
                          • NeverDieN Offline
                            NeverDieN Offline
                            NeverDie
                            Hero Member
                            wrote on last edited by NeverDie
                            #97
                            This post is deleted!
                            1 Reply Last reply
                            1
                            • NeverDieN Offline
                              NeverDieN Offline
                              NeverDie
                              Hero Member
                              wrote on last edited by
                              #98
                              This post is deleted!
                              1 Reply Last reply
                              0
                              • NeverDieN Offline
                                NeverDieN Offline
                                NeverDie
                                Hero Member
                                wrote on last edited by NeverDie
                                #99

                                Is it just me, or does the myBoardNrf5 cause I2c to fail during initialization? I have code which worked fine on mNrf5Board but which now hangs during initialization when using myBoardNrf5. :( Is it working for anyone else?

                                NeverDieN 1 Reply Last reply
                                0
                                • NeverDieN NeverDie

                                  Is it just me, or does the myBoardNrf5 cause I2c to fail during initialization? I have code which worked fine on mNrf5Board but which now hangs during initialization when using myBoardNrf5. :( Is it working for anyone else?

                                  NeverDieN Offline
                                  NeverDieN Offline
                                  NeverDie
                                  Hero Member
                                  wrote on last edited by NeverDie
                                  #100

                                  @NeverDie said in 💬 MySensors NRF5 Platform:

                                  Is it just me, or does the myBoardNrf5 cause I2c to fail during initialization? I have code which worked fine on mNrf5Board but which now hangs during initialization when using myBoardNrf5. :( Is it working for anyone else?

                                  I've re-installed everything and am still getting no joy using I2C currently. The non-I2C stuff seems to be working fine though.
                                  So, before I spin more cycles trying to figure it out, is i2c working for anyone else right now using the latest builds and myBoardNrf5? Or, is I2C currently broken?

                                  NeverDieN 1 Reply Last reply
                                  0
                                  • NeverDieN NeverDie

                                    @NeverDie said in 💬 MySensors NRF5 Platform:

                                    Is it just me, or does the myBoardNrf5 cause I2c to fail during initialization? I have code which worked fine on mNrf5Board but which now hangs during initialization when using myBoardNrf5. :( Is it working for anyone else?

                                    I've re-installed everything and am still getting no joy using I2C currently. The non-I2C stuff seems to be working fine though.
                                    So, before I spin more cycles trying to figure it out, is i2c working for anyone else right now using the latest builds and myBoardNrf5? Or, is I2C currently broken?

                                    NeverDieN Offline
                                    NeverDieN Offline
                                    NeverDie
                                    Hero Member
                                    wrote on last edited by NeverDie
                                    #101

                                    It appears that the place where it hangs is this line here in Wire_nRF52.cpp:

                                      while(!_p_twim->EVENTS_LASTTX && !_p_twim->EVENTS_ERROR);
                                    

                                    This is too bad, as I2C seemed to work fine prior to around a couple weeks ago. I think maybe (?) the latest update somehow broke it.

                                    Please advise.

                                    1 Reply Last reply
                                    0
                                    • NeverDieN Offline
                                      NeverDieN Offline
                                      NeverDie
                                      Hero Member
                                      wrote on last edited by NeverDie
                                      #102

                                      Well, since I'm dead in the water as things stand, I moved the code over to run on an nRF52 DK. Then, usingy Sandeep's code and none of the mysensors code, I was able to get the nRF52 DK to read an attached Si7021 temperature-humidity sensor. i.e. that worked without hanging.

                                      So, it would appear that there's something about the mysensors code that is causing the problems. @d00616 Can we please get it fixed?

                                      d00616D 1 Reply Last reply
                                      0
                                      • NeverDieN NeverDie

                                        Well, since I'm dead in the water as things stand, I moved the code over to run on an nRF52 DK. Then, usingy Sandeep's code and none of the mysensors code, I was able to get the nRF52 DK to read an attached Si7021 temperature-humidity sensor. i.e. that worked without hanging.

                                        So, it would appear that there's something about the mysensors code that is causing the problems. @d00616 Can we please get it fixed?

                                        d00616D Offline
                                        d00616D Offline
                                        d00616
                                        Contest Winner
                                        wrote on last edited by
                                        #103

                                        @NeverDie said in 💬 MySensors NRF5 Platform:

                                        So, it would appear that there's something about the mysensors code that is causing the problems. @d00616 Can we please get it fixed?

                                        I have no I2C Hardware for testing, but I take a look into the I2C and MySensors code soon.

                                        1 Reply Last reply
                                        0
                                        • NeverDieN Offline
                                          NeverDieN Offline
                                          NeverDie
                                          Hero Member
                                          wrote on last edited by NeverDie
                                          #104

                                          The sooner the better. I'm pretty much stuck until it gets fixed.

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


                                          11

                                          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