Notifications
Clear all
Topic starter
Hey!
Our system was shut down as scheduled,
but rebooted directly,
power got cut (I asume?),
and scheduled startup never happend...
After checking the system, Wittypi LED didn't pulse, but the raspberrypi is off too.
There was no "System starts up because of the scheduled startup got delayed. Maybe the scheduled startup was
due when Pi was running, or Pi had been shut down but TXD stayed HIGH to prevent the power cut." log message (as described in the UserManual).
Any recommendations?
schedule.wpi:
BEGIN 2024-04-19 05:00:00 END 2029-04-19 00:00:00 ON H13 OFF M5
wittyPi.log
[2024-04-19 20:28:23] Schedule next shutdown at: 2024-04-20 07:05:00 [2024-04-19 20:28:25] Schedule next startup at: 2024-04-20 07:10:00 [2024-04-20 07:04:54] Shutting down system because scheduled shutdown is due. [2024-04-20 07:04:55] Halting all processes and then shutdown Raspberry Pi... [xxxx-xx-xx xx:xx:xx] Witty Pi daemon (v4.14) is started. [xxxx-xx-xx xx:xx:xx] Running on Raspberry Pi Zero W Rev 1.1 [xxxx-xx-xx xx:xx:xx] Seems RTC has good time, write RTC time into system [xxxx-xx-xx xx:xx:xx] Writing RTC time to system... [2024-04-20 09:56:17] Done :-) [2024-04-20 09:56:17] Firmware ID: 0x02 [2024-04-20 09:56:17] Firmware Revison: 0x05 [2024-04-20 09:56:19] Current Vin=11.96V, Vout=5.09V, Iout=0.08A [2024-04-20 09:56:20] System starts up because the button is clicked. [2024-04-20 09:56:29] Send out the SYS_UP signal via GPIO-17 pin. [2024-04-20 09:56:31] Pending for incoming shutdown command... [2024-04-20 09:56:47] Schedule next shutdown at: 2024-04-20 20:10:00 [2024-04-20 09:56:48] Schedule next startup at: 2024-04-20 20:15:00
journalctl:
-- Boot a98a7e23993d4a08aa4d298db6bee585 -- Apr 20 07:05:16 raspberrypi kernel: Booting Linux on physical CPU 0x0 Apr 20 07:05:16 raspberrypi kernel: Linux version 6.1.21+ (dom@buildbot) (arm-linux-gnueabihf-gcc-8 (Ubuntu/Linaro 8.4.0-3ubuntu1) 8.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #1642 Mon Apr 3 17:19:14 BST 2023 Apr 20 07:05:16 raspberrypi kernel: CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d Apr 20 07:05:16 raspberrypi kernel: CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Apr 20 07:05:16 raspberrypi kernel: OF: fdt: Machine model: Raspberry Pi Zero W Rev 1.1 ... Apr 20 07:05:33 raspberrypi systemd[1]: Starting LSB: UUGear Web Interface initialize script... Apr 20 07:05:33 raspberrypi thd[325]: Found socket passed from systemd Apr 20 07:05:34 raspberrypi systemd[1]: Starting LSB: Witty Pi 4 initialize script... Apr 20 07:05:34 raspberrypi uwi[335]: Starting UWI server... Apr 20 07:05:34 raspberrypi dphys-swapfile[248]: want /var/swap=100MByte, checking existing: keeping it Apr 20 07:05:34 raspberrypi systemd[1]: Starting WPA supplicant... Apr 20 07:05:34 raspberrypi wittypi[336]: Starting Witty Pi 4 Daemon... Apr 20 07:05:34 raspberrypi uwi[340]: /etc/init.d/uwi: line 17: /home/kuckadm1n/Desktop/kuckuck-pi/uwi/uwi.log: No such file or directory ... Apr 20 07:05:37 raspberrypi systemd[1]: Started LSB: Witty Pi 4 initialize script. ... Apr 20 07:05:47 raspberrypi wittypi[343]: Witty Pi daemon (v4.14) is started. Apr 20 07:05:47 raspberrypi wittypi[343]: Running on Raspberry Pi Zero W Rev 1.1 Apr 20 07:05:47 raspberrypi dbus-daemon[244]: [system] Successfully activated service 'org.freedesktop.hostname1' Apr 20 07:05:47 raspberrypi systemd[1]: Started Hostname Service. Apr 20 07:05:47 raspberrypi NetworkManager[273]: <info> [1713589547.3827] hostname: hostname: using hostnamed Apr 20 07:05:47 raspberrypi NetworkManager[273]: <info> [1713589547.3881] hostname: hostname changed from (none) to "raspberrypi" Apr 20 07:05:47 raspberrypi NetworkManager[273]: <info> [1713589547.4158] dns-mgr[0x22f78d8]: init: dns=default,systemd-resolved rc-manager=resolvconf (auto) Apr 20 07:05:47 raspberrypi NetworkManager[273]: <info> [1713589547.5144] manager[0x22fd018]: rfkill: Wi-Fi hardware radio set enabled Apr 20 07:05:47 raspberrypi NetworkManager[273]: <info> [1713589547.5407] manager[0x22fd018]: rfkill: WWAN hardware radio set enabled Apr 20 07:05:47 raspberrypi wittypi[429]: cat: /home/user/wittypi/tmp/BUILD-DATA: No such file or directory ... Apr 20 07:05:49 raspberrypi wittypi[343]: Seems RTC has good time, write RTC time into system Apr 20 07:05:49 raspberrypi wittypi[343]: Writing RTC time to system... ... Apr 20 07:05:55 raspberrypi kernel: vc4-drm soc:gpu: [drm] Cannot find any crtc or sizes Apr 20 07:05:55 raspberrypi sudo[513]: root : PWD=/ ; USER=root ; COMMAND=/usr/bin/date -s @1713599777 Apr 20 07:05:55 raspberrypi sudo[513]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=0) Apr 20 09:56:17 raspberrypi sudo[513]: pam_unix(sudo:session): session closed for user root Apr 20 09:56:17 raspberrypi wittypi[343]: Done :-)
Posted : 20/04/2024 11:08 am
Topic starter
The reason that the time changed for 2+ hours here, was because Witty Pi's software wrote the correct time into the system. The whole startup session started at about 9:56, not 7:05. The correct way to read timestamp in log has been mentioned on page 35 in the user manual, the same thing applies to system log too.
Sorry for not getting back on this... The whole thing is developed remotely a lot, and the currently available devices are in the field already. Stupid, I know, but that's how it is now... I was hoping to find a solution anyway.
It just happened again, that a RPi shutdown as scheduled, but didn't start as scheduled. I wasn't able to check the device yet, but I'm afraid it is in the same state as mentioned before (wittypi delivering still delivering power as the RPi didn't shutdown fast enough).
As I currently can't change it, nor provide more infos on this, I'd love to suggest some kind of bulletproof RPi watchdog feature instead to prevent this state to happen again and make sure, that no regardless of its state, the RPi will be (re-)booted at some point. Do you think it is possible to set up an alternative firmware with (one of) the following features?
- Instead of date aware schedules, I'd love to have schedules set to repeat daily. e.g. startup everyday at 6am, and shutdown everyday 8pm. This way, a missed startup could be retried at least 24h later. Maybe with remembering to force it with a short power cut, as the last one didn't work. But I guess this won't work as the MCU doesn't have enough space to handle this...
- Instead some kind of watchdog logic to, based on the schedule or power-/temperature-thresholds, re-checks if the raspberrypi is actually on while it should and if not forces to reboot with a short powercut.
- Make both Alarms a startup alarm. The first to happen gently as it does right now (maybe without effect), the second 5 minutes later if as a fallback with previous powercut, if it wasn't disabled after a succesful boot within those 5 minutes. I guess a shutdown with powercut should be possbile to be scheduled from the RPi, so the second of the available two alarms the firmware can handle could be used for this?
As I read around here, that the firmware almost eats up all space, and I don't have an idea on how much more space some of this would need, so maybe the whole temperature handling could be removed for those who do not need it?
Hope to see some solution for this to make the setup somehow more reliable for me.
Thanks for your efforts!
Moritz
please delete my previous post. I wasn't able to edit the typos within the given edit-time.
Posted : 28/04/2024 8:55 pm
@mmoollllee It is really a bad idea to put the device at field before fully verified and tested it. Since the problem keeps happening, shouldn't you take back the device and do the troubleshooting immediately? The best way is to clearly figure out what happened and then we will have a solution for that.
Customizing the firmware is feasible because the firmware is fully open-sourced and we may provide some guidences as well. However this should not be considered at this moment: you have a problem to solve and you don't know yet what it exactly is. Also customizing a firmware takes a lot of work, you will need to fully understand the firmware source code before being able to modify it according to your needs.
With that said, all those firmware features you mentioned can be implemented, and you may have to remove some features from current firmware to get enough space. However this will take you a lot of effort, and it is not a fast way to solve the problem you mentioned.
Posted : 29/04/2024 9:25 am
Page 2 / 2
Prev