Falscher ZeitSlot wird bei Entfernen von "Gäste anwesend" in Verbindung mit "Urlaub zu Hause" und "Urlaub zu Hause wie Sonntag" gewählt

[daniel-finger]

Ich nutze HeatingControl mit der Einstellungen:

• "jeden Tag separat"
• ein Profil
• 4 Perioden
• Temperaturabsenkung absolut
• Feiertag wie Sonntag
• Urlaub zu Hause wie Sonntag

Ich mach also "Urlaub zu Hause", weil ich HomeOffice habe und mit dem aufstehen den Datenpunkt Gäste anwesend auf true, damit die Heizung anfängt (der reguläre Zeitpunkt wäre später). Das funktioniert auch und wird erkannt. Später (also wenn die Heizung regulär an sein sollte aufgrund von "Urlaub zu Hause") setze ich den Datenpunkt Gäste anwesend wieder zurück. Dabei wird die Heizung aber auf den falschen Datenpunkt zurückgestellt. Starte ich den Adapter neu, ist wieder alles korrekt.

Die Einstellungen für Sonntag und Montag sehen so aus:

und die Einstellungen für den Raum:

Nach dem Neustart wird das folgende angezeigt:

Das StatusLog des Raums zeigt (die Zeilen mit -- beginnend hab ich eingebaut, damit man weiß was da passiert):

04.12.2023 11:50:22 auto holiday at home 20°C
04.12.2023 11:50:22 auto 16.5°C
04.12.2023 11:50:20 starting holiday at home 16.5°C
04.12.2023 11:50:20 starting 16.5°C
04.12.2023 11:50:19 starting
--------- restart ----------------
04.12.2023 10:00:14 auto holiday at home 16.5°C
-- 04.12.2023 10:00:14 reset Guests variable -------
04.12.2023 07:37:03 auto Guests holiday at home 20°C
03.12.2023 23:00:00 auto holiday at home 16.5°C
03.12.2023 10:00:00 auto holiday at home 20°C
-- 03.12.2023 10:00:00 reset Guests variable -------
03.12.2023 09:02:00 auto Guests holiday at home 20°C
03.12.2023 08:30:00 auto holiday at home 20°C

Wenn ich zusätzlich was ausprobieren oder weitere Logs liefern soll, einfach Bescheid geben.

[rg-engineering]

@daniel-finger ich habe versucht, das Problem nachzustellen, leider bisher ohne Erfolg.
Kannst du mir ein komplettes debug-log von dem Vorgang erzeugen und mir zukommen lassen? Gern auch per email, da die logs gerne recht groß werden...

[daniel-finger]

@rg-engineering Gern, ich habe eben das Loglevel des Adapters umgestellt und meine Workarounds deaktiviert.
Morgen Abend müsste ich ein vollständiges log haben.

[daniel-finger]

@rg-engineering Ich habe das Log hier als Text Anhang mit eingefügt: heatingcontrol.log

Zu den Zeitpunkten:
2024-02-12 21:16:39 Start des Adapters
2024-02-12 23:00:00 Schlafzimmer, Essdiele, Badezimmer, Küche, Arbeitszimmer werden auf 16.5°C gestellt
2024-02-12 23:50:00 Wohnzimmer wird auf 16.5°C gestellt
2024-02-13 06:16:43 Ich stehe auf und DP 0_userdata.0.Heizung.GuestsOrIncrease -> TRUE
2024-02-13 06:16:43 Heizungen werden aktiviert
2024-02-13 08:32:09 Ich gehe nochmal an dem entsprechenden Bewegungsmelder vorbei, der auch feststellt, wann ich
aufgestanden bin. Setzt True nochmal, ändert nichts an den Heizungen
2024-02-13 10:00:09 0_userdata.0.Heizung.GuestsOrIncrease wird auf false gesetzt und auf den Heizungen ein resetManual gemacht, falls ich zwischenzeitlich an den Heizungen gespielt habe.
Der Adapter macht Beispielsweise:
2024-02-13 10:00:09.457 - debug: heatingcontrol.0 (28370) Schlafzimmer ### ChangeStatus GuestsPresent to false in auto
2024-02-13 10:00:09.457 - debug: heatingcontrol.0 (28370) Change Status GuestsPresent in Schlafzimmer to false
2024-02-13 10:00:09.457 - debug: heatingcontrol.0 (28370) CalculateRoomTemperature for Schlafzimmer auto false
2024-02-13 10:00:09.457 - debug: heatingcontrol.0 (28370) Schlafzimmer auto mode: target 16.5
2024-02-13 10:00:09.457 - debug: heatingcontrol.0 (28370) Schlafzimmer auto mode (incl. reduced): target 16.5
2024-02-13 10:00:09.458 - debug: heatingcontrol.0 (28370) SetRoomTemperature started for Schlafzimmer target 16.5 with offset 0
2024-02-13 10:17:18 Ich restarte den Adapter und alles wieder zu korrigieren.
2024-02-13 10:17:30.928 - debug: heatingcontrol.0 (7245) sunday profile used for holiday at home
2024-02-13 10:17:30.972 - debug: heatingcontrol.0 (7245) Schlafzimmer: set new state auto
2024-02-13 10:17:30.973 - debug: heatingcontrol.0 (7245) Schlafzimmer ### ChangeStatus ProfilPoint to -99 in auto
2024-02-13 10:17:30.973 - debug: heatingcontrol.0 (7245) ChangeStatus Profilepoint in Schlafzimmer just recalc
2024-02-13 10:17:30.974 - debug: heatingcontrol.0 (7245) CalculateRoomTemperature for Schlafzimmer auto false
2024-02-13 10:17:30.975 - debug: heatingcontrol.0 (7245) Schlafzimmer auto mode: target 19
2024-02-13 10:17:30.975 - debug: heatingcontrol.0 (7245) Schlafzimmer auto mode (incl. reduced): target 19
2024-02-13 10:17:30.976 - debug: heatingcontrol.0 (7245) SetRoomTemperature started for Schlafzimmer target 19 with offset 0

