48_HomeConnect.pm neue Überarbeitung

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

Vorheriges Thema - Nächstes Thema

Adimarantis

Hallo Zusammen,

Nachdem das schon seit Jahren nicht mehr gepflegte Modul viele Unzulänglichkeiten hat, hatte ich mir die Überarbeitung von pah ("ergonomische Version") installiert und angefangen einige Verbesserungen vorzunehmen.

Ich hatte ein wenig Zeit und Motivation und es wurde ein komplette Überarbeitung draus - die sicherlich noch nicht abgeschlossen ist.

Das ist neu/anders:
- Die überlangen Readingnamen und Werte können jetzt getrennt über zwei Attribute optional gekürzt werden (namePrefix und valuePrefix) - default sollte das Verhalten vom Original sein
- Bei den Werten wird komplett gekürzt, bei den Readings lasse ich aber die Gruppierung vor dem letzen Punkt stehen - also Option.xxxx oder Status.xxxx - damit man zum einen die Events besser filtern kann, zum anderen aber auch um zu verhindern, dass es durch die Kürzung uneindeutig wird
- neue Zeitfunktion "delayFinishAt hh:mm" gibt eine Uhrzeit an, an der das Gerät fertig sein soll, wobei hh:mm in den nächsten 24h liegt - damit möchte ich meine Spülmaschine dann so starten, dass sie in der früh fertig und noch "heiss" ist, so dass nach dem Öffnen alles schneller abtrocknet. Noch nicht im Detail getestet
- neue Funktionen pauseProgram und resumeProgram - getested mit einem aktuellen Wäschetrockner
- Neue readings "state1" und "state2" - diese sind dazu gedacht um einen zweizeiligen Status in FTUI anzuzeigen und beinhalten Informationen über Restzeit, aktuelles Program etc. und werden per default auf Deutsch übersetzt. Lässt sich mit translate=0 unterbinden
- Zeitverzögerung von 60s beim Start von FHEM bevor Werte abgefragt werden, da ich zumindest das Problem hatte, dass obwohl die HomeConnect Verbindung stand, die Abfrage von Settings etc. noch nicht möglich war
- Überhaupt wurden viele Race Conditions behoben, Fehler besser behandelt und eben der ganze Code umgestaltet

Mit meinen 3 Geräten schaut es soweit schon ganz gut aus, wobei ich noch nicht alles getestet habe (einen Trockner startet mal problemlos auch mal leer um was zu testen, bei Waschmaschine und Spülmaschine muss ich da immer abpassen wenn es tatsächlich was zu tun gibt :) )
Grundsätzlich war das Modul ja recht generisch aufgebaut und andere Geräte sollten zumindest soweit funktionieren, dass es zur Anzeige des Status reicht. Welche Optionen dann per FHEM gesetzt werden müssen und welche Aktionen gebraucht werden, wäre dann zu diskutieren.
Ich gehe eher davon aus, dass man alles am Gerät einstellt (nachdem man es beladen hat) und den Fernstart dann nur aktiviert, damit FHEM Optimierungen, insbesondere für den Stromverbrauch (Solar, variable Strompreise), vornehmen kann.

Mein Ziel ist es erstmal, das ganze für meine Anwendungsfälle stabil zu bekommen, wenn aber jemand mittesten/mitmachen will, ist gerne willkommen.
Um das einfacher zu gestalten habe ich einen fork auf Github gemacht und dort meine Version eingecheckt:
https://github.com/bublath/FHEM-HomeConnect

Das "Connection" Modul ist da auch dabei, aber das habe ich bisher nicht anfassen müssen.

Todo:
- Dokumentation
- Settings von Geräten unterstützen (z.B. Schleuderzahl, Trockengrad, Leisemodus.....)
- Testen, testen, testen

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)

Prof. Dr. Peter Henning

Hmm. Ich hätte es besser gefunden, wenn wir uns dazu im Vorfeld mal austauschen und ein Ziel setzen. Aber gut, zum Modul:

