48_HomeConnect.pm neue Überarbeitung

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

Vorheriges Thema - Nächstes Thema

Prof. Dr. Peter Henning

Zitat von: Adimarantis am 29 Dezember 2024, 22:56:27zumindest sehe ich bei den "getSettings" Antworten keinen relevanten Unterschied.
Hmm. Kann das der überflüssige Punkt sein?

Auf jeden Fall danke für die Mühe. Ich hatte mir auch schon überlegt, die Strings zu extrahieren - bin aber bisher an akuter Lustlosigkeit gescheitert.

Zur generischen Unterscheidung: Man könnte das jetzt erstmal für type=Washer auf MainsOff lassen. Und ein neues Attribut, sagen wir mal "special_WasherOff" einführen. Defaultwert ist MainsOff, nur wenn das nicht funktioniert, setzt man das Attribut auf Off.

LG

pah




Adimarantis

Der überflüssige "." macht wirklich nichts (weil nicht verwendet) aber das verschwindet sowieso:

Aktuell warte ich jetzt mal damit eine neue Version einzuchecken, weil ich jetzt die ganze options/settings Speicherung und Logik auf hash umgestellt und überarbeitet habe. Dabei räume ich den Code auch ein wenig auf und entferne einige Sonderfälle und "toten" Code.
Leider ist nicht ausgeschlossen, dass dabei was auf der Strecke geblieben ist, daher lasse ich das jetzt erstmal eine Weile bei mir laufen. Grundsätzlich ist es etwas generischer geworden, so dass ich hoffe das eher mehr als weniger geht - aber wie wir wissen ist die API ja leider nicht immer konsistent.

Desweiteren habe ich die startup Logik noch etwas robuster gemacht und weitere kleine Verbesserung an der Ablaufslogik vorgenommen.

Um sicherzustellen, dass ich keine Geräte "kaputt gemacht" habe, die ich nicht zuhause habe, wäre es hilfreich mit der aktuellen Version auf Github (zur Erinnerung: https://github.com/bublath/FHEM-HomeConnect ) das logfile für alle verfügbaren Geräte zu aktivieren, und dann komplett von vorne (shutdown restart) bei eingeschalteten Geräten mitzuprotokollieren, dann ein paar typische Aktionen zu machen und das Gerät einfach mal laufen zu lassen.

Danke schon mal im voraus für die Logfiles.

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

Zitat von: Adimarantis am 31 Dezember 2024, 13:11:04macht wirklich nichts (weil nicht verwendet)
Na ja, nicht in der Verwendung - aber als Kennzeichen dafür, dass MainsOff verwendet werden soll. Irgendwoher muss das ja auch die App wissen.
Eine solche Verbiegung würde ich den HC-Leuten ohne Weiteres zutrauen.

Könnte man aber nur herausfinden, wenn man ein Gerät testet, dass a.) ebenfalls nur ausgeschaltet und b.) mit einfachem Off bedient werden muss.

Logfiles werde ich produzieren, dauert aber ein paar Tage.

LG

pah

Adimarantis

Ich habe noch ein bisschen App Source Code durchforstet und einige Events, Kommandos etc. gefunden die nicht dokumentiert sind.
Versuche irgendwas davon abzusetzen mündeten immer in einer Fehlermeldung.

Zufällig hab ich beim Googlen in dem Forum von Home Assistant den Hinweis gefunden, das wohl die Developer API die wir verwenden eine alte/abgespekte Version der API ist - anders als die von der APP verwendet wird.
Das erklärt warum ich gewisse Events nicht bekomme (z.B. Flusenfilter voll vom Trockner), manche Optionen sehe oder nicht setzen kann (z.B. halbe Beladung beim Trockner) und einiges inkonsistent ist.
Die lassen uns einfach mit einer "Beta" im Regen stehen während die "echte" API fleissig weiterentwickelt wurde.

Update von der Programmierfront: Funktioniert eigentlich nach dem Refactoring der Options/Setting alles wieder recht gut. Wollte jetzt mal die offizielle Simulation anhängen, aber wenn ich mein FHEM da dranhängen will kommt ein "internal error" von der API. Hab mal ein Support Ticket aufgemacht.
Sofern ich das mit der Simulation nicht hinbekomme, werde ich mein Update in 1-2 Tagen mal einchecken - sonst würde ich da erstmal virtuell noch andere Geräte durchtesten.
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

