Sorry, didn't see notice that you replied. I kind of decided the same thing myself as I really don't have the patience to analyze a library to see if I can mess with it and have it work with sleep modes. So I went back to "RH_RF95.h" and "LowPower.h" for transmitting and sleeping. Idea is to send packets like NNNTTTTCCCCCC where the first three are letters indicating the node that is sending, the node that should receive, and the current node (for the relays). The TTTT is just a transmission count so I can avoid 'ringing' by the relays if more than one can hear the transmission from either end. The CCCCCC is a six digit code that the user would enter at the kiosk using just three buttons (that will give over 700 unique numbers so should be sufficient).
The idea is the kiosk node will permanently sleep until a user wakes it with a button interrupt, they then enter the code. Kiosk sends to relay. Relay makes sure transmission number is new and repeats. Second relay does same, but if it gets the original msg as well as the repeated msg, it will ignore the second message because it has the same transmission number. Relays will stay active for some set period of time to allow the server node to respond with a yea or nay, and possibly some period of time past that to allow a human to indicate they have received the message and are on their way.
Initially the kiosk unit would broadcast every 20ms until it got a reply or timed out because ...
I was thinking of sleeping the relays for something like 10 seconds, wake and listen for 100ms, and back to sleep if no message. By my calcs (using others actual readings), with the radio and board asleep it will only draw about 300uA for 10s and then about 40ma listening for 100ms, so should average out (excluding actual transmissions which should be scarce) to about 0.639mA. A 2500mA battery should last close to 150 days. I figure maybe two batteries and change only every six months. The 100ms listen should easily capture the kiosk broadcast, and the kiosk should not have to wait more than 10 seconds for a reply. With waiting that long, and also having the second relay just begin its sleep so would add another 10 second delay, the total kiosk delay for a response should be under 21 seconds.
Thinking about button debounce right now, but think that may not be an issue with a loop something like this:
codeset = 7 ; // The button press values will be inserted into positions 7 through 12 of data[]
while (codeset < 13){
int val = 0 ; // init val
if(digitalRead(ONE)){ // read the three pins and set val for first one with a changed state
val = 1 ;
} else if (digitalRead(TWO)) {
val = 2 ;
} else if (digitalRead(THREE)) {
val = 3 ;
} else if (digitalRead(WAKE_UP)) { // a reset for the user if they know they screwed up entering the code
codeset = 7 ;
val = 0 ;
delay(100) ;
}
if(val){ // if a button press was read
data[codeset] = val ; // set the corresponding digit into the message location
codeset++ ; // inc message location
delay(100) ; // 100 ms for debounce ................ ????????????
for (byte i=0; i<20; i++) { // indicate to user ready for next press
digitalWrite(LED,HIGH);
delay(300);
digitalWrite(LED,LOW);
delay(300);
}
}
}