MaxPower, MaxACPower und Alarms werden nachts nicht gelöscht

[elisenjens]

Platform

ESP8266

Assembly

I did the assebly by myself

nRF24L01+ Module

No response

Antenna

external antenna

Power Stabilization

nothing

Connection picture

• [ ] I will attach/upload an Image of my wiring

Version

0.7.40

Github Hash

fd2fd20

Build & Flash Method

AhoyDTU Webinstaller

Setup

Standard with MQTT Sunrise and Sunset set Reset values and YieldDay at midnight set Reset 'max' values at midnight set

Debug Serial Log output

AhoyDTU © 2023
Discord
Github
GIT SHA: fd2fd20 :: 0.

Error description

Values are not resetted; was ok before 0.7.39

[elisenjens]

After reboot Max values are resetted

[elisenjens]

Tested 0.7.41: no fix

[elisenjens]

Funzt in 0.7.44 wieder; close

[lumapu]

interssant, denn es wurde nichts geändert 😉 Bei meinem ESP32 funktioniert es auch.

[elisenjens]

Heute morgen sind die Max Werte noch vom Vortag da; muss gestern dann tagsüber einen Reboot gegeben haben, der die Werte gelöscht hat.

[lumapu]

bei mir klappt es täglich. Kannst du bitte bei deiner DTU mal auf [IP]/serial gehen und in einem zweiten Tab/Fenster auf [IP]/debug? Dann wieder zurück in den ersten Tab. Dort müsstest du jetzt ähnliches vorfinden:

21:10:07 I: webSc, tmt: 1, rel: 1
21:10:07 I: uart, tmt: 2, rel: 5
21:10:07 I: tSend, tmt: 2, rel: 5
21:10:07 I: tsCmt, tmt: 1, rel: 1
21:10:07 I: mqttS, tmt: 1, rel: 1
21:10:07 I: wifiL, tmt: 1, rel: 1
21:10:07 I: mqttM, tmt: 20, rel: 60
21:10:07 I: midNi, tmt: 1693864800, rel: 0
21:10:07 I: ivCom, tmt: 1693886851, rel: 0
21:10:07 I: Sunri, tmt: 1693938075, rel: 0
21:10:07 I: ntp, tmt: 41180, rel: 0

als nächstes kannst du prüfen, ob der Timestamp unter midNi wirklich nächster Mitternacht entspricht.

[elisenjens]

Hi Lukas,

sorry, war im Urlaub. Hier mein Log:

14:30:15 I: webSc, tmt: 1, rel: 1

14:30:15 I: uart, tmt: 5, rel: 5

14:30:15 I: tSend, tmt: 5, rel: 30

14:30:15 I: mqttS, tmt: 1, rel: 1

14:30:15 I: wifiL, tmt: 1, rel: 1

14:30:15 I: mqttM, tmt: 38, rel: 60

14:30:15 I: midNi, tmt: 1694210400, rel: 0

14:30:15 I: ivCom, tmt: 1694196337, rel: 0

14:30:15 I: Sunri, tmt: 1694196397, rel: 0

14:30:15 I: ntp, tmt: 42818, rel: 0

