48_HomeConnect.pm neue Überarbeitung

Begonnen von Adimarantis, 24 Dezember 2024, 00:02:52

Vorheriges Thema - Nächstes Thema

Adimarantis

Einige Readings bleiben ja nach Programmende/Ausschalten mit teilweise verwirrenden Werten belegt.
Teilweise lösche ich die schon (z.B. ActiveProgram). Ich würde jetzt in die Config pro Device eine Liste von Readings einbauen, die gelöscht werden sollen, sowie allgemeine Readings generell löschen (= "" Leeerstring) wenn kein Program aktiv ist (=Active,Run,Pause,DelayedStart) oder bei Power Off.
Allgemein: "FinishAtHHMM", "ProcessPhase", "RemainingProgramTime", "RemainingProgamTimeHHMM", "ProgramProgress", "ActiveProgram", "StartAtHHMM", "StartInRelativeHHMM", "StartInRelative", "ElapsedProgramTime"
Dishwasher: "Option.BaseProgram", "Option.ProgramName" (wird nur bei aktivem Favoriten befüllt)
Oven: "Status.CurrentCavityTemperature" (weil bekanntermaßen unsinnige Werte, wenn kein Programm aktiv)

Bedenken? Weitere Readings?
Ich hatte außerdem überlegt das Reading "Event.ProgramAborted" bei PowerOn zu löschen - das bleibt bei mir ewig (mit Wert "Present") stehen.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU)/RfxTrx433XL/Zigbee
Module: 50_Signalbot, 48_HomeConnect, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Shadow3561

Beim GS bleiben
     Option.EnergyForecast 46 %
     Option.ExtraDry Off
     Option.FinishAtHHMM 16:38
     Option.FinishInRelativeHHMM 4:12
     Option.RemainingProgramTime 15120 seconds
     Option.RemainingProgramTimeHHMM 4:12


und beim Kochfeld
     Option.ElapsedProgramTime 16609 seconds
     Option.RemainingProgramTime 10 seconds


befüllt.

Waschtrockner kann ich nicht testen, der läuft gerade.
Mit freundlichen Grüßen

Adimarantis

Ich hätte jetzt Werte die bei potentiell gewähltem Program Sinn machen könnten stehengelassen.
Dazu gehören auch relative Laufzeiten (FinishInRelative*, Estimated*), Forecasts und On/Off Options. Mir geht es um Readings die definitiv falsch sind und durch die ganzen "get" Befehle auch nicht korrigiert werden.

Apropos Forecast. Irgendwo kam schon mal die Diskussion über die sinnfreien Prozentangaben auf.
Die App zeigt ja kWh und Liter.
Könnte man das nicht ausrechnen?
z.B. zeigt die App für das Spülmaschinenprogramm "Auto 45-65" 1.4 kWh und 15.0 l - in Prozent in FHEM 65% und 67%
Das würde heissen das 100% Energie = 2.15 kWh und 100% Wasser = 22.39 l sind.
Wenn ich das allerdings über mehrere Programme prüfe, dann bekomme ich eine Schwankungsbreite von 19,2-24,5 kWh und 21-30 Liter
Das erscheint mir doch etwas zuviel Abweichnung für reine Rundungsfehler (kWh scheinen immer auf 0.1 und Liter immer auf 0.5 gerundet zu sein)


Raspberry 4 + HM-MOD-RPI-PCB (pivCCU)/RfxTrx433XL/Zigbee
Module: 50_Signalbot, 48_HomeConnect, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Shadow3561

Ich habe mal die forecast Angaben bei mir verglichen.
Das stimmt hinten und vorne nicht.
Programm Auto 45-65 Energy 70% Wasser 69%
entspricht App.            1.25kwh.   10.5l
       
Mischbeladung.       Energy 70& Wasser 65%
                              1.45kwh    14.5l

Hier sieht man sehr schön, dass man das nicht in Relation setzen kann.
Ich denke Prozentangaben beziehen sich eher auf die abgebildete Grafik im GS-Display und haben relativ wenig mit den Verbräuche zu tun. Die kWh und Liter rechnet die App entweder selber aus, je nach Programm oder sie werden von der API geliefert die BSH für die App benutzt.
Mit freundlichen Grüßen

         

Prof. Dr. Peter Henning

Ich denke, es braucht für jedes Gerät eine Liste von readings, die beim Programmende zwar nicht gelöscht, aber auf einen neutralen Wert gesetzt werden.

LG

pah

Adimarantis

Zitat von: Prof. Dr. Peter Henning am 20 Januar 2025, 10:11:29Ich denke, es braucht für jedes Gerät eine Liste von readings, die beim Programmende zwar nicht gelöscht, aber auf einen neutralen Wert gesetzt werden.
Genau. Da habe ich in meiner Testversion jetzt eine Doppelstrategie:
Die Liste von Readings die ich im vorherigen Post als "allgemein" gekennzeichnet habe, setze ich generell auf Leerstring (natürlich nur wenn es das Readings bereits gibt), und dann gibt es noch eine devicespezifische Liste in der HomeConnectConf.pm . Dafür bräuchte ich noch Vorschläge.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU)/RfxTrx433XL/Zigbee
Module: 50_Signalbot, 48_HomeConnect, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Adimarantis