Es ist schon klar, dass die uns eine alte Version anbieten. Die Frage ist, ob das bei den "offiziell unterstützten" Systemen wie IO Broker auch so ist.

Das mit der Simulation habe ich ebenfalls nicht zum Laufen bekommen und irgendwann einfach aufgesteckt.

In meinem Sourcecode findest Du noch ein paar Überbleibsel meines originalen Plans. Nämlich ein Modul zu schreiben, das ähnlich wie die App alle Optionen als echte Buttons zur Verfügung stellt. Ich habe solche interaktiven Oberflächen schon für mehrere Module gebaut, z.B. YAAHM, Alarm und Babble. Immerhin hatte es schon funktioniert, dass nach einem get ProgramOptions diese Options als Buttons in der Detailübersicht eingeblendet wurden.

Erfordert allerdings Etliches an JavaScript.

LG

pah

Adimarantis

pihole indentifiziert dass Domains wie
prod.reu.rest.homeconnectegw.com
reu.sdws.homeconnectegw.com
media3.bsh-group.com
pki-ca.home-connect.com
von der App verwendet werden.

Was ich so lese verwendet auch ioBroker das development Interface und weist darauf hin dass nicht der volle Funktionsumfang der App zur Verfügung steht (gleich mit Link auf https://developer.home-connect.com/support/contact wo man requests absetzen kann - also lasst uns die Freunde mit Requests überschütten, wenn was fehlt)

Wenn man sich die Bedingungen für die Veröffentlichung so ansieht, dann ist es auch schlicht unmöglich, dass eine Heimintegration es schafft eine offizielle App zu werden.
Fängt damit an, dass man JEDE Fehlermeldung von der API dem Anwender zeigen muss bis hin zur Geheimhaltung von Tokens, Secrets etc. was in einer Scriptsprache nie 100% geht.

Die Ansätze zur Generierung von HTML habe ich gesehen - und komplett rausgeworfen.
Hatte auch schon überlegt, hier mehr Oberfäche (oder zumindest "get" Funktionen mit Übersichten) zur Verfügung zu stellen, aber ich habe ehrlich gesagt meine Zweifel ob das jemand verwenden würde.
Die Integration ist für Automatisierung - da verwendet man die FHEM Oberfläche zum Ausprobieren bis alles läuft - und da reicht die Standardoberfläche.
Wenn's erstmal läuft dann macht alles DOIF und Co und die Visualisierung läuft z.B. über FTUI (siehe Bild).
Du darfst diesen Dateianhang nicht ansehen.
Wenn es Bedarf für mehr gibt, kann man das natürlich diskutieren.


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 die Simulationsumgebung nach wie vor nicht geht und ich nicht mehr weiss was ich noch selber testen soll/kann, checke ich jetzt das aktuelle Update ein.
Bitte dran denken 48_HomeConnect.pm und 48_HomeConnectConnection.pm einzuspielen. Quelle: https://github.com/bublath/FHEM-HomeConnect
Die kleine Änderung in HomeConnectConnection ist rückwärtskompatibel, kann man also stehen lassen.
Da sich sehr viel geändert hat, bitte möglichst so vorgehen:
1. Dateien austauschen
2. Alle Readings löschen. Nicht zwingend notwendig macht es aber Übersichtlicher da sich viele Namen geändert haben, z.B, mit
deletereading TYPE=HomeConnect .*   
3. save config & shutdown restart
4. In allen devices das Attribut FileLog setzen
5. Ggf Automatisierungen (DOIF etc.) an die neuen Readings und Kommandos anpassen oder DOIF disablen
6. Alle Geräte einschalten (da viele im Power Off Zustand keine oder eingeschränkte Infos liefern)
7. save config & shutdown restart
   Damit der ganze Start Prozess mit dem Logfile protokolliert wird
8. Alles mögliche ausprobieren, mal manuell ein Programm laufen lassen oder aus FHEM - damit schön viel Infos im Logfile landen
9. Logfile posten - keine Angst, das Logfile sollte keine persönlichen Daten beinhalten. Die HaId wird automatisch entfernt

Änderungen (seit dem letzten Update vom 29.12):
- Einige Übersetzungen/Default korrigiert
- neues Attribut "excludeSettings" - wird automatisiert befüllt wenn Settings/Commands auf Fehler laufen um die Listen individuell zu kürzen. Kann aber auch manuell editiert werden
- neues Attribut "extraOptions" - eher zum Test - damit habe ich versucht ob gewisse Optionen deren Strings ich aus der App extrahiert habe nicht doch funktionieren. Gefunden habe ich aber bislang keine
- neues Command "anyRequest" - rein zum Test - damit habe ich versucht versteckte Kommandos zu finden. Das Textfeld wird als request ohne weiteren Inhalt an die API gesendet (als api/homeappliances/<HaId>/<textfeld>) - bisher kam da aber immer "The requested resource could not be found." zurück.
- Startup: type, prefix und programs werden zusätzlich in einem hidden reading gespeichert (und somit beim "save" abgespeichert). Das hilft um Fehler beim Neustart zu vermeiden, da manche Devices im ausgeschalteten Zustand keine Daten liefern
- Startup: Verschiedene weitere Optimierungen im Ablauf- und Fehlerverhalten
- Refaktoring: Namen der Unterroutinen weitgehend in der Gross/Kleinschreibung vereinheitlich
- Refaktoring: Unnötigen Code entfernt
- Refaktoring: options und settings von Array auf Hash umgestellt. Dadurch sieht man im "list" besser was es wirklich gibt und was die Felder bedeuten und die Routinen die mit options/settings arbeiten können besser Bedingungen prüfen.
- Refaktoring: einige internal readings nach $hash->{helper} verschoben um die Liste klein zu halten
- "set commands": Bedingungen wann Kommandos ausgeblendet werden teilweise korrigiert
- Umbenennung der "Root." Reading: Nachdem das ja schon als störend erwähnt wurde und der volle Pfad der "Root." Readings nirgends benötigt wird, habe ich diese jetzt auf "Setting." umbenannt (Setting.SelectedProgram, Setting.ActiveProgram) - das verwirrt hoffentlich weniger als das völlig aus der Reihe tanzenden "Root."
- DelayedStart: Im FinishInRelative Fall hatte ich das Problem, dass dieses Reading sowohl automatisch befüllt wurde, als auch der Trigger für einen DelayedStart war. Das führte teilweise zu seltsamen Ergebnissen. Die DelayedStart Logik setzt jetzt explizit ein Flag und überträgt StartInRelative or FinishInRelative beim StartProgram nur, wenn vorher per Kommando ein DelayedStart vom Anwender angefordert wurde.
- Dokumentation: Die Inline Dokumentation wurde weitgehend an die Änderungen angepasst (bis auf temporäre Testoptionen)

Ungetestet:
- Wenn ein Event mit "Finished" im Namen erhalten wird, und der operationState "Run" ist, wird dieser auf "Finished" gesetzt, da der Trockner im "WrinkleGuard" noch "Run" bleibt
- Alarms: Events die meiner Ansicht nach Alarme sind (also sowas wie "Salz nachfüllen") werden in dem Reading "alarms" aufgelistet solange sie aktiv sind und in "alarmCount" steht wieviele das sind. Will ich nutzen um in FTUI ein Badge (rote Zahl) anzuzeigen als Hinweis, das da was zu tun ist. Nachdem ich aber seit Implemtierung noch keine Alarm hatte, die Simulationsumgebung von BSH nicht mit mir redet und es nicht ganz so einfach selbst zu simulieren ist, kann das noch Fehler enthalten

Happy Testing & Happy New Year,
Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU)/RfxTrx433XL/Zigbee
Module: 50_Signalbot, 48_HomeConnect, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Adimarantis

