Cool stuff for Raspberry Pi, Arduino and all electronics hobby projects
Notifications
Clear all

High reliability mode / guaranteed wake mode for Witty Pi 4

28 Posts
4 Users
1 Likes
511 Views
(@eagleshot)
Posts: 32
Eminent Member
Topic starter
 

Hey @admin 🙂

I just wanted to pick the topic of a "high reliability mode" back up, as I wasn't able to implement  a really elegant solution on how to wake up if the system is not woken up by the RTC so far. My use case are systems, where the schedule is updated remotely, so an invalid schedule file could potentially "brick" the system (or other issues such as the capacitor problem, where a start was triggered, but not executed due to power issues).

My newest idea would be a counter that gets increased with every time the watchdog wakes up the MCU. If the raspberry pi starts up (e.g. by the RTC), the counter gets reset. If it doesn't start, the raspberry pi gets started by the MCU after the counter gets big enough (e.g. after 24 hours). This way, this functionality could be added with very low additional complexity and little additional memory usage. You can see an example implementation here: https://github.com/Eagleshot/Witty-Pi-4/commit/abd4251dcd72fd82910d1910d0f52735935744e0

Could this be a feature, that could be implemented in the official firmware or can you give me feedback, if this makes any sense to you? 😀 

Another question I have is that while trying to compile the firmware to test this modification, I couldn't find the TinyWireS library in the Arduino library manager. Do I have to install it manually from this link ( https://github.com/nadavmatalon/TinyWireS) or is there another location to install it?

Thank you very much for your help!😀

Eagleshot

 

 

 
Posted : 28/05/2024 9:36 pm
(@admin)
Posts: 371
Member Admin
 

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.

 
Posted : 29/05/2024 12:21 pm
(@mhornsby)
Posts: 3
Active Member
 

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

 

 

 
Posted : 29/05/2024 8:36 pm
(@eagleshot)
Posts: 32
Eminent Member
Topic starter
 

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.

This post was modified 1 month ago by Eagleshot
 
Posted : 29/05/2024 11:02 pm
(@mhornsby)
Posts: 3
Active Member
 

@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

 
Posted : 30/05/2024 12:33 am
(@admin)
Posts: 371
Member Admin
 

@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.

 

 
Posted : 30/05/2024 12:42 pm
(@eagleshot)
Posts: 32
Eminent Member
Topic starter
 

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

This post was modified 1 month ago 2 times by Eagleshot
 
Posted : 01/06/2024 3:48 pm
(@admin)
Posts: 371
Member 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.

 
Posted : 01/06/2024 4:29 pm
(@eagleshot)
Posts: 32
Eminent Member
Topic starter
 

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

 
Posted : 01/06/2024 5:38 pm
(@eagleshot)
Posts: 32
Eminent Member
Topic starter
 

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

 
Posted : 03/06/2024 8:45 pm
(@admin)
Posts: 371
Member Admin
 

@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 : 04/06/2024 12:58 pm
(@admin)
Posts: 371
Member Admin
 

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.

 
Posted : 06/06/2024 5:08 pm
(@eagleshot)
Posts: 32
Eminent Member
Topic starter
 

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.

 

 

 
Posted : 07/06/2024 9:12 am
(@admin)
Posts: 371
Member Admin
 

@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.

 
Posted : 08/06/2024 3:18 pm
(@drunkenungulate)
Posts: 7
Active Member
 

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.

 
Posted : 08/06/2024 11:22 pm
Page 1 / 2
Join Waitlist We will inform you when the product arrives in stock. Please leave your valid email address below.