I made a remote controlled wall switch for lighting.
It is an ATTiny85 (8MHz internal), a 315MHz ASK receiver using RCSwitch, a 5v dual coil latching relay, and a modified Decora rocker switch to be momentary SPST.
The relay toggles either with the manual rocker switch, or with an RF signal, for 3-way switch functioning.
Everything works great. I'm just looking for ways to polish the project with a power saving function to stretch battery life (for the meantime until I decide to feed it from the mains through a converter).
The whole shebang runs on 4 AA NiMH batteries. Haven't run a set into dead yet. But I've tried a single 18650 through a boost to 5V and it only lasted a couple days. Maybe power saving would make the 18650 viable.
The RF receiver uses interrupt 0 on pin 2, and the manually activated rocker is a standard button input/pulldown on pin 3. Those are the two inputs that the ATTiny85 has to respond to, (by writing either pin 0 or 1 HIGH to turn on either relay coil via transistors).
I want to keep the setup running at 5V as the relay needs that and the RF module receives acceptably. I've built one with a 3V coil relay but the RF wasn't too happy.
I've kept it at 8MHz, haven't been sure enough to pick 1MHz in the IDE settings and how that would affect things. But for the simple project that this is, 1MHz should be plenty if it works.
Is it possible to put the ATTiny85 to sleep while still having it responsive to incoming RF data on the interrupt as well as the button input (not interrupt)?
Or does it need two inputs, one to just wake it up and another that it will actually perform other functions?
What does this chart mean by 'only level interrupt'? The pin state change from my button seems okay, but what does incoming RF data look like to the ATTiny85? Will it lose any of the incoming message upfront so I'll have to just send repeats?
Looks like I save some power by going down to 1MHz by putting
CLKPR = 0x80;
CLKPR = 0x03;
in setup when IDE settings are for 8MHz. Using IDE settings for 1MHz don't save any current whereas the above cuts it by over half.
Haven't seen if this affects RF communication yet, that's on the agenda for tomorrow.
Not sure if this is even useful if I do some sort of sleep thing where the active times are so brief it doesn't matter what it draws when active, but when it's sleeping.
It would need two inputs, one to wake it and one for the data. You can't use the data output for this because that those cheap OOK/ASK receivers output gibberish on the output pin if there's no data coming in.
Read the SYN470 datasheet, specifically the special functions for some of the pins. The chip has just the features you want, I think, with regards to power management.
Path of least resistance to using this approach, I think:
Buy a receiver built on a Synoxo SYN470, like the RXB-12's that are abundant and cheap online. Study datasheet, carefully pry up necessary pins and deadbug connections to them to get the wake output and connect to Arduino. Sleep the Arduino while running the receiver full time, and wake with wake pin.
You still need to leave the receiver itself powered sadly.
I had asked you on another thread if the SYN480 was the same as the 470 in terms of your recommendation, don't think I got an answer, but I ordered some back then and still waiting on them.
A few years ago I built a project using a t85 that was in deep sleep most of the time, woke to take a temperature reading (thermistor) and went back to sleep if the current reading was the same as the previous. If not the same, a tri-color LED would light to advise if the temperature was going up or going down (red - blue/green).
Some of the code may be of use .... a number of authors' sleep techniques were used.
You could wake up the receiver intermittently to see if a carrier with a calling code is present - that's what pagers and mobile phones do....
Maybe it's better to go to a slightly bigger MCU like the tiny84 and use RF24L01 transceivers as they have the ability to drop into low power mode and have IRQ to wake the MCU when data arrives.