1. Bei der Waschmaschine wird state=idle und state1=Bereit angezeigt, obwohl Status.OperationState=Offline ist.
Bei den Programmen wird zur Auswahl angeboten     
"Super153045Super1530", als SelectedProgram dann aber nur "Super1530" angezeigt.
Die Anzeige des gewählten Programms erfolgt doppelt als "Root.SelectedProgram" und "Status.SelectedProgram"

2. Beim Backofen sind ebenfalls überflüssige halbe Präfixe "Root" enthalten. Sollten entweder entfallen, oder durch "Status" ersetzt werden.
Root.ActiveProgram
Root.SelectedProgram
Bei der Temperaturanzeige für den Backofen gibt es einen Encoding-Fehler, die Anzeige lautet z.B. "71 °C"
Wieso hat den state2 den Wert 0:00, wenn der Kurzzeitwecker noch 10 Minuten läuft?

3. Beim Kochfeld taucht noch ein Reading mit halbem Präfix "Root" auf: Root.ActiveProgram, ist aber leer. Stattdessen wird ein Fehler angezeigt
lastErr = No programs found, wenn das Kochfeld ausgeschaltet ist und
lastErr = No programs selected or active, wenn es eingeschaltet ist, aber nicht warm ist.
Beides sind aber eigentlich keine Fehler.
Wenn das Kochfeld benutzt wird, gibt es noch das Reading Root.SelectedProgram, aber ebenfalls mit dem halben Präfix "Root". Der könnte noch weg, oder durch "Status" ersetzt werden.

4. Bei der Spülmaschine hat das Reading state den Wert off, obwohl die Kiste läuft. Ein Reading Status.OperationState fehlt ebenso Status.DoorState, state1 und state2 sind leer.
Ein Reading mit dem Namen "percent" halte ich für einen Fehler - "Prozent" ist die Einheit, aber von welcher Größe? FHEM-Standard ist "Name Zahl Einheit". 

Allgemein ist ziemlich unklar, was "state2" beinhalten soll.
Ich hatte aus dem Grund die "übersetzten" Status tr_State1...3 eingeführt, die jetzt einfach herausgeflogen sind.

Ich hatte außerdem ganz bewusst die Mehrsprachigkeit für Programme und Statusangaben eingeführt und diese an die Systemsprache gekoppelt. Das hat sich ganz gut bewährt - aber bisher finde ich in der überarbeiteten Version keine Übersetzungen nach den eingebauten Hashtabellen.

Mehr konnte ich heute nicht testen.

LG, Frohes Weihnachtsfest

pah

Adimarantis

Danke fürs anschauen und ebenfalls Frohes Fest. Weihnachtsbaum steht, also hab ich kurz Zeit zu antworten.

Ich hab das jetzt einfach mal gepostet um eben Feedback zu bekommen. Dass einiges - insbesondere mit mir unbekannten Geräten - nicht funktionieren wird war klar.

Die Bedeutung von "Bereit" ist, dass das Gerät bereit zur Verwendung ist - was ja auch bei ausgeschalteten Geräten der Fall ist.

Die "Root" Präfixe sind m.E. so richtig, das "Status.SelectedProgram" wird vom Modul gesetzt - das hatte ich so gelassen, sollte man aber wohl entfernen. Das "Root" Reading kommt so von der API.

Mein FHEM läuft mit encoding=unicode, daher hatte ich die Werte kodiert - muss ich noch abhängig von der Einstellung machen - daher dürften bei dir alle Umlaute etc. aktuell vermüllt sein.

Kurzzeitwecker ist das der Alarm? Da habe ich leider kein Gerät, welches das verwendet.
Ich zeige hier RemainingProgramTimeHHMM - entweder ist das für den Fall falsch oder das wird nicht aktualisiert.
Gerne hier Hinweise/Wünsche wie das darzustellen wäre.

