@Yveaux
many thanks for the response.
So if I understand correctly, you are saying (in my code above) that I should call
sleep(digitalPinToInterrupt(RainINT), FALLING, MYsleepTime);
that is passing the interrupt handler RATHER than the PIN?
BUT still call
pinMode(RainPin, INPUT_PULLUP);
attachInterrupt(digitalPinToInterrupt(RainPin), RainINT, FALLING);
in the setup?
From my reading of the code you reference above, any existing interrupt handler is disabled prior to the final sleeping, and re-attachment of the interrupt. However I don't see where it might reference the interrupt handler.
I see that a value is returned after waking, which is either the pin, or "0" dependant on wake cause, and this is utilised in the example you quote above.
Question, Is an existing interrupt handler re-instated anywhere after waking? or is it up to me to re-attech the IRQ handler? I ask, as if not then any "event" occurring whilst not sleeping will be missed. which in my case is quite likely during heavy rain.
Sorry if I am being a little thick. Might it be better for me to use just a short timed sleep (say 1 sec), loop for n sec to provide my ultimate sleep time, subject to breaking the loop if a interrupt occurs, by setting a flag in the IRQ handler.
I realise this is what is sort of being done in the example above, using Mysensors returned value from the sleep + interrupt function, but it won't (I think) address the case of an interrupt occuring whilst actioning the several seconds potentially utilised during the main loop, especially if there are re-transmit attempts.
Once again many thanks for the help.
regards Nigel
in hal/transport/RFM69/driver/new/RFM69_new.h you must also replace
#define RFM69_MAX_PACKET_LEN (0x40u) with
#define RFM69_MAX_PACKET_LEN (0x40ul)
if you are using RFM69 radio
@skywatch Just to add to your points on 254 max children, definitions, presentation, etc., which may help @mrmuszynski at some stage.
I've an array in a sketch with 14 DS18B20 addresses, all paged in turn using the one wire protocol on a single pin, so it is entirely possible to hit the 254 children limit before looking at I2C devices.
The beauty of the DS18B20 array is individual chips are "defined" sequentially, hence making presentation and fetching values available to a FOR loop, which makes for a highly compact sketch.
Update:
The issue seems to be with the Mega Mini board.
I managed to remove the Adafruit RFM69HW daughter board from the verroboard, and wired this to a Nano, and a Teensy 3.2. Both worked with the same PSU.
The USB converter however is still giving garbage , no matter which of the three sources above.
So I am in the belated process of porting code to the teensy as the target.
Many thanks for the help to you all.
Now, if I can only sort out my sensebender gateway problem....
