Ich hab das auch mal versucht und wollte das Programm starten.
Die neue Variable ist bei mir auch vorhanden, nimmt aber keine Eingabe entgeben bzw. meldet im Debug dass das Programm nicht verfügbar ist.
dump.txt (123,6 KB)
Das Anzeigen von Daten funktioniert:
Und auch die Steuerung über die Miele App ist möglich. Muss ich noch etwas an der Konfiguration ändern? Achso, der Geschirrspüler ist geschlossen und steht auf „@Fernsteuerung Aktiv“ (Mobil Control).
Das Variablenprofil der Variable „Programm starten“ wird erst nach dem ersten gelungen Datenabruf gefüllt - der ersten bei der das Miele-Gerät im richtigen Zustand ist.
D.h. das Miele-Gerät muss eingeschaltet sein, dann sollte bei nächsten aktiven Datenabruf im Debug des MieleAtHomeDevice ein Abruf von „programs“ zu sehen sein (aber Achtung: wie immer die Limitierung erhöhen!) und dann sollte auch das Variablenprofil mit Name MieleAtHome.Programs_<InstanzID> gefüllt worden sein. Die InstanzID der ist Namensbestandteil, weil es für jedes Gerät ja eigene Programme gibt.
Wenn das dann immer noch nicht funktioniert hat, im Splitter und Device den Debug aktivieren und die Limitierung deutlich erhöhen. Und dann ein manuelle Anruf initialisieren.
Es kann natürlich sein, das für die Miele API-Version 1.0.7 die Firmware der Gerät aktualisiert werden musste - die Version, wo diese Funktion dazu kam, ist aber schon lange draussen und damit denke ich das Gerät auch aktuell
Morgen,
kann mir Jemand bei diesem Fehler weiterhelfen:
17.06.2025, 06:02:39 | TimerPool | Oven (UpdateData):
Warning:
Warning: Undefined array key "mobileStart" in /var/lib/symcon/modules/.store/demel42.mieleathome/MielelAtHomeDevice/module.php on line 1751
in /- on line 1
Danke und lg
spannend, laut Doku muss das vorhanden sein.
Welches Gerät/Gerätetyp hast du?
Passiert das immer oder nur unter manchen Umständen?
Kann ich natürlich dann abfangen
Es ist ein Miele H7660BP Backofen.
Sehr selten tritt das auf…
Danke und lg
welche Modulversion hast du im Einsatz (Instanzkonfiguration → Panel Information)
lg
Beobachte es mal mit der aktuelle Beta (2.7.1).
Hab mir das Modul vor wenigen Tagen neu eingerichtet inkl. neuem Geschirrspüler. Leider muss ich feststellen das schon nach wenigen Stunden, oft Minuten die Anmeldung bei Miele wieder verloren geht…an was kann das liegen?
Die Frage lässt sich so nich beantworten.
Was meinst du genau mit „die Anmeldung geht verloren“?
Meldet einer der Instanzen einen Fehler oder bekommt einen Fehlerstatus? (also nicht mehr „aktiv“). Und wenn ja, welche der 3 Instanzen; es gibt ja die IO-Instanz (einen SSO-Client, der die Status-Änderungenvon der Mirle-Cloud automatisch erhält), den Splitter (der für die Befehle und die sehr seltenen Statusabfragen (1/h ist glaube ich Standard) zuständigist und die Device-Instanz(also der „Geschirrspüler“), der nur Daten auswertet und Kommandos veranlasst.
Welche Art der Anmeldung nutzt du?
Welche Version hast du im Einsatz - IPS (incl Server-Platform) sowie Modul (siehe ein paar Einträge vorher); Stable- oder Beta-Zweig?
Vermutlich werde ich auch aussagefähige Logs benötigen, um zu helfen, jetzt reicht aber erstmal die Beschreibung.
Hi!
Ich kann das Problem vorerst mal nur so beschreiben, das nach einer gewissen Zeit die Anmeldung bei Miele weg ist und wenn ich dann auf Zugang prüfen klicke, diese Meldung kommt:
Ich benutze als Art der Anmeldung Miele@Home über IP-Symcon Connect.
Wenn ich mich neu anmelde via „Miele@Home Anmeldung“ wie es auch in der Doku steht, passt wieder alles, für eine gewisse Zeit, denn geht wieder nichts mehr. Symcon ist auf der aktuellsten Ninja, das Modul im Stable. OS ist Ubuntu in der Version 20.04 LTS.
Hier noch ein Screenshot aus dem Debug, denke es liegt am Token…
hmm, ungültige Zugangsdaten ist so gesehen eine etwas unglückliche Formulieren, bedeutet in diesem Kontext, das es kein gültige Anmeldung gibt.
bei dem Zugang via Symcon-Connect funktioniert das ja so, das du im Modul eine Anmeldung einleitest und dann eine Seite von Miele angezeigt wird, bei der du dich anmeldest.
die liefert via Symcon dann einen token und einen refresh-token zurück.
die werden in der Instanz persistent (als Attribute) gespeichert (im üblichen 10m-Intervall ist das dann „auf Platte“).
Der AccessToken wird zyklisch invalid und dann wird mittels RefreshToken ein neuer AccessToken geholt, dabei wird auch ein neuer RefreshToken geholt.
Das geht unendlich so weiter, erfordert eigentlich nie eine neue Anmeldung.
Ist auch nix Miele-spezifisches, wird bei allen Anmeldungen via OAuth2 so gemacht und bei so gut wie allen Web- und API-Anmeldungen angewendet.
Es muss aber schon irgendwas bei Dir schiefgehen … also ist „eigentlich“ nicht so ganz passend.
Was ab und an passiert ist, das die zugehörige IO-Instanz auf Fehler läuft, weil aus ungeklärtem Grund die Instanz meint, das der AccessToken ungültig ist - dann hilft „Zugang prüfen“ wieder mittels des RefreshToken einen AccessToken zu erhalten.
Aber wenn bei dir einfach so, der RefreshToken gelöscht wird (wie auch immer) … schon komisch.
Als erstes würde ich bitte auf die aktuelle Beta des Moduls gehen, dann passt das zu dem aktuellen Entwicklungsstand. Da ist vermutlich nichts dabei, was das Ganze beeinflussen würde, aber schaun wir mal.
Das dein IPS auf Nija steht ist nicht ganz so doll, weil ich damit nicht ausschliessen kann, das die IPS-Version eine Rolle aoielt, gehe ich aber erstmal nicht von aus.
Wenn das dann immer noch auftritt (was ich erwarten würde), müsstet Du ein Debug der IO-Instanz und der Splitter-Instanz erstellen. Da das Log ja viel zu lang würde, um es inder GUI zu sammeln, müssen die Logs in die Logdatei protokolliert werden (das kann man im Debugfenster aktivieren). Nicht der Download des Debugs (das läd nur das, was im Debugfenster zwischengespeichert wird).
Diese Dateien (unter Linux unter /var/log/symcon zu finden und heissen debug_<InstanzID>.log
Die Datei mir per PN schickenmit einer Info, wann was gemachtw urde. Wnn ist sehr wichtig, damit ich die Stelle im Debug wiederfinden kann.
Die Debug sollten nach Möglichkeit mir der Anmeldung beginnen, damit ich sehe, das der RefreshToken kommt un gespeichert wird.
Nich zwei Hinweise:
Die beiden Debugs würde ich dann versuchen zu analysieren
Das mit dem Log und Screenshot war mir klar, sollte nur mal den ersten Eindruck vermitteln. Alles klar, hab mal auf die Modul Beta gewechselt und versuche die Logs zu bekommen, ich schick sie dir dann.
Danke!
Mir ist noch ein Gedanke bei „Ninja“ gekommen, den du eventuell verwerfen oder bestätigen kannst.
ich hatte ja gesagt, das die Token als Attribute der Instanz gesichert werden. Attributes sind (analog zu Properties), Bestandteil der settings.josn.
Diese wird ja nur alle 10m gesichert.
Soweit ich weis, wird die settngs.json ja bei einem Herunterfahren des IPS gesichert, aber ob das immer und zuverlässig erfolgt, würde ich nicht alles drauf wetten.
Wenn also zB zum Zeitpunkt X das letzte Mal gesynct wurde und bei X+2m ein neuer RefreshToken geholt wird, ist der noch für 8m ungesichert. Wenn innerhalb dieser Zeit IPS neu startet, wird ggfs. der alte RefreshToken genutzt, der aber ungültig ist - der aktuell gültige ist futsch.
Und bei Ninja wird ja häufiger, zT jeden Tag, aktualisiert.
Daher kam mir dieser Gedanke …
Ich wollte heute einen Ablaufplan erstellen, und die Variable " Arbeitsfortschritt" als Auslöser nutzen.
Dabei ist mir aufgefallen das ich da nur 1% angeben kann.
Ich möchte natürlich auf 100% reagieren, kann den Wert aber nicht eingeben. 
Kann heute nicht so richtig schauen, aber versuch mal im Variablenprofil MieleAtHome.WorkProgress die Schrittweite auf 1 zu setzen und Maximalwert auf 100.
Das ist eigentlich ein reines Ausgabeprofil, daher ist der Aspekt der Eingabe nicht geprüft.
Hoffe, das diese Änderung keine Auswirkung auf die Darstellung der Variable hat - bitte testen
Hi @demel42
Danke für die schnelle Rückmeldung 
funktioniert so! 
Die Darstellung ist weiterhin OK
Danke