Die Idee vom "percent" reading war etwas ohne Einheit zur Verfügung zu stellen, was einfacher in Bedingungen (DOIF) zu verwenden ist. Idee für einen besseren Namen? Das "time" ist auch so ein Überbleibsel und eigentlich redundant, da es ja genau so in RemainingProgramTimeHHMM steht.

Die Systematik von "state1" und "state2" kann man auch diskutieren. Diese sind rein zu Anzeigezwecken und da der Platz unter einem Icon in FTUI recht schmal ist, spalte ich diese ausführlicheren Infos in zwei Spalten auf.
Customizing sollte hier in z.B. UserReadings unter Verwendung der Originalreadings erfolgen.
Gerne Anregungen, aber hier wird man es niemals jedem Recht machen können.

Übersetzung: Ich fand die Übersetzung von Readingwerten etwas kritisch, da man ja evtl. Abfragen (DOIF, notify...) darauf aufbaut und sich das zerschiesst, wenn man die Sprache ändert oder die Übersetzing ein/ausschaltet.
Grundsätzlich ist das Modul aber so programmiert, dass ich deine Übersetzungstabellen (sind ja noch alle da) ohne Probleme an zentraler Stelle (replaceValue()) einbauen könnte - genau deswegen hab ich das auch überall sonst rausgeworfen. Muss ich mir noch überlegen. Ich würde es bei mir nicht wollen, aber in "state1/2" sehr wohl.
Vielleicht wäre ein Ansatz zu sagen state1/state2 wird immer anhand der locale Einstellung übersetzt - wer auf "DE" schaltet will solche Infos sicher auch Deutsch und das Attribut "translate" schaltet es dann für die Readings auf.

Aktuell schwimme ich bisschen mit den ganzen "Delay...." set-Befehlen.
Kannst du kurz erläutern wie das gedacht war?
Beim meinem Trockner (FinishRelative) macht das aktuell totalen Quatsch.
Außerdem wollte ich mir diese $localoptions näher ansehen. Überlege da einen Hash draus zu machen - dann wirds im "list" auch lesbarer und ist eindeutiger als arrray Indizes

Gruß,
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)

DerTom71

Hallo Adimarantis,

ich habe 4 Geräte zum testen:
Cooking.Oven
Refrigeration.FridgeFreezer
Cooking.Hob
Dishcare.Dishwasher

Kühlschrank/Spühlmaschine/Bachoffen
Den Wert des Readings doorstate könnten man um den Präfix kürzen. Bei mir:
BSH.Common.Status.DoorState=BSH.Common.EnumType.DoorState.Closed

Kühlschrank:
Der Wert des Readings state=off, obwohl BSH.Common.Setting.PowerState=On ist.
Mein Kühlschrank hat eine automatische Türöffung. Das wäre ein Befehl denn ich gerne hätte.

Schöne Weihnachten.

Gruß
Tom

Prof. Dr. Peter Henning

Zitat von: Adimarantis am 24 Dezember 2024, 14:43:41Kannst du kurz erläutern wie das gedacht war?
Das ist nötig, weil der "Delayed Start" bei den einzelnen Geräten der BSH-Gruppe unterschiedlich realisiert ist. Wenn man dem Modul eine
DelayStartTime übergibt, fängt das Gerät UM eine bestimmte Uhrzeit an. Mit DelayEndTime sorgt man dafür, dass das Gerät ZU einer bestimmten Zeit fertig ist. DelayRelative bewirkt, dass das Gerät IN einer Zeit von hh:mm Stunden und Minuten startet.
Bitte das unbedingt wieder einbauen, das brauche ich nämlich.

Betreffend die Übersetzungen: Da habe ich durchaus Arbeit hineingesteckt, und möchte nicht, dass das jetzt wieder herausfliegt. Meines Erachtens sollte das jeder selbst festlegen können, dafür gibt es das Systemattribut language (und im Zweifelsfall auch noch das Attribut translate). Und aus genau diesem Grund habe ich die drei State-Angaben als "tr_State1..3" bezeichnet, tr steht für translated.