Und nachmal ein paar Updates:

- neues Attribut: "extraInfo" - wenn auf 1 gesetzt werden zusätzliche "Option"-Readings erzeugt, die Dinge wie Water/EnergyForecast, LoadRecommendation sowie die aktuelle Einstellung von Optionen die nur am Gerät eingestellt werden können (Beschränkung der Developer API - vielleicht kann man die zukünftig auch mal setzen)
- Konsistentere Verwendung von Boolean Values: statt on/off , On/Off und 0/1 wird jetzt überall On/Off verwendet - ich hoffe das passt für alle Booleans...
- weitere Unstimmigkeiten in den komplexeren Abläufen verbessert (z.B. wenn ein DelayedStart nachträglich verändert wird)
- Fehler bei alarmCount und Finished state flow behoben
- Code weiter aufgeräumt
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU)/RfxTrx433XL/Zigbee
Module: 50_Signalbot, 48_HomeConnect, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

isy

#38
Moin Jörg,
ich habe jetzt auch deine Version eingespielt, nur gestartet und Readings erneuert. Ich habe noch kein Programm etc. gestartet.
Soweit keine FM.

Mir fällt auf:
- Das Logfile liegt im /opt/fhem/ Verzeichnis, der Hyperlink im Log-Device zeigt auf /opt/fhem/log
- Im FHEM Log stehen Meldungen:
2025.01.05 09:25:09 1: [HomeConnect_ResponseInit] SN63E800BE: defined as HomeConnect Dishwasher Siemens SN63E800BE
2025.01.05 09:25:13 1: [HomeConnect_ResponseGetPrograms] EX977NVV6E: no programs found

