Sleeping while waiting for an HTTP IN input

Planner
1

I have a simple script to set pin9 using HTTP IN. It works fine but I am concerned about draining the battery quickly if is left always on.


I tried to add a server.sleepfor() but the remote activation it doesn’t seem to work anymore, even if returns 200.

Please comment on the draining the battery concern and advise a better course of action.

Thanks,

-Marco G.

// Remote Set example 
 
// Variable to represent pin state
local pinState = 0;

// input class for PIN control channel
class input extends InputPort
{
  name = “PIN control”
  type = “number”
 
  function set(value)
  {
      server.log(format(“received value %d”, value));
      
      if(value == 0) {
          // set PIN low
          hardware.pin9.write(0);
          pinState = 0;
          server.show(“LOW”);
      }
      if (value == 1) {
          // set PIN high
            hardware.pin9.write(1);
            pinState = 1;
            server.show(“HIGH”);
      }
  }
}
 
// Configure pin 9 as an open drain output with internal pull up
hardware.pin9.configure(DIGITAL_OUT_OD_PULLUP);
 
// Register with the server
imp.configure(“Remote-Toggle”, [input()], []);

//server.sleepfor((1 * 30));

2

When the imp is in “sleepfor” or “sleepuntil”, server events won’t wake it up. I’m not sure whether the server keeps hold of an HTTP event that happens while the imp’s asleep, and supplies it the next time it wakes up – but if not, that sounds like a useful feature request.

If you want the HTTP event to be acted on instantly, “sleepfor” or “sleepuntil” is too deep a sleep. Apart from anything else, in those sleep states the wifi chip itself is powered down and not listening. The best you can do in that case is normal, “imp.wakeup”-type sleep. I’m not sure what the power consumption of that is at the moment, but I do know that it’s somewhat above the optimum achievable, and we’ve got some significant power-saving features planned for future firmware revisions.

Peter

3
Thank you for clarifying. I am not interested in the HTTP event to be acted instantly, I am more interested in preserving battery life. A 30 to 60 seconds cycle would be enough for my application. How do I know that even with a "imp-wakeup"-type sleep, the request will be delivered?

If I am not missing something, at the moment the request is ignored and lost unless the imp is connected, and the client gets returned "200 OK" regardless. This is probably wrong anyway.

Having the server queueing the request would be optimal. Ideally, the server would queue the request and return the timestamp of the last contact with the imp to the client in the body of the response. This can be very valuable for the remote client to estimate when the imp will establish the next contact.

As a side question, without any sleeping, would anyone have a guess for how long 2AA batteries would last? 

Thanks,

-Marco G.
4

Depending on what type of AA batteries you are using they are usually rated for 2500 mAh (milliampere-hour)

Alkaline batteries can be from 1700 to 3000 mAh

Using the April board depending on how much mA the board is using on top of if you are using the 3.3V pin will give you a rough estimate on how long the batteries will last. The documentation says the 3.3v pin can provide up to 100mA. I cant find the draw of the board itself but to give you an example:

April: 100mA
Using the 3.3v pin: 100mA

2500/200 = 12.5 hours battery life of constant use and no sleeping


5

Queuing of n messages (where n is TBD) is in the todo list; these would get delivered at the next connection. You’re right in that right now there is no way to implement this without using an external server.


Right now, because wifi power save is not enabled, you’re looking at ~24 hours from 2xAA’s in Nora. With PS enabled (but without CPU power management), I just tested this at ~100 hours. We will be in the realms of a month or longer without sleeping from 2xAA - ie connected to wifi constantly - when all the power save items are implemented.

When you sleep, you can get this up significantly higher. The tradeoff is how often you want the device to be able to receive messages.

6

Thank you for all the useful answers.


Great to hear about the power-save feature. For the intended application, I definitely would like to have the queuing in the server to allow the imp to be idle and in deep sleep to extend the battery time to the maximum.

-Marco G.

7

Marco, I’ve found this battery life Calculator quite handy as you can specify sleep and wake power & duration.
http://oregonembedded.com/batterycalc.htm