NodeManager sensors with multiple interrupt pins

  • Re: 💬 NodeManager
    I would like to use more than one sensor from within the NodeManager v1.8 template sketch where each of the sensors has its own interrupt pin.

    In my particular case I would like to support in my node sketch both a tipping bucket rain sensor and a wind speed sensor. Both use a reed switch with a pullup resistor to VCC and the switches short the sense lead to GND when activated.

    Furthermore I am using a Moteino with RFM69HW radio. Therefore the INT0 on pin D2 is already in use and I am left only with the INT1 on pin D3. As I have read already on this forum, in this case I could apply the wired or configuration from such that when the interrupt pin gets triggered I can read from another digital pin which sensor was the source of the interrupt.

    I have read a little bit the source code from the NodeManager and the MySensors library and if I have it understood correctly when I derive my code from SensorPulseMeter for multiple sensor classes only the last instance of a class placed in the main sketch will "win" the onInterrupt() callback. It seems there is a one to one relation between interrupt pin and SensorPulseMeter subclass instance.

    I imagine that to support the wired or configuration one could code "by hand" a sequence of attachInterrupt() with a if-else condition from within the main sketch file and redirect the signal source to a handler function for each sensor. But would it not be nicer to have some elegant way to code a new subclass of SensorPulseMeter that can accept the one available interrupt pin and keep a list of sense pins and/or interrupt handlers for each derived sensor instance?

    Are there any suggestions how I could approach this?

    Cheers and happy new year 2020 ^^

  • @j54n1n Just skimmed this so pardon me if I misunderstood through the hangover....
    If I recall correctly there is a method of using multiple triggers to a common Interrupt pin someone tested here presumably involving diodes and resistors but crucially linked to ADC input. On wakening from interrupt the first task was identify the culprit... If I remember rightly @NeverDie extended the principle using a resistor array...
    Hope this helps while I'm researching the wonders of aspirin...

  • Hero Member

    @zboblamont You're probably thinking of this thread: I've scaled it to a dozen buttons on one line, and it still works reliably.

  • @neverdie Good man, and wonderfully timed... 😉
    I've only just realised it's potential solution for an application here...
    Have volt-free NOs on two pump contactors, one held closed other than in power failure, the other only closed when the borehole pump is called...

  • Hello, These are valid and nice hardware solutions for multiple interrupts. Since I am building my node as a replacement for an old weather station I have allocated already all the analog pins of the Moteino for the other sensors. So for that reason I have still some free digital pins and I will go for the wired or solution with the diodes.

    I was more interested in a solution on the software side. For example if the team of the NodeManager library had thought of supporting more than one pulse type sensor per interrupt pin. In my case it would be the rain sensor and the wind speed sensor.

    I hope it is now more clear what I meant.

  • Hero Member

    @j54n1n So, you're wanting to tie all your pulse sources to one interrupt pin and use only software to somehow differentiate among them? If the pulse durations were different you might have a chance if the pulses were guaranteed not to overlap, but what if the pulses sometimes do overlap? How would you distinguish them?

  • Hello @NeverDie,
    Yes that is it what I want to try. Both the rain sensor and the wind sensor are reed switches and it is clear to me that I could miss a pulse since it could be masked by one of the sensors. I am trying to fiddle arround in the code of the NodeManager template without changing to much of its interrupt (INT0 & INT1) handling. And since on my Moteino board INT0 is already occupied by the RFM69 radio I have to work arround pin D3 (INT1).

    Or is it possible also to use pin change interrupts with the NodeManager sketch on batteries? A.k.a.: Can I use PCINT2_vect for port D pins (for ex.: PD4 on pin D4) that wakes up my sleeping NodeManager sketch?


  • Hero Member

    That sounds more promising than overloading a single pin.

  • So can somebody confirm that pin change interrupts can wake up a sleeping node loaded with a NodeManager template sketch?

    I have got the impression by reading here in the forum that the ATmega328p microcontroller has problems waking up from pin change interrupts. Maybe I am wrong?

  • @j54n1n If not, would a second low power non-radio board handling the two Ints (and any other expansion) be a viable option ?

  • Hero Member

    I can't think of any reason it wouldn't work. It sounds as though he has enough spare digital pins to differentiate the pulse signals. That's different from where he originally said it all needed to be processed using just a single pin without any extra hardware. The tricky part would be when a different pulse arrives on the same port just immediately prior to his clearing the interrupt. I think he could cover that case in software though by simply re-checking the digital pins after clearing the interrupt and before going to sleep.

    Of course, using pin change he'll get twice as many interrupts as compared to just using a falling/rising edge interrupt, but that's easily handled in software as well. It's not as energy efficient, so that becomes part of the trade-off. If he were willing to use diodes, then he could OR all his pulses together onto a standard interrupt pin with a pulldown resistor on it but differentiate them using the spare digital pins that he now says are available. Then you could look for interrupts on a rising edge, and you wouldn't get twice the interrupts. Given the choice, I think I would do it this way, as it would make things easy. Diodes are cheap. It's personal preference as to which approach you take, but either way should work.

  • @j54n1n said in NodeManager sensors with multiple interrupt pins:

    So can somebody confirm that pin change interrupts can wake up a sleeping node loaded with a NodeManager template sketch?

    I have got the impression by reading here in the forum that the ATmega328p microcontroller has problems waking up from pin change interrupts. Maybe I am wrong?

    You are wrong, i have one sitting on my bench right now sleeping and waking up on A5 pin change.
    it's bare 328p test bead drawing mere 1uA in sleep...
    Use sleep(0);
    All the code you need to set things up:(tested on nano and mini boards)

    void pciSetup(byte pin)// enables pin change for given pin
    	*digitalPinToPCMSK(pin) |= bit (digitalPinToPCMSKbit(pin));  // enable pin
    	PCIFR  |= bit (digitalPinToPCICRbit(pin)); // clear any outstanding interrupt
    	PCICR  |= bit (digitalPinToPCICRbit(pin)); // enable interrupt for the group
    void pciClear(byte pin)// disables pin change for given pin
    	*digitalPinToPCMSK(pin) &= ~(bit (digitalPinToPCMSKbit(pin)));  // disable pin
    	PCIFR  |= bit (digitalPinToPCICRbit(pin)); // clear any outstanding interrupt
    	PCICR  &= ~(bit (digitalPinToPCICRbit(pin))); // disable interrupt for the group
    ISR (PCINT0_vect)//pins d8-d13
    ISR (PCINT1_vect)// pins a0-a7
    ISR (PCINT2_vect)//pins d0-d7

    If you want to get several readings and then send them to gateway(power meter pulse counting) it's better to write your own sleep function. Built in sleep(); wakes radio on every wake up.
    :work in progress:

    void PowerDown(void)
      ADCSRA &= ~(1<<ADEN);//disable ADC - 120uA
      sleep_bod_disable();//disable bod  - 15uA
     ADCSRA |= (1<<ADEN);//enable ADC

    then call transportDisable(); before powering down
    and transportReInitialise(); before sending your data.

  • Ah ok, thanks @Sasquatch

  • Contest Winner

    @j54n1n at this time NodeManager can only handle interrupts through the designated pins and only one type of interrupt per pin. But feel free to submit a feature request on and, if you have, any piece of code which may help in the implementation. Thanks

Log in to reply

Suggested Topics

  • 11
  • 2
  • 2
  • 16
  • 1
  • 4
  • 10
  • 2