Betreffend die Präfixe: "Root" sollte in jedem Fall entfernt werden, wenn man den Attributwert namePrefix=0 setzt, sonst ist das inkonsistent.

Betreffend den Kurzzeitwecker: Ja, das ist der Alarm - und z.B. beim Kochfeld das Einzige, was man über FHEM setzen kann.

Betreffend "percent": Es gibt zwar bei vielen FHEM-Devices ein Reading pct - aber nur dann, wenn dieses eindeutig zuzuordnen ist, z.B. bei Rollläden oder Dimmern. Bei einer Waschmaschine könnte das Vieles bedeuten. Um es eindeutig zu machen, müsste man das Reading schon mindestens "pctFinished" nennen

So, Schluss für heute.

LG

pah

Adimarantis

Zitat von: DerTom71 am 24 Dezember 2024, 16:28:56ich habe 4 Geräte zum testen:
Cooking.Oven
Refrigeration.FridgeFreezer
Cooking.Hob
Dishcare.Dishwasher
3 mir unbekannte, hört sich vielversprechend an.

ZitatKühlschrank/Spühlmaschine/Bachoffen
Den Wert des Readings doorstate könnten man um den Präfix kürzen. Bei mir:
BSH.Common.Status.DoorState=BSH.Common.EnumType.DoorState.Closed
Das sollte eigentlich schon passieren in
Status.DoorState=Closed

ZitatKühlschrank:
Der Wert des Readings state=off, obwohl BSH.Common.Setting.PowerState=On ist.
Mein Kühlschrank hat eine automatische Türöffung. Das wäre ein Befehl denn ich gerne hätte.
Ich denke da brauche ich mehr Infos und man müsste wohl auch mal mittracken welche Infos/Events vom Device kommen.
Als nächstes hätte ich dafür die Idee, dass man ein spezielles Logging in ein extra Logfile aktivieren kann, welches alle Aktionen mitprotokolliert.
Das schaltest du dann ein, und machst ein paar typische Aktionen - dann werte ich das File aus.

Gruß,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

Zitat von: Prof. Dr. Peter Henning am 24 Dezember 2024, 17:02:08Betreffend die Übersetzungen: Da habe ich durchaus Arbeit hineingesteckt, und möchte nicht, dass das jetzt wieder herausfliegt. Meines Erachtens sollte das jeder selbst festlegen können, dafür gibt es das Systemattribut language (und im Zweifelsfall auch noch das Attribut translate). Und aus genau diesem Grund habe ich die drei State-Angaben als "tr_State1..3" bezeichnet, tr steht für translated.
Ich hätte folgenden Vorschlag mal testweise realisiert:
Du definierst im Attribut "translate" eine kommagetrennte Liste von Readings (nur der Kurzname, also z.B. DoorState).
Diese Readings werden dann mit den Tabellen übersetzt und komplett ohne Prefix eingetragen. Das "tr_" hab ich mir mal gespart, da die original Readings den einfachen Prefix behalten und es so eindeutig bleibt. Kommt also raus
"DoorState=geschlossen"
Funktioniert übrigens auch für Programme (z.B. "SelectedProgram")
Bei Readings mit "units" werden diese entfernt um sie besser weiterverarbeiten zu können. (also alles nach Leerzeichen)

Dadurch kann sich jeder aussuchen, was er gerne hätte und sich dann aus diesen Readings individuell eigene Readings bauen.
Als Default bleibt state1 und state2 welches automatisch übersetzt wird wenn global auf "DE" gesetzt ist.

ZitatBetreffend die Präfixe: "Root" sollte in jedem Fall entfernt werden, wenn man den Attributwert namePrefix=0 setzt, sonst ist das inkonsistent.
Insbesondere mit dem o.g. Feature sollte das "Root." m.E. bleiben, damit es keine Namenskonflikte gibt.

Das ganze Zeit und Alarm Thema hab ich mir bisher noch nicht weiter angeschaut.
Viel Zeit ist in den Modulstart gegangen:
Mit 3 Geräten hatte ich beim FHEM Neustart ständig Timeouts bei der initialen Abfrage von Infos und die Devices wären total unvollständig befüllt.
Liegt vielleicht auch daran das mein System viel zu tun hat - insbesondere HMCCU blockiert beim init einiges.