Es gibt noch die Anzeige im Device:
BSH.Common.Root.SelectedProgramDas kommt womöglich von der alten HC Version. Der dahinterliegende Link führt zur FM.

Ich habe das Device gelöscht und neu angelegt.
Im FHEM Log dann diese Info
2025.01.05 09:52:26 1: [HomeConnect_define] called
2025.01.05 09:52:40 1: PERL WARNING: Use of uninitialized value $type in pattern match (m//) at ./FHEM/48_HomeConnect.pm line 1027.
2025.01.05 09:53:26 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/48_HomeConnect.pm line 2515.
2025.01.05 09:54:51 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/48_HomeConnect.pm line 1676.

Das neue Device bleibt im Status mit den drei Fragezeichen, auch nach  dem Einschalten.
Logfile unten, List vom Device ebenso. Die "S" am Anfang der Zeilen bei den Reading fehlen wirklich!

Viele Grüße, Helmut


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

Adimarantis

Deswegen braucht man Tester - den "define from scratch" Fall hatte ich noch nie probiert.
Die "use of uninitialized" verstehe ich - da müssen ein paar Tests rein, um festzustellen, dass das Device noch nicht initialisiert ist.
Warum die Intialisierung dann nicht automatisch läuft muss ich mir ansehen.
Habs kurz nachgestellt und nach einem
set <device> init in der Kommandozeile solltest du einen Schritt weiterkommen.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU)/RfxTrx433XL/Zigbee
Module: 50_Signalbot, 48_HomeConnect, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

isy

Das ging ja flott! Schön, dass die Entwicklung des Moduls weitergeht.

Ein Init zeigt im Web keine Änderungen, hier FHEM Log:
2025.01.05 10:12:45 1: [HomeConnect_Set] init called
2025.01.05 10:12:56 1: [HomeConnect_Init] for EX977NVV6E called
2025.01.05 10:12:56 1: [HomeConnect_ResponseInit] EX977NVV6E: defined as HomeConnect Hob Siemens EX977NVV6E
Ein Weg wird erst zu einem Weg, wenn man ihn geht

Adimarantis

Hmm.
Ist dein Gerät eingeschaltet? Bei manchen Geräten kriegt man sonst keine/kaum Infos.
Zumindest sollten jetzt mehr internal readings da sein. (wichtig ist "type" und "prefix")
Spiel man mit den "get" Optionen (Settings, Programs, Status) ob das was bringt.
Steht schon was im extra Logfile?
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU)/RfxTrx433XL/Zigbee
Module: 50_Signalbot, 48_HomeConnect, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

isy

Ja, das Kochfeld ist eingeschaltet.
Es gibt keine neuen Readings, auch ein get..... bringt keine sichtbaren Änderungen
Ein neues Logfile habe ich angefügt.

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

isy

Nach erneutem Einschalten werden jetzt Readings angezeigt!
Sehr schön!

Man sollte wohl die alten Devices besser löschen.
Ich werde das mal probieren oder soll ich abwarten, dass der Autocreate besser durchläuft?
Ein Weg wird erst zu einem Weg, wenn man ihn geht

Adimarantis

Das define Problem hab ich jetzt (hoffentlich) gefunden und gefixed. Ist bereits in Github eingecheckt.

Kannst schon hier weitermachen, aber besser noch wenn du die neue Version nochmal ganz vom Start testest.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU)/RfxTrx433XL/Zigbee
Module: 50_Signalbot, 48_HomeConnect, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)