Ich hoffe das hilft etwas, um durch das Log zu finden. Wenn du mehr brauchst, oder ich was testen soll, einfach was sagen.

[rg-engineering]

@daniel-finger ich denke, ich habe das Problem gefunden, die Lösung habe ich aber noch nicht. In der Zwischenzeit könntest du folgendes machen:

• setze die Zeitperioden jeden Tag identisch, d.h. setze einen Zeitpunkt um 8:30Uhr für jeden Tag, nicht nur Sonntag
• verwende den gleichen Zeitpunkt (23:00) nicht mehrfach
  Ich würde drei Perioden setzen und jeden Tag um 8:30Uhr, 16:00Uhr und 23:00Uhr triggern. Mo - Fr setzt du die 20° um 16:00Uhr, Sonntags um 8:30Uhr. Alle anderen Temperaturen würde ich dann auf 16° stellen.

Wenn das hilft, weiß ich zumindest, dass meine Vermutung bzgl. des Fehlers richtig ist...

[rg-engineering]

Alternativ könntest du auch nach einem reboot bzw. früh vor dem Setzen von "Gäste anwesend" zunächst "Urlaub zu Hause" deaktivieren und danach wieder aktivieren.

[daniel-finger]

• setze die Zeitperioden jeden Tag identisch, d.h. setze einen Zeitpunkt um 8:30Uhr für jeden Tag, nicht nur Sonntag

Ja, damit umgehe ich das Problem natürlich.

• verwende den gleichen Zeitpunkt (23:00) nicht mehrfach

Das werde ich direkt mal umbauen, das an verschiedenen Zeitpunkten dann die gleiche Temperatur gesetzt wird.

Ich würde drei Perioden setzen und jeden Tag um 8:30Uhr, 16:00Uhr und 23:00Uhr triggern. Mo - Fr setzt du die 20° um 16:00Uhr, Sonntags um 8:30Uhr. Alle anderen Temperaturen würde ich dann auf 16° stellen.

Ich habe 4 Perioden, da ich die Werktags für das Badezimmer benötige. Das soll morgens aufheizen für 2 Stunden, dann abschalten und erst wieder später 16:30 Uhr wieder einschalten.

Ich versuche das gerade selbst anhand des Codes und Logs nachzuvollziehen,
In der Funktion CalculateRoomTemperature wird einfach der Temp2Set = room.CurrentProfileTarget; übernommen und das eigentliche Problem ist, das am Raum das falsche CurrentProfileTarget hängt?

Es sollte ja room.State == "auto" zutreffen, jedoch auch room.HolidayPresent, was aber im Code nicht relevant ist.

Sollte es dann nicht reichen, beim umstellen des DP GuestsPresent die Neuberechung zu triggern, wenn room.HolidayPresent zutrifft?

Ich hab mal in der database.js den Code angepasst, der beim Umstellen des DP GuestPresent ausgeführt wird:

   else if (state == "GuestsPresent") {
                if (theRoom.GuestsPresent != val) {
                    parentAdapter.log.debug("Change Status GuestsPresent in " + theRoom.Name + " to " + val);
                    theRoom.GuestsPresent = val;
                    changed = true;
                    if (theRoom.HolidayPresent && theRoom.State != "starting") {
                        //Neuberechnung der Zeiten (cron) und damit Zieltemperaturen
                        const currentProfile = await GetCurrentProfile();
                        await CreateCronJobs(parentAdapter, currentProfile, ChangeStatus, Rooms);
                        
                        //aktuellen Profilpunkt setzen
                        await GetCurrentProfilePoint(theRoom, currentProfile);
                    }
                }
            }