Mein Ansatz ist jetzt mit timer eine zufällige Zeit zu warten bis ich einen Home Connect Request mache und dann noch ein paar Retries vorzusehen.
Aktuell läuft der Fehler bei device=offline noch in die selbe Schiene - das sollte noch gesondert behandelt werden.

Langsam denke ich die Kernfunktionalität wird einigermassen stabil.
Todo:
- Filelog Modus damit Anwender mir unbekannte Geräte mitschneiden können, was die Arbeit diese korrekt zu implementieren vereinfachen sollte
- Zeitfunktionen reparieren
- localsettings in hash umbauen
- Zustandsübergänge testen und ggf korrigieren

Gruß,
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)

Prof. Dr. Peter Henning

Bleiben wir mal bei der Spülmaschine - die wird derzeit am häufigsten benutzt.

Nachdem ich da jetzt einmal DelayRelative 0:01 angegeben haben, kann ich das Ding gar nicht mehr über das Modul starten.
Fehlermeldung "Key BSH.Common.Option.StartInRelative has unexpected type or value false".
Die Werte für den verzögerten Start werde ich auch nicht mehr los, sogar wenn ich das Ding komplett auf PowerOff stelle, mit anderen Worten: Dort ist etwas kaputt gegangen.

Verschwunden ist auch die Option "SilenceOnDemand", die in meiner Version bestens funktioniert hat. Dazu gibt es zwar ein Reading, aber keinen Setzbefehl.

Dann gibt es nach wie vor das (durch die inkonsistente Benennung von BSH verursachte) Problem, dass Ready eben nicht gleich "Bereit" ist. Solange die Kiste nicht "PowerState=On" hat, geht eben gar nichts. Aus dem Grund hatte ich das bei meiner Version als "Inactive" gekennzeichnet, genau wie bei Backofen und Kochfeld. Bei der  Waschmaschine kommt dann noch "Offline" hinzu.

Betreffend die Präfixe für SelectedProgram: Es gibt ein "set <device> SelectedProgram <string>". Wenn kein gleichnamiges Reading (eben _ohne_ Präfix) existiert, gibt das DropDown-Feld nicht den aktuell eingestellten Wert wieder. Darum plädiere ich nach wie vor dafür, statt eines Readings "Root.SelectedProgram" den "Root"-Präfix herauszunehmen. Ob dann noch das doppelte "Status.SelectProgram" drin bleibt, ist Geschmackssache.

Das mit dem Encoding-Problem kann ich nicht ganz nachvollziehen. Normalerweise habe ich mit Unicode-Daten überhaupt kein Problem.

Kann ich stateFormat zwar abfangen, es wundert mich trotzdem.

LG

pah

Prof. Dr. Peter Henning

Waschmaschine, läuft gerade (manuell gestartet).
Eingestellt (und von der App richtig angezeigt) ist "Cotton". Das Modul behauptet aber, dass SelectedProgram ebenso wie ActiveProgram "Super1530" sei.

SpinSpeed und Temperature werden nicht aktualisiert, sondern stehen auf den (somit falschen) Werten vom letzten Lauf.

LG

pah

Adimarantis

Wenn eine neue Version vom Modul mit "reload" eingespielt wird, wäre wichtig entweder FHEM durchzustarten oder zumindest ein "set <device> init" (aus der Kommandozeile da die Option im Webinterface nicht angeboten wird) auszuführen.
Sonst sind die internen Strukturen, Readings etc. potentiell unvollständig, was insbesondere dazu führt, dass Options nicht gehen.