Nachdem das jetzt bei mir ohne ersichtliche Nebeneffekte lief, ein kleines Update
- Verbesserte Erkennung von device offline beim FHEM Neustart / init
- Einige Readings werden nach auf Leerstring gesetzt, wenn ein Programm beendet wurde - bitte um Feedback für weitere Readings
- Hat schon jemand das die Berechnung von ElapsedProgramTime/RemainingProgamTime getested (betriff wohl hauptsächlich Öfen)?

Das versteckte "StartX" wurde geändert, dass es ein ResumeProgram schickt. Wollte ich ausprobieren, bin aber noch nicht zu gekommen.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU)/RfxTrx433XL/Zigbee
Module: 50_Signalbot, 48_HomeConnect, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Prof. Dr. Peter Henning

Testbericht:
Bei Systeminitialisierung
Zitat2025.01.21 09:55:30 1: [HomeConnect_Init] for PXX895D57E called
2025.01.21 09:55:33 1: [HomeConnect_Init] for WAV28G43 called
2025.01.21 09:55:35 1: [HomeConnect_Init] for HBG4785B6 called
2025.01.21 09:55:36 1: [HomeConnect_Init] for SN55ZS49CE called
2025.01.21 09:55:39 1: [HomeConnect_ResponseGetPrograms] PXX895D57E: no programs found
2025.01.21 09:59:29 1: PERL WARNING: Argument "" isn't numeric in int at /opt/fhem/FHEM/48_HomeConnect.pm line 1828.
2025.01.21 09:59:29 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at /opt/fhem/FHEM/48_HomeConnect.pm line 1829.

Standardprogramm "Nudelauflauf" beim Ofen (Start erfolgt automatisch nach dem Einstellen des Gewichtes 1.25 kg am Backofen)

1. Anzeige Temperatur und Restlaufzeit funktionieren prima.

2. Ein Stopp per "set ... Power standby" geht auch.
Während das Programm gestoppt ist, kann man zwar in FHEM "set ... Weight" eingeben, der Wert wird aber nicht übernommen. Stattdessen wird der Ofen wieder auf den Defaultwert 1 kg zurückgesetzt.
Zitat2025.01.21 10:03:28 1: [HomeConnect_HandleError] HBG4785B6: Error "HomeAppliance reported an error"
2025.01.21 10:03:51 1: PERL WARNING: Use of uninitialized value $values in pattern match (m//) at /opt/fhem/FHEM/48_HomeConnect.pm line 821.
2025.01.21 10:03:51 1: [HomeConnect_HandleError] HBG4785B6: Error "Program option not supported"

3. Ein Neustart mit "set ... StartX" geht nicht, keine Reaktion. Dafür Fehlermeldung im FHEM-Log
Zitat2025.01.21 10:04:55 1: PERL WARNING: Use of uninitialized value $program in concatenation (.) or string at /opt/fhem/FHEM/48_HomeConnect.pm line 1177.
2025.01.21 10:04:55 1: PERL WARNING: Use of uninitialized value $program in concatenation (.) or string at /opt/fhem/FHEM/48_HomeConnect.pm line 1182.
2025.01.21 10:04:55 1: [HomeConnect_HandleError] HBG4785B6: Error "Unknown program feature key: "

4. Neustart mit der App geht problemlos, auch die Veränderung des Gewichts auf 1,5 kg.

Anbei noch das Log.

LG

pah

Adimarantis

Zitat von: Prof. Dr. Peter Henning am 21 Januar 2025, 10:31:582025.01.21 09:59:29 1: PERL WARNING: Argument "" isn't numeric in int at /opt/fhem/FHEM/48_HomeConnect.pm line 1828.
2025.01.21 09:59:29 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at /opt/fhem/FHEM/48_HomeConnect.pm line 1829.
Ok. Nebeneffekt vom auf Leerstring setzen. Sollte gefixt sein, aber unkritisch.
ZitatWährend das Programm gestoppt ist, kann man zwar in FHEM "set ... Weight" eingeben, der Wert wird aber nicht übernommen. Stattdessen wird der Ofen wieder auf den Defaultwert 1 kg zurückgesetzt.
Set Weight wird als "Unsupported Option" bemängelt - landet das dann in der Excludeliste und wird zukünftig nicht mehr angeboten?
Ich vermute stark, dass durch das Standby das Gewicht zurückgesetzt wird. FHEM macht hier nichts.
Zitat2025.01.21 10:03:51 1: PERL WARNING: Use of uninitialized value $values in pattern match (m//) at /opt/fhem/FHEM/48_HomeConnect.pm line 821.

Sollte gefixt sein.
Zitat3. Ein Neustart mit "set ... StartX" geht nicht, keine Reaktion. Dafür Fehlermeldung im FHEM-Log
Diese "Spieloption" hat in deiner Version noch eine andere Bedeutung und benötigt einen Programmnamen. Aber egal:
Ich hab jetzt in der gerade eingecheckten Version 1.20 die Befehle PauseProgram und ResumeProgram für den Ofen freigeschaltet. Laut Doku könnte das gehen - das ist dann evtl. "schonender" als auf Standby gehen.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU)/RfxTrx433XL/Zigbee
Module: 50_Signalbot, 48_HomeConnect, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Prof. Dr. Peter Henning

Wir tasten uns langsam voran.

- PauseProgram macht gar nichts
- StopProgram stoppt das Programm, geht also
- ResumeProgram wird nicht in der Liste der Befehle angezeigt. Wenn ich es trotzdem absetze, passiert nichts.

LG

pah

Adimarantis

Zitat von: Prof. Dr. Peter Henning am 21 Januar 2025, 13:01:02- PauseProgram macht gar nichts
Scheinbar von deinem Modell nicht supported
Zitat- StopProgram stoppt das Programm, geht also
- ResumeProgram wird nicht in der Liste der Befehle angezeigt. Wenn ich es trotzdem absetze, passiert nichts.
Resume wird nur im Status "Paused" angezeigt - außerdem auch von deinem Modell nicht unterstützt. Und Stop beendet ja das Programm, wobei das Start aus bekannten Gründen nicht geht. Somit ist "Resume" leider auch kein Workaround.

Sind wir wieder beim BSH support - der mir auf insgesamt 5 Anfragen bisher nur einmal geantwortet hat.....
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU)/RfxTrx433XL/Zigbee
Module: 50_Signalbot, 48_HomeConnect, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

