search

uugear / Witty-Pi-4

Software and Firmware for Witty Pi 4
MIT License
23 stars 16 forks source link

help with a schedule #17

Closed 3ricj closed 11 months ago

3ricj commented 11 months ago

Hi there,

I'm trying to work out a schedule so that the rpi will wake up for 2 minutes a few times per day, and then shut off again.

For example:

BEGIN 2022-06-01 00:00:00 END 2035-07-31 23:59:59 OFF M300 ON M2 OFF M88 ON M2 OFF M688 ON M2 OFF M43 ON M2 OFF M31

For easy of reading, here's the absolute times:

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns="http://www.w3.org/TR/REC-html40">

  |   | 0:00 -- | -- | -- OFF | 300 | 5:00 ON | 2 | 5:02 OFF | 88 | 6:30 ON | 2 | 6:32 OFF | 688 | 18:00 ON | 2 | 18:02 OFF | 43 | 18:45 ON | 2 | 18:47 OFF | 313 | 0:00

`

If I've done this right it should wake up at 5am, 6:30am, 6pm, and 6:45pm. This is, in general, working.

However, where it's getting confused is the following:

Let's say at 1:20pm, I manually wake up the rpi: in order to check something on it -- the runscript.sh fires on boot, reads the schedule... here's what is printed into the schedule.log:

--------------- 2023-10-26 13:20:02 --------------- Schedule next shutdown at: 2023-10-26 18:02:00 Schedule next startup at: 2023-10-26 18:45:00

Note: the next scheduled startup is at 18:45 (6:45pm)-- that's incorrect, or at least not what I expect. If it's following the schedule.. it should wake up at 6pm still -- that time hasn't arrived! It's only 1:20pm.... so it misses the next wake up.

There seems to be an omission in the logic of runScript.sh; in this case my expectation is that it will still wake up again at 6pm... but instead, it seems to be skipping ahead to the next part of the schedule. Perhaps it's assuming it doesn't need to turn on because it's already awake?

Is there a workaround here or something I'm missing in order to get the system to turn on when scheduled?

Best, -3ric

3ricj commented 11 months ago

Any information?

uugear commented 11 months ago

After BEGIN and END, you need to define ON first, and then OFF. ON and OFF have to appear in pair. In your script you have 5 OFFs and 4 ONs.

You may use H5 for five hours, instead of M300. Both can work but H5 is more friendly to readers.

3ricj commented 11 months ago

Thank you. I've made that change but the bug persists: 

$ ./runScript.sh
--------------- 2023-10-31 11:27:50 ---------------
Schedule next shutdown at: 2023-10-31 18:02:00
Schedule next startup at:  2023-10-31 18:45:00
---------------------------------------------------
$ cat schedule.wpi
BEGIN   2023-10-31 05:00:00
END     2035-07-31 23:59:59
ON      M2    # stay on for 2 minutes until 5:02
OFF     M88   # stay off for 88 minutes until 6:30
ON      M2    # stay on for 2 minutes until 6:32
OFF     M688  # stay off for 688 minuts until 1800 (6:00pm)
ON      M2    # stay on for 2 minutes until 1802 (6:02pm)
OFF     M43   # stay off for 43 minutes u ntil 1845 (6:45pm)
ON      M2    # stay on for 2 minutes until 1847 (6:47pm)
OFF     M613  # stay off for 613 minutes until 0500 (5:00am) the next day.  Total minutes: 1440.
$
uugear commented 11 months ago

This is called "shifting ON state", as mentioned on page 19 in the user manual.

3ricj commented 11 months ago

So... if I understand correctly, here's what I need to do:

What I don't understand is how I can make a very basic on and off schedule which is always followed. The instructions mention.. I could change the BEGIN time -- so.. that means I need to completely restructure the schedule anytime I turn on the rpi? that doesn't seem very user friendly, and really won't work for my end users.

For example, let's think about how a thermostat program works. It's programmed to set the heat to 25c from 8am to 10am, 15c from 10am to 6pm, and 25c from 6pm until 10pm. If the user overrides this schedule: For example, changing the temp in the middle of the day because they are home -- I would still expect it to return back to the schedule at the very next transition. Not the one after it, which seems to be how the witty system is designed.

Effectively, it seems I may need to just remove all of the witty code and set the i2c registers myself due to this very strange and extremely unhelpful feature.

uugear commented 11 months ago

You want the schedule to be followed all the time, but you interrupted it by turning it on at a time that it is supposed to be off.

A "schedule rivising" mechanism has be implemented for this scenario, but I don't know why you didn't see it happen.

You can always implement your own software to suit your needs, this is one important reason why we publish the source code of software.

3ricj commented 11 months ago

Hi there,

Does the schedule revising mechanism operate if the pi is shutdown before the scheduled wakeup time?

I'm not sure why this bug exists. "interrupting a schedule" by turning on a pi shouldn't change the scheduled timing. Can you explain why this is useful to anyone, in any context? I can't seem to think of any other scheduled device with this behavior.

I mean, the witty knows that the wakeup reason was manual power on -- but it seemingly doesn't check that in the code.

It's great that you've published the code, but it's pretty hard to find this bug in the code, and I've been looking. Best I can tell, it's an omission of some logic around line 136 on runScript.sh. I would really love some help in resolving this.

uugear commented 11 months ago

You need to understand how Witty Pi works. It has one RTC with two alarms, one for shutdown and one for startup. Everytime you boot your Pi (either manually or automatically), the software has one chance to schedule the shutdown and the next startup. The scheduled times are based on the current time (when the Pi is boot), that's why you interrupted the schedule when turning on the pi when it should be off.

In my previous answer I already gave a link to describe the schedule revising mechanism, or you may see below:

Schedule revising is such a mechanism, that it tries to fix the schedule, when the schedule is interrupted.

For example, your Raspberry Pi should be waken up on 2:00, but it turns on at 1:33. When 2:00 comes, your Pi is already on and the scheduled startup will be simply ignored. The bad thing is that, without booting on 2:00, Witty Pi's software can not properly schedule the next shutdown, which means the schedule script has been interrupted and will not continue.

Schedule revising is the way that Witty Pi software try to fix this problem, it detected that your Raspberry Pi is awake at a wrong time, and it immediately schedule a shutdown just 1 minute before the scheduled next startup time. By doing so, your Pi will reboot at the next startup time and the schedule script will continue.

3ricj commented 9 months ago

For anyone else facing this problem:

The issue was actually resolved by updating the firmware on the board. The boards from adafruit all have the missing cap (so they don't work at all with any modern PI), and have old firmware which causes them to never turn on correctly with basic schedules.