Spülmaschine: Ich denke ich hab ziemlich die Gleiche. Der Fehler der delayedStart verhindert hat, sollte jetzt behoben sein. Ich habe zumindest meine jetzt erfolgreich um 5 Minuten verzögert gestartet.
SilentMode: das hätte wahrscheinlich nach einem manuellen getProgramOptions funktioniert. Sollte jetzt aber jedesmal automatisch laufen (ungetestet), wenn ein neues Program ausgewählt wird. Ich konnte es zumindest nach einem getProgramOptions bei mir erfolgreich setzen.

Die "delayed" Optionen schauen bei "StartInRelative" Devices soweit gut aus.
Bei "FinishInRelative" stimmt m.E. die Berechnung nicht - ging das schon mal? Damit muss ich noch spielen. Mein Trockner ist so ein Gerät, also kann ich das gut ausprobieren.

Meine alte Waschmaschine lief jetzt auch und hat das Programm eigentlich korrekt angezeigt. Vielleicht lag das am fehlenden "set init"?

Das Logfile Feature ist jetzt eingebaut:
Bitte das Attribut "logfile" mit einem entsprechenden Filenamen setzen, ein "set init" durchführen (oder FHEM neu starten) und dann die entsprechenden Aktionen mitprotokollieren und hier posten. Das logfile enthält alle Events und die JSONs von der API Kommunikation.
Es sollten m.E. keine "privaten" Daten enthalten sein. Die HaId wird mit "XXXX" ersetzt - ich denke das ist einzige das wirklich individuell ist.

Root.SelectedProgram: Jetzt verstehe ich deine Motivation. Persönliche finde ich es nicht so schlimm wenn das aktuelle Programm nicht vorausgewählt ist - man will es ja sowieso ändern und die Liste ist jetzt nicht so lang. Wenn man es nicht kürzt ist es doch genauso. Bin noch nicht überzeugt. Wäre eine Sonderlocke - ich hätte es gerne generisch.

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)

Prof. Dr. Peter Henning

Na, das war schon nach einem Neustart, kein einfaches reload.

Derzeit gehts eher gar nicht.

2024.12.26 17:27:50 1: Downloading https://raw.githubusercontent.com/bublath/FHEM-HomeConnect/master/controls_homeconnect.txt
2024.12.26 17:27:50 1: UPD FHEM/48_HomeConnect.pm
2024.12.26 17:27:50 1: Got 101136 bytes for FHEM/48_HomeConnect.pm, expected 91546

Ich habe das jetzt erstmal manuell wieder eingespielt, alles brav initialisiert.

Unschön dabei: Bei "set .. init" wird ein Icon eingetragen - die habe ich extra herausgeworfen, ich arbeite lieber mit devStateicon

Und nein: Auch wenn alles initialisiert ist, und auch nach manuellem get ProgramOptions wird mir kein "set ... SilenceOnDemand" angeboten.

LG

pah


Adimarantis

Die Dateigröße anzupassen vergisst man gerne. Ich hab jetzt ein Script geschrieben, das die controls Datei mit anpasst.

Die Verfügbarkeit von Options ist recht tricky. Es kommt drauf an was man manuell und was über FHEM startet und wann man getProgramOptions aufruft (für SilenceOnDemand muss das Programm bereits laufen wenn man das tut).

Daher wäre es echt hilfreich mein logfile Attribut zu nutzen, um den genauen Ablauf mitzuloggen. Jeder machts ein bisschen anders und es dauert sicherzustellen, dass alle Varianten abgedeckt sind.

Die aktuelle Version sollte hoffentlich besser funktionieren.
Wenn mit FHEM ein Programm ausgewählt wird, werden die aktuellen Optionen geholt, womit die "set" Befehle, die VOR dem Programmstart verfügbar sind nach einem Browser Refresh angezeigt werden sollten.
Wird das Programm manuell gewählt, passiert das aber nicht! Hier befürchte ich ans Rate Limit zu kommen, wenn ich bei jedem "Klick" am dem Gerät eine Abfrage mache.

Sobald das Gerät gestartet wird (ActiveProgram wird gesetzt - sollte also sowohl manuell oder per startProgram funktionieren) , wird jetzt getProgramOptions aufgerufen, wodurch Optionen die man dann nicht mehr einstellen kann (z.B. VarioSpeed) verschwinden und SilenceOnDemand auftaucht (wieder: Browser refresh!)

