Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
daniel-finger opened this issue Dec 4, 2023 · 15 comments
Open

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

daniel-finger opened this issue Dec 4, 2023 · 15 comments
Assignees
@rg-engineering
Labels
bug Something isn't working
Milestone
V2.13 Release

Comments

@daniel-finger
Copy link

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:
Profile_Arbeitszimmer
und die Einstellungen für den Raum:
Room_Arbeitszimmer
Nach dem Neustart wird das folgende angezeigt:
Room_Arbeitszimmer-restart

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 rg-engineering self-assigned this Feb 10, 2024
@rg-engineering rg-engineering added the bug Something isn't working label Feb 10, 2024
@rg-engineering
Copy link
Owner

@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
Copy link
Author

@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
Copy link
Author

daniel-finger commented Feb 13, 2024 •
edited
Loading

@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
Copy link
Owner

@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
Copy link
Owner

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
Copy link
Author

  • 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
Copy link
Owner

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 ...

rg-engineering added a commit that referenced this issue Feb 25, 2024
@rg-engineering
issue #492: cron jobs recalculation is necessary after reboot when Va…
36cbc39 
…cationAtHome and PublicHoliday is active
@daniel-finger
Copy link
Author

daniel-finger commented Feb 25, 2024 •
edited
Loading

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
Copy link
Author

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!

@daniel-finger
Copy link
Author

Läuft einwandfrei!

@rg-engineering
Copy link
Owner

rg-engineering commented Feb 26, 2024 •
edited
Loading

bei mir nicht ganz.
Die Anzeige der aktuellen Periode ("CurrentTimePeriod") stimmt immer noch nicht:

grafik

grafik

sollte eigentlich 25 sein... Uhrzeit und Temperatur sind richtig...

@daniel-finger
Copy link
Author

Jetzt wo du es sagst: Ich hatte in meiner "Funktioniert" Meldung nur auf die Temperatur direkt auf dem Gerät geachtet.

@rg-engineering
Copy link
Owner

@daniel-finger habe jetzt auch für diese Problem ein kleines bug fix hier im github...

@daniel-finger
Copy link
Author

Ich habe heute auch noch mal drauf geschaut während "die Gäste anwesend" waren. Sieht alles sehr gut aus.
Danke dir!

@rg-engineering
Copy link
Owner

dann release ich diese Version am Wochenende und wir können das Ticket hier schliessen

rg-engineering added a commit that referenced this issue Mar 1, 2024
@rg-engineering
chore: release v2.12.5
f859876 
* (René) see issue #492: cron jobs recalculation is necessary after reboot if VacationAtHome and PublicHoliday is active
* (René) create cron job for PowerInterruption only if feature is active
* (René) bug fix: with cron 3.x status log of cron jobs were wrong
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@rg-engineering rg-engineering

Labels
bug Something isn't working
Projects
None yet
Milestone
V2.13 Release
Development

No branches or pull requests
2 participants
@rg-engineering @daniel-finger