ahoy
ahoy copied to clipboard
lumapu
Reset Ahoy at midnight (ESP8266, v0.7.11)
Hallo,
ich habe gestern voller Freude das neue Setting/Feature "Reset Ahoy at midnight" entdeckt und sofort die bei mir seit wenigen Wochen stabil laufende v0.7.3 aktualisiert. Heute Morgen habe ich dann allerdings überraschend festgestellt, dass letzte Nacht kein Reset des Ahoy (ESP8266) stattgefunden hat.
Zur Info: Da Abends nach Sonnenuntergang + 30min der WLAN-Router abgeschaltet wird, hat Ahoy kein Netzwerk mehr verfügbar. Möglicherweise gibt es hier ja Abhängigkeiten!?!
Bei der Zeitsynchronisierung hätte ich allerdings erwartet, dass min. eine einmalige Zeitkorrektur zur Unterstützung des Feature passen sollte.
Soeben habe ich zumindest den "alten" bekannten Reset-Grund "Hardware Watchdog" wiedergefunden:
Hierdurch lief meine v0.7.3 ja in den letzten Wochen auch stabil, d.h. gelegentlicher Hardware-Reset durch den Watchdog im <= oder >= Tagesrythmus. ;-)
I think it's wrongly implemented. I will refactor that to get it working. In current implementation it is inside the NTP sync routine, but in Ahoy we have a scheduler to do that independent.
Checked it again - it is correctly implemented but requires once a successfuly NTP sync. You can check if the scheduler has a registration for that function by doing that:
- open
[IP]/serialin first browser tab - open
[IP]/debugin second browser tab - go back to first browser tab and check the outpus
for me it looks like that (for today July 19th)
22:57:38 I: webSc, tmt: 1, rel: 1
22:57:38 I: uart, tmt: 3, rel: 5
22:57:38 I: tSend, tmt: 8, rel: 30
22:57:38 I: mqttS, tmt: 1, rel: 1
22:57:38 I: mqttM, tmt: 10, rel: 60
22:57:38 I: midNi, tmt: 1689804000, rel: 0
22:57:38 I: midRe, tmt: 1689804010, rel: 0
22:57:38 I: ivCom, tmt: 1689822911, rel: 0
22:57:38 I: Sunri, tmt: 1689881260, rel: 0
22:57:38 I: ntp, tmt: 40750, rel: 0
we're only interested for the entry 'midRe' which has a registered timestamp of 1689804010. So it's correct in my case - tested with version 0.7.11. I don't know what happens if the wifi router is turned of during Ahoy-Reboot.
I've checked your proposal with the following results on my setup:
08:02:10` I: (#0) resetPayload
08:02:10 I: (#0) enqueCommand: 0x0b
08:02:10 I: (#0) prepareDevInformCmd 0x0b
08:02:10 15 pid: 80
08:02:10 I: TX 27B Ch75 | 15 81 85 66 81 86 16 45 40 80 0b 00 64 b8 cd e2 00 00 00 08 00 00 00 00 84 09 9e
08:02:10 I: procPyld: cmd: 0x0b
08:02:10 I: procPyld: txid: 0x95
08:02:15 I: webSc, tmt: 1, rel: 1
08:02:15 I: uart, tmt: 5, rel: 5
08:02:15 I: tSend, tmt: 25, rel: 30
08:02:15 I: mqttS, tmt: 1, rel: 1
08:02:15 I: mqttM, tmt: 57, rel: 60
08:02:15 I: midNi, tmt: 1689890400, rel: 0
08:02:15 I: midRe, tmt: 1689890410, rel: 0
08:02:15 I: ivCom, tmt: 1689881893, rel: 0
08:02:15 I: Sunri, tmt: 1689881953, rel: 0
08:02:15 I: ntp, tmt: 32877, rel: 0
1689890410: Fri Jul 21 2023 00:00:10 GMT+0200 (Mitteleuropäische Sommerzeit)
So far neither a reset due to "Reset at midnight" feature nor a reset due to "Hardware Watchdog" which I've seen several times in the last days/weeks with v0.7.3 and v0.7.11 as well.
For me it's not a question it's a bug as the Ahoy firmware up to v0.7.15 doesn't perform a reset at midnight in case that the WiFi network isn't available during night.
yes I will look deeper into that - and there is no fixed dev label until now. So it's still in process.
checked with an ESP8266 which had no WiFi at all (was configured using AP-Mode). Reboot was successful. Time was synced after first boot from browser.
AhoyDTU (ESP8266) still does not reset at midnight (v0.7.23) when WiFi connection is off at night.
Is it possible to check it with a other branch (dev03)? https://github.com/lumapu/ahoy/tree/development03 Download https://github.com/lumapu/ahoy/actions/runs/5981603776 - 0.7.41
Of course but never seen that there is already a fix or change for this issue available. I‘m currently running v0.7.36, the latest stable release. I‘ll update to v0.7.41 in a few minutes to check the issue at next midnight. I‘ll give an update tomorrow.
I checked that problem the last days as well.
These are my settings in v0.7.36:
Activating/Deactivating the option "reset values and YieldDay at midnight" showed up in the logs by doing a http://[IP]/debug after each change, that this is enlisted in my case by "mid2" OR "midNi" and not as you said before by "midRe". Maybe this is the bug already, I don't know.
So my system has this kind of behaviour. After activating the option as shown I got a new entry "midNi": (it goes away after deavtivating the option)
I did that yesterday and had a look now in the logs before starting this answer here and now the entry is named "mid2":
After deactivating the option this entry dissappears. After activating again I have the entry "midNi" in the debug again, not the "mid2" anymore. (I did not play around with other options)
In none of my cases an entry "midRe" showed up.
So my YieldDay goes on day by day in counting without a reset :-)
Additional information:
- My Hoymiles hm 1500 is running 24/7
- NTP setup works properly
I checked that problem the last days as well.
These are my settings in v0.7.36:
Activating/Deactivating the option "reset values and YieldDay at midnight" showed up in the logs by doing a http://[IP]/debug after each change, that this is enlisted in my case by "mid2" OR "midNi" and not as you said before by "midRe". Maybe this is the bug already, I don't know.
So my system has this kind of behaviour. After activating the option as shown I got a new entry "midNi": (it goes away after deavtivating the option)
I did that yesterday and had a look now in the logs before starting this answer here and now the entry is named "mid2":
After deactivating the option this entry dissappears. After activating again I have the entry "midNi" in the debug again, not the "mid2" anymore. (I did not play around with other options)
In none of my cases an entry "midRe" showed up.
So my YieldDay goes on day by day in counting without a reset :-)
Additional information:
- My Hoymiles hm 1500 is running 24/7
- NTP setup works properly
That's another issue as my original one was raised regarding the Device System option "Reboot Ahoy at midnight" and not Inverter option "Reset values and YieldDay at midnight"
Please raise an new issue for this observation. I can confirm that the "Reset values and YieldDay at midnight" isn't working for me since weeks as well. But maybe only due to my special setup that my WLAN-Router isn't running 24/7. I switch off the WLAN-Router during night so that Ahoy doesn't have any internet (and NTP) connection during the night, especially at midnight.
Remark: Some days ago I didn't switch off the WLAN-router during night by mistake and Ahoy did the Device/System reset. So for me my main issue here is that if no 24/7 internet connection, especially at midnight is available those reset won't work. :-(
Of course but never seen that there is already a fix or change for this issue available. I‘m currently running v0.7.36, the latest stable release. I‘ll update to v0.7.41 in a few minutes to check the issue at next midnight. I‘ll give an update tomorrow.
Ahoy device system/reset at midnight is still not working in my specific case that the WLAN-router is off during the night (not running 24/7).
Remark: If the WLAN-router is on at midnight the reset works with the same settings but that isn't my preferred setup. ;-)
L.S. My first Ahoy-DTU was up and running in August 2023. Used it successfully (I can't remember the revision number). Update 0.8.83 is installed last week and I was impressed by the good progress of the development. The reset of YieldDay was performed correctly during the night until I changed a setting. Now I'm struggling to get the reset of values correct while there are several inputs possible. Please note that I'm setting the system time from the browser, there is no connection possible through the NTP server. Herewith I present a list of set-points with my settings and some queries.
- A set-point Reboot Ahoy at midnight is available on the TAB System Configuration.
OFF
I'm careful to reboot the ESP 8266 to often, especially when eeproms are used. When do I need this setting?
- On the TAB Inverter several set-points can be used.
- A set-point Reset values and YieldDay at midnight
ONThis text looks good, this would be my favorite, however in this set-point the following text is added: (Pause communication during night need to be set). Where can I find this set-pointPause communication during night. Furthermore I would like to pause communication from sunset to sunrise. How can values and YieldDay be reset during a pause in communication? (in my original version I could see times of sunrise and sunset. That's gone in update 0.8.83) - A set-point Reset values at sunset
ONThis is an acceptable alternative for resetting at midnight. Does it include YieldDay? - A set-point Reset values when the inverter status is not available
OFFTo be honest, I don't understand the purpose of this set-point. - A set-point Reset 'max' values at midnight
ONThe max values are only used in History I presume?
- A set-point Reset values and YieldDay at midnight
As stated YieldDay is not resetting, hopefully I can correct the mess I created.
L.S. Still couldn't manage to reset the daily values during the night. The raw data of the RSTAPI shows my actual settings:
"rstMid":true,
"rstNotAvail":false,
"rstComStop":true,
"strtWthtTm":false,
"rdGrid":true,
"rstMaxMid":true,
Can someone please tell me how to reset the daily values during the night? Kind regards.
all issues with fixed-dev were closed with the newest release. I can reopen this one
L.S.
Still struggling with the resets overnight.
Now I noticed the ts_sunrise and ts_sunset under /api/index are 0.
Is that normal?
Herewith a copy of the api/index/generic:
wifi_rssi 0
ts_uptime 343830
ts_now 1725004901
version "0.8.83"
modules "MDH-en"
build "5ebfe5a"
env "esp8266"
menu_prot false
menu_mask 61
menu_protEn false
cst_lnk ""
cst_lnk_txt ""
region 0
timezone 1
esp_type "ESP8266"
ts_now 1725004901
ts_sunrise 0
ts_sunset 0
ts_offsSr 0
ts_offsSs 0
Under Settings I filled in:
Latitude (decimal) 52.00000
Longitude (decimal) 4.00000
Offset (sunrise) 0
Offset (sunset) 0
As stated earlier I don't use a NTP Server but browse the time from my mobile during startup. Everything works fine except the reset overnight! Can you please help me?
Kind regards
hi, there is a new release 0.8.140 available. Does your problem also exist with this release?
L.S. After re-installation and checking all settings in v 0.8.83 I get the following on the main page:
Uptime: 0 Days, 00:05:29
ESP-Time: 2024-09-08, 18:27:52
System Infos:
Inverter #0: Oost is available and is producing 115.2W
Inverter #1: West is available and is producing 116.4W
Night time, inverter polling disabled, paused at 1.1.1970, 01:00:00
Night time paused at seams not updated when SYNC FROM BROWSER.
As suggested I tried to UPDATE to v0.8.14. The first things to fill in during initial setup are WEBSERVER and PASSWORD. Never asked before. A beauty of AHOY-DTU is the standalone AP on the ESP8266. Can you please tell me how to start up v0.8.14 in AP mode without requirement to connect to the internet?
kind regards
L.S. Please, what do I have to fill in in the “welcome page” of AHOY-DTU 0.8.140 to use the AHOY-DTU as stand alone acces point? Occasionally I can "SYNC FROM BROWSER" whereafter polling during the night seems to work but I cannot get any inverter data and the system keeps asking for Webserver and Password. Kind regards.
@nexulm is this issue fixed for your setup ?
@psm1711 I understand that you were struggling with how the settings work together. After you have set the Location to your local place and the Offsets, did the settings work for you ? You may need to update the Latitude and Longitude settings for your location, e.g. by looking on Openstreetmap or some other map to find the matching coordinates for your AhoyDTU.
@lumapu if nexulm confirms we can close this issue, or do we need to add some documentation ?
I'll close the issue as I've re-arrange my setup by connecting the Ahoy-DTU to a WiFi AP with 24/7 support in the last months. I can't confirm that the original issue with 07.11 is fixed with any of the newer version as I didn't give the original setup with switching of the WiFi AP over night a chance. BTW: Due to my WiFi issues in the past I've moved over to a WT32-ETH01 LAN connection with OpenDTU, so not using the great AhoyDTU project at the moment.
If anyone else figure out such an issue, please open a new issue.