Am Rande: Ich habe theoretisch eingebaut dass man die Farbe vom AmbientLight ändern kann (Dishwasher und Hood), da meiner Frau das Blau zu dunkel war. Anscheinend kann das meine Maschine aber nicht (ich habe "emotionLight" und das kann man wohl nur ein/ausschalten) - aber vielleicht hat jemand ein Gerät dass es kann und möchte das probieren. Jetzt ist nur die Frage wie man verhindert, dass Optionen angeboten werden, die Geräte nicht haben. Daher wäre es interessant ein Logfile von AmbientLight Besitzern zu bekommen - vielleicht wird die Fähigkeit ja irgendwo mitgeliefert - dann weiss ich das ich es deaktivieren muss, wenn das nicht der Fall ist.

Und danke für die Geduld. Wie schon angemerkt ist die API nicht gerade sehr komfortabel und konsistent - da hilft oft nur trial and error - und da man ja nicht ständig die Spülmaschine laufen hat kann das dauern :)


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)

Prof. Dr. Peter Henning

#12
Zitat von: Adimarantis am 26 Dezember 2024, 22:02:27Die Verfügbarkeit von Options ist recht tricky
Amen, Bruder, Amen.

Darum hatte ich ja Standard-Options definiert, die immer verfügbar sein sollten.

Starten der Spülmaschine funktioniert nach wie vor nicht, Fehler liegt hier drin:

Zitat2024.12.27 11:00:52 Request:$VAR1 = {
          'callback' => sub { "DUMMY" },
          'uri' => '/api/homeappliances/XXXX/programs/active',
          'data' => '{"data":{"key":"Dishcare.Dishwasher.Program.Eco50","options":[{"key":"BSH.Common.Option.StartInRelative","value":false}]}}'
        };

2024-12-27_11:00:52 SN55ZS49CE StartProgram
2024.12.27 11:00:52 Response with HC_PS: 1
2024.12.27 11:00:52 Response:$VAR1 = {
          'error' => {
                       'key' => 'SDK.Error.InvalidOptionValue',
                       'description' => 'Key BSH.Common.Option.StartInRelative has unexpected type or value false'
                     }
        };

2024-12-27_11:00:52 SN55ZS49CE lastErr: Key BSH.Common.Option.StartInRelative has unexpected type or value false



LG

pah

Adimarantis

Langsam krieg ich die Krise mit dem Ding. Gerade nochmal delayed start probiert und heute wurde der OperationState nicht auf "DelayedStart" gesetzt (was gestern ging), was meinen Flow wieder ausgehebelt hat  >:(
Und mit getProgramOptions muss man warten, bis die Maschine auf "run" geht - während der "Wartezeit" ist SilenceOnDemand noch nicht verfügbar.
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

#14
Zitat von: Adimarantis am 27 Dezember 2024, 12:57:11Langsam krieg ich die Krise mit dem Ding
Tja. Hat schon seinen Grund, dass ich damit nur sehr langsam weitergemacht habe. Aber ich denke, dass wir da durchaus gemeinsam die Kurve kriegen können.

Bei mir hat übrigens vorhin der OperationState ganz wunderbar auf DelayedStart gewechselt.

Zum Thema des sofortigen Startens: Bitte in Zeile 1409 einfach setzen
Zitat$value = "0 seconds"
statt nur "0". Das sollte das beheben.

LG

pah

Edit: Habe gerade festgestellt, dass "AlarmEndTime" im Kochfeld (Hob) nicht mehr funktioniert, bei Backofen sehr wohl. Irgendetwas faul an der Berechung der Sekundenzahl. "AlarmRelative" geht aber noch.
EditEdit: Käse, mein Fehler. Hatte die Zeit zu spät gesetzt, und bin in einen "OutofBoundsError [0 - 5940] seconds" gelaufen.