High reliability mode / guaranteed wake mode for Witty Pi 4

It is a good idea, and I can imagine it will be quite useful for remotely deployed devices.

Just think this feature needs a better name to instantly tell what it does. Calling it "high reliability mode" implies the default mode is not reliable, which is not true for non-battery solutions. We would not turn on this mode by default, because it may trigger unexpected startups: for users who don't need it, that will be called unreliable then.

What this mode does, is to assure the device will be turned on at least once in given duration. "Guaranteed wake mode" might be a better name. The expectation of this duration may vary depends on the use case, so it will be better to make this duration configurable.

If you have tested your implementation, please make a pull request. After merging your code, we may do some renaming and add configurable options. A new startup reason will be added too.

Hi @admin 

Just some thoughs

Option 1

Make day 0 a special case. So if the startup was Day 00 Time 08:00:00 it would start 08:00:00 every day. Or if the Shutdown was Day 00 Time 17:00:00 it would shutdown everyday at 17:00:00

Problem with this one is how to make it work with the schedules

Option 2 

Use another register set to do the same thing. That is a time without a day so the Pi can Start and Shutdown at a specific time everyday. And set via UWI or the shell menu

That way if something goes wrong, say an extended power outage, software crash , or even user error the Pi will always start at a specific time. And  it would be possible to run corrective action . You might have a cron set for 08:05:00 that does something.

Michael

I agree with your input @admin. This of course should not be enabled by default for regular users and the parameters like the time should ideally be user configurable. I agree with the name not being optimal, but I think the same can be said about your suggestion (the witty pi isnt guaranteed to wake up reliably when not activating this mode?). Another suggestion could be a "wake up watchdog". Do you have any input regarding the TinyWireS library? 😀

Thanks for your input @mhornsby. While I see that this could be better in theory, I think this will add a lot of complexity (and thus potential error sources) to the code, as you also need to log at least the last startup time and check the alarms from the rtc in the mcu. Is there a specific use case you have in mind? In my case the schedule is updated automatically by either sunrise/sunset calculations or the raspberry pi downloads it automatically from my server. Like this, the system should start according to the schedule after being restarted once and if an invalid schedule is the problem, it can be updated remotely.

One thing you could do is flip the way the alarms are programmed around (similar to your second idea). The raspberry pi sends its schedule to the mcu and the mcu programs the rtc by itself. The mcu would then reprogram the rtc after every alarm.  This way the raspberry pi would only need to interact with the witty pi if it wants to modify the schedule, thus eliminating a potential problem source. Then you could make a validation that the mcu only overwrites its internal schedule if the schedule sent by the rapsberry pi is valid or potentially check for other conditions - like not being an empty schedule. While this could maybe be better from a reliability perspective, this would require a complete re-write and re-testing of the firmware, which I don't think is feasible.

@eagleshot My use case is I have a Pi with a battery and solar panel in a waterproof enclosure located in a field about 200m from my house. I have no way know of the Pi is running except to walk out to the box and open it. I use Python to set the startup fo Sunrise and shutdown to Sunset. Because I need to specify a day and time for startup  e.g.  Day 30 06:00:00 if for some reason the Pi does not start at that time on Day 30  - it won't start again (maybe in a Month) . For me if I could start at time 06:00:00 without specifying the day , then hopefully it would start the next day

@eagleshot Witty Pi is not guaranteed to wake up your Pi: it would not do so if you have not told it to, or you have told it to wake up your Pi but something went wrong and then it couldn't. There is difference between "guaranteed to wake up" and "working reliably": waking up at a wrong time should not be consdiered "reliable", the same applies to other cases like not shutting down (on time), not cutting power after shutdown, system unexpectly reboot after shutdown etc.

This feature is not a magic that can directly make your system more reliable, instead it provides a chance to troubleshoot and maybe restore a remotely deployed device when something goes wrong. The implementation you proposed is indeed a "wake up watchdog", but people may not understand what it does by seeing its name, while "guaranteed wake mode" directly tell people what it does.

@mhornsby the two options you mentioned are rather complex to implement and most probabley could not be implememted with current remaining resource in the MCU. In your use case, I believe it is good enough to guaranteed at least one startup in 24 hours -- in stead of waiting for a month, you wait for 1 day maxium. You may do some configuration on your Pi so it will send you an email/SMS when it is up, so you can take the chance to access it before it is down again.

The expected duration for such guaranteed wake varies from case to case. Usually you will want the duration to be longer than the cycle period of your schedule script.

Just wanted to ask again because of the TinyWireS library, since I havent been able to compile the firmware. As mentioned, I did only find this TinyWireS library, which I couldnt get to compile: https://github.com/nadavmatalon/TinyWireS . Which library do i need?

@admin

@eagleshot in older version of firmware (for Witty Pi 3 I think), we used https://github.com/orangkucing/WireS , which declares "TinyWireS" instead of "Wire" at the end of its WireS.cpp file. This has been mentioned on this page.

However, in newer firmware we used the WireS library in the ATtinyCore instead, so you do not need to install external WireS library.

Okay, thats weird. It seems that the problem was because of the new arduino ide, with the old one it works without problem.

Hello @admin

I have tested the implementation over the weekend and it worked as I expected. One thing I noticed is the time being very inconsistent and also dependent on other sources such as the length of the LED blink and dummy load duration. I don't consider this is an issue, as this feature should exclusively be used as a backup and normally never triggers and so the exact timing is not relevant, however I think that this should be communicated to users of this feature to avoid confusion. How shall we continue? Here is my TODO list for a full integration of this feature:

* Make counter user programmable and allow user to en-/dissable the feature

* Add a startup reason

* Add voltage validation (similar to normal startup: https://github.com/uugear/Witty-Pi-4/blob/1e33398f37527f7167ee57eff903807ff843fc14/Firmware/WittyPi4/WittyPi4.ino#L371-L377)

Do you want to take over from here or can I help you with the implementation/additional testing?

Regards,

Eagleshot

@eagleshot you may create a pull request with your current implementation. After merging your code we will make further modifications to make this feature complete.

Posted by: @eagleshot

↑

Add voltage validation

I think it is better not to add any voltage validation before triggering the garanteed wake, otherwise an incorrect configuration on recovery voltage threshold will effectly disable this functionality.

I understand that you don't want it to try booting the Pi when battery voltage is still low, but even if it fails to boot up, it still has next chance: the counter will be reset and after a while it will try again. As long as the charging circuit is still working, there will be a moment that you can access the device remotely.

On the other hand, if we validate the voltage here, that can make the "garenteed wake" no longer garenteed, if you use a 7.4V battery and incorrectly configure recovery voltage to 9V, this "garenteed wake" will never happen then.

My reasoning would be, that this voltage only needs to be configured once. After the system has been deployed this setting won't be changed anymore unlike the schedule. Because of this, an accidental incorrect configuration should not be a concern for users, especially as the configuration can be tested before deployment. I think the chance that the process of the pi booting while not having enough power currupting the sd-card and the risk of damaging the battery because of deep discharge is much higher, than the chance of an incorrectly configured recovery voltage. As this setting will probably mostly be used in remote and battery powered systems, I think it would be highly beneficial. Furthermore, just as the recovery voltage, this could/should be optional for the user, so they can choose to use it or not.

@eagleshot In my opinion a well configured/validated device doesn't need such functionality at the first place. So here we do need to consider the consequance of some bad configurations.

However, you do make a point that unsuccesfull startup may corrupt SD card or damage battery, those are worst results.

Hey, this is a great feature! Is this something that will be available in the WittyPi 4 L3V7 as well once it's implemented?  I've got two of them and would be happy to help test.