14:30:20 I: (#0) enqueCommand: 0x0b

14:30:20 I: (#0) prepareDevInformCmd 0x0b

14:30:20 I: TX 27 CH23 | 15 83 06 93 56 81 89 18 63 80 0b 00 64 fb 13 dc 00 00 00 00 00 00 00 00 fd cf cf

14:30:20 I: procPyld: cmd: 0x0b

14:30:50 I: (#0) enqueCommand: 0x0b

14:30:50 I: (#0) prepareDevInformCmd 0x0b

14:30:50 I: TX 27 CH40 | 15 83 06 93 56 81 89 18 63 80 0b 00 64 fb 13 fa 00 00 00 00 00 00 00 00 9c 7d 3a

14:30:50 W: (#0) Frame 1 missing: Request Retransmit

14:30:50 I: TX 11 CH61 | 15 83 06 93 56 81 89 18 63 81 a7

14:30:50 W: (#0) Frame 4 missing: Request Retransmit

14:30:50 I: TX 11 CH75 | 15 83 06 93 56 81 89 18 63 84 a2

14:30:50 I: procPyld: cmd: 0x0b

14:31:20 I: (#0) enqueCommand: 0x0b

14:31:20 I: (#0) prepareDevInformCmd 0x0b

14:31:20 I: TX 27 CH3 | 15 83 06 93 56 81 89 18 63 80 0b 00 64 fb 14 18 00 00 00 00 00 00 00 00 e2 1c c0

14:31:20 I: procPyld: cmd: 0x0b

14:31:50 I: (#0) enqueCommand: 0x0b

14:31:50 I: (#0) prepareDevInformCmd 0x0b

14:31:50 I: TX 27 CH23 | 15 83 06 93 56 81 89 18 63 80 0b 00 64 fb 14 36 00 00 00 00 00 00 00 00 43 c9 9a

14:31:50 I: procPyld: cmd: 0x0b

14:32:20 I: (#0) enqueCommand: 0x0b

14:32:20 I: (#0) prepareDevInformCmd 0x0b

14:32:20 I: TX 27 CH40 | 15 83 06 93 56 81 89 18 63 80 0b 00 64 fb 14 54 00 00 00 00 00 00 00 00 21 78 2b

14:32:20 W: (#0) Frame 1 missing: Request Retransmit

14:32:20 I: TX 11 CH61 | 15 83 06 93 56 81 89 18 63 81 a7

14:32:20 W: (#0) Frame 1 missing: Request Retransmit

14:32:20 I: TX 11 CH75 | 15 83 06 93 56 81 89 18 63 81 a7

14:32:20 I: procPyld: cmd: 0x0b

Von: Lukas Pusch @.> Gesendet: Montag, 4. September 2023 21:13 An: lumapu/ahoy @.> Cc: elisenjens @.>; State change @.> Betreff: Re: [lumapu/ahoy] MaxPower, MaxACPower und Alarms werden nachts nicht gelöscht (Issue #1125)

bei mir klappt es täglich. Kannst du bitte bei deiner DTU mal auf [IP]/serial gehen und in einem zweiten Tab/Fenster auf [IP]/debug? Dann wieder zurück in den ersten Tab. Dort müsstest du jetzt ähnliches vorfinden:

21:10:07 I: webSc, tmt: 1, rel: 1 21:10:07 I: uart, tmt: 2, rel: 5 21:10:07 I: tSend, tmt: 2, rel: 5 21:10:07 I: tsCmt, tmt: 1, rel: 1 21:10:07 I: mqttS, tmt: 1, rel: 1 21:10:07 I: wifiL, tmt: 1, rel: 1 21:10:07 I: mqttM, tmt: 20, rel: 60 21:10:07 I: midNi, tmt: 1693864800, rel: 0 21:10:07 I: ivCom, tmt: 1693886851, rel: 0 21:10:07 I: Sunri, tmt: 1693938075, rel: 0 21:10:07 I: ntp, tmt: 41180, rel: 0

als nächstes kannst du prüfen, ob der Timestamp unter midNi wirklich nächster Mitternacht entspricht.

— Reply to this email directly, view it on GitHub https://github.com/lumapu/ahoy/issues/1125#issuecomment-1705632292 , or unsubscribe https://github.com/notifications/unsubscribe-auth/A5776ZL5XJAYIILVFPKYFHDXYYR2BANCNFSM6AAAAAA37PUI64 . You are receiving this because you modified the open/close state. https://github.com/notifications/beacon/A5776ZPKXH4CRLCUJRO6URTXYYR2BA5CNFSM6AAAAAA37PUI66WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTFVHRCI.gif Message ID: @. @.> >

[elisenjens]

Hab mal ein Downgrade auf 0.7.36 mit Erase gemacht und da funktioniert das Löschen der Max-Werte

[elisenjens]

Testweise bin ich jetzt per Update wieder auf die 0,7.47 und schau morgen, ob es funzt

[elisenjens]

scheint durch das Downgrade und Erase gefixt; danke für die Hilfe!

[elisenjens]

Heute morgen sind die Max-Werte vom Vortag wieder da (0.7.48).

[elisenjens]

Standby: in der alten Version war das Flag für "Max-Werte nachts löschen" noch nicht drin, oder? Kann sein, dass ich es dann nach dem Update auf die Dev nicht gesetzt hatte; muss ich morgen wieder testen; sorry...

[elisenjens]

Leider hat das Setzen des Flags nicht geholfen; nach wie vor werden bei mir die Max Werte nicht gelöscht

[elisenjens]

Habe jetzt nochmal die stable geflasht und auch da werden meine Max-Werte nicht zurückgesetzt

[technics42]

I am using 0.7.36 and values are also not reset, altough option is checked. I also checked to reboot and midnight, which also doesn't work. Maybe it (both) depends on wifi available? Because usually my wifi is switched off during night.

[elisenjens]

Interesting comment: same situation with my Fritzbox: Wifi switched off at night time. Happy to test this night again with Wifi switched on. THX!

[technics42]

Also display is not switched on in the morning, if there is no wifi available, probably polling of inverter does not start and that's why display is off. Once wifi is switched on, display comes up and inverter polling is working.

[elisenjens]

Wifi active at midnight fixes the issue. Thx to technics42! Lumapu: can we handle this issue as a change request (enhancement) to ensure that Max-Werte are resetted even if Wifi ist switched off (e. g. variable time when reset should take place)?

[technics42]

@lumapu I guess event handling based on time (midnight-events, starting of polling,...) should be made independent on wifi, once there is a valid time set. This could solve some of the open issues, reported for resetting values, max. values, inverter polling,...

[elisenjens]

Grateful if you could pick it up as an enhancement! Fully supported.

[lumapu]

yes, I see your point. For now I have no idea why these functions depend on WiFi. As I have noticed it also occurs if a valid time was set but router isn't available during nighttime.

[technics42]

@lumapu I am really not familiar with your code, but after taking a short look into it, I could imagine that the problem comes from app::onNetwork(). This function is called on wifi-disconnect with gotIp=false. So you just go into else-branch where you do not register any tickers (e.g. NRF) and just use loopWifi instead of loopStandard. So, for me it seems like on disconnected wifi you are just trying to connect to wifi again - could you please check?

[lumapu]

I think you exactly found the point, will test this the next days

[You69Man]

@lumapu I have also observed, that if i disconnect my WiFi router (during day!), the local display of the Ahoy goes to "offline" status. Display "offline" status however derives from the inverter iv->isProducing() function which should have absolutely no relationship to the "other" communication side (WiFi). I didn't dig deeper into this yet (although I planned to), but can it be that we are on the same track here?

[beegee3]

onNetwork, loopWifi and loopStandard were created before all these midnight and display features took place in the code. In the scenarios described here, it makes no sense to use two different loops. loopStandard should be called in all scenarios. But if Wifi is lost (offline), Mqtt should not be called. @lumapu: are there other features depending on Wifi? Else I would propose a variable like mNetworkConnected and change the code to:

void app::loop(void) {
    ah::Scheduler::loop();

    if (mNrfRadio.loop() && mConfig->nrf.enabled) {
        while (!mNrfRadio.mBufCtrl.empty()) {
            packet_t *p = &mNrfRadio.mBufCtrl.front();

            if (mConfig->serial.debug) {
                DPRINT(DBG_INFO, F("RX "));
                DBGPRINT(String(p->len));
                DBGPRINT(F(" CH"));
                DBGPRINT(String(p->ch));
                DBGPRINT(F(", "));
                DBGPRINT(String(p->rssi));
                DBGPRINT(F("dBm | "));
                ah::dumpBuf(p->packet, p->len);
            }
            mStat.frmCnt++;

            Inverter<> *iv = mSys.findInverter(&p->packet[1]);
            if (NULL != iv) {
                if (IV_HM == iv->ivGen)
                    mPayload.add(iv, p);
                else
                    mMiPayload.add(iv, p);
            }
            mNrfRadio.mBufCtrl.pop();
            yield();
        }
        mPayload.process(true);
        mMiPayload.process(true);
    }
    #if defined(ESP32)
    if (mCmtRadio.loop() && mConfig->cmt.enabled) {
        while (!mCmtRadio.mBufCtrl.empty()) {
            hmsPacket_t *p = &mCmtRadio.mBufCtrl.front();
            if (mConfig->serial.debug) {
                DPRINT(DBG_INFO, F("RX "));
                DBGPRINT(String(p->data[0]));
                DBGPRINT(F(", "));
                DBGPRINT(String(p->rssi));
                DBGPRINT(F("dBm | "));
                ah::dumpBuf(&p->data[1], p->data[0]);
            }
            mStat.frmCnt++;

            Inverter<> *iv = mSys.findInverter(&p->data[2]);
            if(NULL != iv) {
                if((iv->ivGen == IV_HMS) || (iv->ivGen == IV_HMT))
                    mHmsPayload.add(iv, p);
            }
            mCmtRadio.mBufCtrl.pop();
            yield();
        }
        mHmsPayload.process(false); //true
    }
    #endif
    mPayload.loop();
    mMiPayload.loop();
    #if defined(ESP32)
    mHmsPayload.loop();
    #endif

    if (mMqttEnabled && mNetworkConnected)
        mMqtt.loop();
}

//-----------------------------------------------------------------------------
void app::onNetwork(bool gotIp) {
    DPRINTLN(DBG_DEBUG, F("onNetwork"));
    mNetworkConnected = gotIp;
    ah::Scheduler::resetTicker();
    regularTickers();  // reinstall regular tickers
    every(std::bind(&app::tickSend, this), mConfig->nrf.sendInterval, "tSend");
    #if defined(ESP32)
    if(mConfig->cmt.enabled)
        everySec(std::bind(&CmtRadioType::tickSecond, &mCmtRadio), "tsCmt");
    #endif
    mMqttReconnect = true;
    mSunrise = 0;  // needs to be set to 0, to reinstall sunrise and ivComm tickers!
    //once(std::bind(&app::tickNtpUpdate, this), 2, "ntp2");
    tickNtpUpdate();
    #if !defined(ETHERNET)
    if (WIFI_AP == WiFi.getMode()) {
        mMqttEnabled = false;
    }
    everySec(std::bind(&ahoywifi::tickWifiLoop, &mWifi), "wifiL");
    #endif /* !defined(ETHERNET) */
}

Here loopStandard is moved to app:loop and loopWifi is dropped. So mInnerLoopCb is not needed anymore. Hope this suggestion does not create trouble since the former loopStandard now runs independently of a valid time. Maybe an app::loop early exit is needed if time is not set.

[elisenjens]

Happy to support testing!

[You69Man]

Ich fürchte, da hat's noch eine Kleinigkeit mit der neuen mainloop in der 0.7.51 (commit 77ba2783). Gerade testhalber aufgespielt (ESP8266, HM800): Wifi ist on, MQTT ist on, RF24 ok, aber Inverter bleibt not available, und Display status daher "offline". Zurück auf 0.7.50 ist alles wieder gut.

[elisenjens]

0.7.51 fixes the issue; THX to all involved and the good teamwork!!!

[technics42]

What about the previous comment? Is there a problem with inverter-polling and/or display with version 7.51?

[You69Man]

What about the previous comment? Is there a problem with inverter-polling and/or display with version 7.51?

I have just now done some more tests on my ESP32 system (NRF24, HM800). Unfortunately still the same results:

Test of V0.7.51 (own Platform.io build): Version runs up NRF24: Ok WiFi: Ok Time synchronization: Ok Inverter communication: Not ok! (waited 5 minutes) -> Inverter "not yet available", Display "offline"

Test of V0.7.55 (own Platform.io build): Same result as V0.7.51 own build

Test of ESP32 with 230917_ahoy_0.7.55_a18a738_esp32.bin (from GitHub dev builds): Same result as with own builds

Back to V0.7.50 (own Platform.io build): Version runs up NRF24: Ok WiFi: Ok Time synchronization: Ok Inverter communication: Ok, after about 10 seconds and shown on display

I'm astonished that it seem that I'm the only one having this issues, am I?

@lumapu: Please reopen the issue!

[lumapu]

Maybe it's time for a new issue?

[You69Man]

Maybe it's time for a new issue?

Neues Issue und neue Erkenntnis dazu, hier: https://github.com/lumapu/ahoy/issues/1164

[elisenjens]

0.7.51 doesn't show alarms next day

[lumapu]

Can you try 0.7.56 or newer (tomorrow)

[elisenjens]

0.7.57 displays alarms ok but shows 0.7.51 in the footer line

[Ollipop030]

0.7.57 displays alarms ok but shows 0.7.51 in the footer line

Then it´s still 0.7.5.1. You have to flash via ESP Flasher or similar, OTA is broken in 0.7.51 and you have to configure your ESP from scratch. If you are on ESP8266 then don´t update to 0.7.57, there is a bug with saving settings, see https://github.com/lumapu/ahoy/issues/1166.

[technics42]

Working with version 0.7.65 using ESP8266 - values are reset at midnight, even if wifi is switched off.

[lumapu]

thank you for testing