isy

#191
Zitat von: Adimarantis am 21 Januar 2025, 08:53:54v
- Hat schon jemand das die Berechnung von ElapsedProgramTime/RemainingProgamTime getested (betriff wohl hauptsächlich Öfen)?

Habe ich heute mal getestet.
Reading nag get status:
    2025-01-21 13:02:05  Option.ElapsedProgramTime 299 seconds
    2025-01-21 13:02:05  Option.RemainingProgramTime 901 seconds
Ofen abgelesen am Display um 13.01:50, also 15 Sekunden eher. Ich müsste das mal besser synchen, bloß wie?
- Abgelaufene Zeit 13:17 (ca 797 Sekunden)
- Restlaufzeit 15:01 (ca 901 Sekunden)

Selbst mit Berücksichtigung der Unschärfe beim Ablesen passen die Zeiten bei mir nicht.

NACHTRAG:
Oder geht es um diese beiden Felder?
    2025-01-21 12:57:59  Status.Cavity.001.ElapsedProgramTime 58 seconds
    2025-01-21 12:57:59  Status.Cavity.001.RemainingProgramTime 1142 seconds

VG Helmut

P.S. Kein Log aktiv.
Ein Weg wird erst zu einem Weg, wenn man ihn geht

Prof. Dr. Peter Henning

Hmm...

Das mit den Updates der Zeiten ist in der Tat nicht schön. Man könnte aber ein Konstrukt schaffen, bei dem ein interner Timer in FHEM abläuft, der durch die BSH-Server lediglich von Zeit zu Zeit "mitgenommen" wird. Und das ginge sogar ohne Belastung für die FHEM-Hauptschleife, wenn man ein wenig Javascript verwendet.

Das wäre mal ein innovatives Widget, das man an ganz vielen anderen Stellen in FHEM ebenfalls verwenden könnte.

Für die Module Astro und YAAHM habe ich so etwas schon gemacht, ich werde mal darüber nachdenken.

LG

pah

Adimarantis

Ok, also die Idee war, das dies ohne get ProgramStatus funktioniert.
Ohne Logs weiss ich jetzt natürlich auch nicht was per Event kam und was intern berechnet wurde.
ElapsedProgamTime schaut auf jeden Fall seltsam aus. Meine Waschmaschine zählt nur "Remaining" und da fehlt die "Elapsed" ganz - da muss ich noch nachbessern.

Eine Abweichung von bis zu 2 Minuten bei interner Berechnung ist möglich, da die Notwendigkeit einer Berechnung aktuell nicht öfter geprüft wird. Vielleicht gehe ich da auf 70s weil die Events von HomeConnect üblicherweise so alle Minute kommen.
Irgendwelche zusätzlichen Timer einzubauen habe ich bisher nicht für notwendig gesehen, da der Event Channel sowieso schon alle 5 Sekunden abgefragt wird.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU)/RfxTrx433XL/Zigbee
Module: 50_Signalbot, 48_HomeConnect, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

isy

Ein Weg wird erst zu einem Weg, wenn man ihn geht