Wobei ich mir nicht sicher bin, ob man die Neuberechnung nicht direkt in den Block
if (theRoom.State != "starting" && changed) {
schieben sollte. Dafür fehlt mir hier der Überblick (und die Gewissheit, ob das überhaupt funktioniert, das sehe ich morgen 😄)

[rg-engineering]

nicht ganz..
Das Problem m.E. ist, dass die cron-Jobs beim Neustart des Adapters nicht neu berechnet werden.
Ich habe bei mir die Zeile mit
theRoom.State != "starting"
auskommentiert. Damit stimmen zumindest nach Neustart des Adapters die Zeiten in den cron jobs.
Ich muss nur nochmal schauen, warum ich das ursprünglich so gemacht habe. Dafür gab es einen Grund...

Der Versuch, einfach mal "HolidayPresent" auf true zu setzen, nachdem der Adapter läuft, sollte eigentlich zeigen, ob die Idee richtig ist. Ich denke, damit sollte das schon laufen. Du hast jetzt genau das auf den Trigger "GuestPresent" eingebaut. Das führt zwar ebenfalls zu einer Neuberechnung der cron jobs, ist aber keine optimale Lösung, weil man das dann an vielen anderen Stellen ebenso einbauen müsste...

Wobei ich mir nicht sicher bin, ob man die Neuberechnung nicht direkt in den Block
if (theRoom.State != "starting" && changed) { schieben sollte.

Dann rechnet der Adapter ständig cron jobs und Profile aus. löscht alle und setzt sie neu ...

[daniel-finger]

nicht ganz.. Das Problem m.E. ist, dass die cron-Jobs beim Neustart des Adapters nicht neu berechnet werden. Ich habe bei mir die Zeile mit theRoom.State != "starting" auskommentiert. Damit stimmen zumindest nach Neustart des Adapters die Zeiten in den cron jobs. Ich muss nur nochmal schauen, warum ich das ursprünglich so gemacht habe. Dafür gab es einen Grund...

Also beim Start wird auf jeden Fall die Funktion CreateCronJobs ausgeführt. Da wird dann auch direkt der Callback ChangeStatus aufgerufen. Möglicherweise wolltest du da mehrfache Ansteuern der Thermostate verhindern, bis die Initialisierung vollständig ist?

Ich versuche mich mal auf das Arbeitszimmer zu konzentrieren...
Die Cron-Jobs werden erst erstellt:
Day: 0 und 16:30 und 23:00

und erst danach "checking external states" mit "HolidayPresent true",
Da wird auch der Profilpunkt richtig gefunden:

start calculate current profile point for profile type 3 (every day)
sunday profile used for holiday at home
Arbeitszimmer found profile point at Period 1 08:30 with 20

Aber die Cron-Jobs, die den currentProfile umstellen sollen, liegen auf den falschen Zeitpunkten, weil zum Zeitpunkt der Erstellung die der DP für HolidayPresent noch nicht verarbeitet wurde? Wobei das SetCurrent() genau das verhindern sollte...

Der Versuch, einfach mal "HolidayPresent" auf true zu setzen, nachdem der Adapter läuft, sollte eigentlich zeigen, ob die Idee richtig ist. Ich denke, damit sollte das schon laufen. Du hast jetzt genau das auf den Trigger "GuestPresent" eingebaut. Das führt zwar ebenfalls zu einer Neuberechnung der cron jobs, ist aber keine optimale Lösung, weil man das dann an vielen anderen Stellen ebenso einbauen müsste...

Ich werde berichten, wie sich das morgen darstellt. Mir wäre da erstmal nur PartyNow noch mit eingefallen.

Wobei ich mir nicht sicher bin, ob man die Neuberechnung nicht direkt in den Block
if (theRoom.State != "starting" && changed) { schieben sollte.

Dann rechnet der Adapter ständig cron jobs und Profile aus. löscht alle und setzt sie neu ...

Ah, und das ist ja nicht bei jeder Aktion notwendig ist, sondern nur bei einer, wo die Auswahl der Profile, verändert werden könnte. Das ist ja auch schon drin, nur die Cron-Jobs liegen auf den falschen Zeiten?

[daniel-finger]

Ich sehe gerade, das du eben einen neuen Commit gemacht hast, Ich habe soeben alles bei mir auf den GIT Stand gesetzt.
Ich habe schonmal einen Cron-Job für morgen früh:

  {
        "day": 0,
        "hour": 8,
        "minute": 30,
        "Values2Set": [
            {
                "ActiveTimeSlot": 1,
                "currentTimePeriod": 31,
                "CurrentTimePeriodFull": "Period 1 08:30",
                "CurrentTimePeriodTime": "08:30",
                "room": "Arbeitszimmer",
                "target": 20
            }
        ]
    },

Ich werde morgen berichten. Danke dir!