Issue with "Wake up alarm" - minute period stops working in the morning

[pluhacekp]

Hello guys,

I would like to ask for a support with my setup. The system is measuring Beehives weight , temp etc on regular bases. Hence I have set Wake alarm to 15mins minute_period, then I run a longer Python script in Cron @reboot with sleep wait of 20s, reporting measured values using REST over Wifi to my OpenHAB server and after approx 1.5min it shuts down the sys again.

All is fine for many rounds, but then the issue is that usually in morning I see the last message comming, saying I am shuting down all fine, and then no more wake up.

My setup is Raspberry zero with PiJuice zero. 12000mA battery - no custom changes in the settings Solar panel connected to usb on PiJuice SW v 1.7 & FW PiJuice-V1.5_2021_02_06

on the end of my script I have inserted following to set the alarm (thinking to use variable for minute period to extend the sleep time when battery is not charged enough and shorten it once I have more sun again)

from pijuice import PiJuice if servis == "OFF": print("Nejsem v servisnim modu") requests.put('http://{}:8080/rest/items/StavHoneyPi/state'.format(ip), "OFF", headers=headers) pj=PiJuice(1, 0x14) pj.rtcAlarm.SetAlarm({'minute_period': 15}) pj.rtcAlarm.SetWakeupEnabled(True) pj.power.SetPowerOff(30) os.system("sudo shutdown -h now") else: print("Jsem v servisnim modu")

In my /boot/config.txt dtoverlay=i2c-rtc,ds1339

Not sure if I should look in the PiJuice settings, my code or if there is something linked to charging from the solar panel - the last wake up has been several times at 6:30. Currently we have sun rise at around 6am so in that time it starts to charge, but I see during the day that charging sometimes disappears (BAD or non) if sun is covered and reapers without any impact on wake up ...

I tried to find the answer in the past issues, but with no luck, but surelly I could overlooked something.

Thanks ! Petr

[mmilann]

Hello, how did you installed firmware, from software menu or using pijuice command tool and are you sure it is V1.5_2021_02_06 because there are several releases of V1.5, but you cannot see it from gui?

One situation could be that due to some hazard, pijuice passes through power reset and it clears RTC configuration, like battery fully discharged. In order to make sure it wakeup after these conditions you can enable watchdog and watchdog restore, (period longer than RTC minute_period), if you are using system task.

[pluhacekp]

Hi, well thats a good question, I had some time ago issues with firmware "disapearing" with V1.5. You have suggested to upgrade to SW v1.7 base and FW1.5, but in that time it was not released yet. It fixed the FW disapearance, but then I noticed this new issue. Hence I have tried to purge the pre-release SW1.7 reinstall it and got the FW 1.5 with seems to be the newer version (based on the dates in the filename). Bottom line - I was fiddeling with it some much that I am not sure...

I might try to do also a clean install to be sure that there is nothing left from manual re/installation, but first I will try to use the watch dog suggestion. The annoying part is that I always need to wait a day to see if a change helps and if not then go on site and start it manually.

Thx. !

[tvoverbeek]

@pluhacekp In your script you only set the minute period: pj.rtcAlarm.SetAlarm({'minute_period': 15}). This clears all the other settings you need like every day, every hour. If you want to refresh/change the rtc alarm settings you specified in the GUI/CLU, you will have to include all of them in the rtcAlarmSetAlarm() call.

Also since you have an internet connection the timesyncd daemon will periodically clear the rtc alarm wakeup flag. There is a small chance this happens in your script between setting the rtc wakeup and the end of the shutdown. You can avoid this by specifying dtoverlay=i2c-rtc,ds1307 in .boot/config.txt. DS1307 has the same clock interface as the DS1339, but no alarm. So the OS cannot interfere with your rtc wakeup settings. I also assume you have set the EEPROM address for the HAT to 0x52, so the dtoverlay in the EEPROM does not get loaded at boot.

[pluhacekp]

@tvoverbeek - ok, I have changed the dtoverlay to ds1307.

Not sure how is it with the setting alarm if I use minute_period only and then check with pijuice.rtcAlarm.GetAlarm() it returns

{'data': {'second': 0, 'minute_period': 15, 'hour': 'EVERY_HOUR', 'day': 'EVERY_DAY'}, 'error': 'NO_ERROR'}

so it seems that others are still in. Is it problem anyway? I thought that if I have 15mins period it starts every 15mins all the time so there is no need to set it to every hour / day

my setting is as bellow - should the address be set to 50 or 52 ?

[tvoverbeek]

Change it to 52, just to be sure ds1339 (specified in the EEPROM) is not used

[pluhacekp]

ok, thanks Ton, I have change that to 52 and will see.

[pluhacekp]

Hello, so it seems change of the EEPROM address to 52 did the trick. I maybe the reason why I did not see the issue in past was that my Python script was very short, running for few seconds only. Since I had to extend it to make sure my weight measurements are done properly it runs about 2 mins now which increased chance "that timesyncd daemon will periodically clear the rtc alarm wakeup flag". Anyway I have now marked second day without the issue so I hope it will not come back anymore. Big thanks

I have bit off topic question regarding the 12000mA battery which I am charging from 30W solar panel. Up until FW1.4 I have seen quite smooth charging / discharging graph, however with FW1.5 this has changed and during discharge the charge values reports are bit strange. First after sun goes down the charge level drops immediatelly by 20-30% (black) and then it slows dome significantly, but still jumps up and down (red areas). Would battery JSON parameters change help ?

[mmilann]

@pluhacekp yes you can enter custom buttery profile parameter from JSON file, that should calibrate charge estimation, also need to set "soc measurement" to mcu option.

[pluhacekp]

@mmilann I was actually hoping for some specific paramenter suggestion ;-) I can try to play a bit with those, I am just little worried to fry the thing. Was there any specific change from FW1.4 to FW1.5 on 12000mA battery that could cause that, I think there used to be issue with temperature measurement which is now fixed, but during discharging the battery was reporting more sensible values.

[mmilann]

Fuel gauge on board is not precise for large capacities, so better to set soc measurement by mcu that depends on parameters specific to each battery. Temperature measurement is improved in V1.5, other JSON parameters apply also for V1.4.