Monatsrückblick Januar/Februar 2026 ist online!

[stef.73]

Hallo zusammen,

Wie von Buzzy im Github-Issue (https://github.com/ioBroker/ioBroker.mihome-vacuum/issues/52) vorgeschlagen, mal ein separates Thema zur Diskussion von Verbesserungsvorschlägen für den ioBroker.mihome-vacuum-Adapter. Ich will den anderen Thread nicht noch weiter aufblasen.

Zu dem Issue:

Aktuell sind die Datenpunkte unterhalb von mihome-vacuum.0.control reine Steuerungs-Datenpunkte, d.h. ein einmal gesetztes true im start-Datenpunkt oder home-Datenpunkt setzt sich freiwillig nicht mehr zurück, bis der Adapter neu startet oder man es manuell auf false setzt.

Es wäre für einige meiner Scripte deutlich einfacher, wenn das automatisch abhängig von der Rückmeldung des Robbies passieren würde, d.h. wenn eine Komplettreinigung beendet ist stellt sich start zurück auf false, wenn eine Zonenreinigung beendet ist, stellt sich zoneClean auf „leer“ usw.

Die Steuerungs-Datenpunkte würden also ähnlich wie beispielsweise bei den homematic-Adaptern zusätzlich den Zustand des Robbies zeigen. Wenn start mit einem bestätigten true gesetzt wird (vom Adapter), weiß man (oder ein Script), das der Roboter gerade eine Komplettreinigung durchführt. Beispielsweise auch, wenn diese über die Xiaomi-App gestartet wurde. Oder wenn sich der zoneClean-Datenpunkt wieder leert (mit Ack), dann kann man eine neue Zonenreinigung starten. (Man kann maximal 5 Zonen auf einmal reinigen lassen, ich habe aber mehr. Würde den WAF verbessern.

Ja, mir ist bekannt, das es den Datenpunkt mihome-vacuum.0.info.state gibt, und das man die o.g. Sachen damit und einem entsprechenden Script abdecken kann, aber direkt im Adapter wäre mMn. der richtige Platz.

Was haltet ihr davon?

Gruß Stef

PS: Es können natürlich auch andere Vorschläge diskutiert werden.

[apollon77]

Wie genau ticken denn deine Skripte?

Ich persönlich setze auch viel so um das es "Status"-States gibt wo der aktuelle Aktionsstatus drin ist und ansonsten reine "Steuer-States" die ich nur zum Steuern nutze um Aktionen auszulösen. Der Wert der Steuerstates ist dabei dann meistens egal - der Status State ist meistens viel genauer, vor allem wenn es mehrere Stati gibt

[stef.73]

Beispiel:

Ich habe insgesamt 12 Zonen definiert, die in der Vis mit Schaltern (mit auswählen/nicht auswählen) abgebildet sind. Dazu dann der "An-Button", der den Trigger bildet. Über ein leeres HTML-Widget mit statusabhängigem Ausblenden ist das ganze dann verriegelt. Solange die Reinigung dauert, soll man nicht zwischendurch die Zonen wechseln. Jetzt kann man aber nur 5 Zonen in einem Rutsch an den Robbie senden.

Jetzt wäre es schön, wenn man einfach den zoneClean-Status überwachen kann, und wenn der wieder "leer" ist, sende ich die nächste Zone.

Mache ich es via "state" (Status 17, in dem Falle also oldState = 17), muss ich extra-Runden drehen, weil ich zwischen "Pause gedrückt" und "bin fertig" unterscheiden muss.

Zweites Beispiel:

Synchronisation bei Verwendung von App und ioBroker. Wenn man in der App (oder bei flole/rrcc) eine Reinigung startet, kommt das in ioBroker nur via state an. Wenn zusätzlich auch der "start"-Steuerstatus auf true gehen würde, dann würde ein entsprechender Button in der vis von ganz alleine zwischen "gedrückt" (aktiv/true) und "nicht gedrückt" (inaktiv/false) wechseln und es braucht kein zusätzliches Script.

(Ja mir ist klar, dass das bei zoneClean nicht ganz funktioniert, weil das Protokoll die Koordinaten der aktuell laufenden Zonenreinigung nicht kennt.)

Es ist nicht so dass es alles nicht geht, aber wenn es doch dieses schöne Feature "Status bestätigt" in ioBroker gibt, dann wäre die Steuerung damit halt einfacher.

Gruß Stef

[BuZZy]

Man könnte eine Option im Adapter einbauen "Reset states after cleaning" und wenn diese Option in den Instanz-Einstellungen aktiviert wurde werden die States auf false gesetzt (bzw. zone Clean und Go To geleert) nach dem die Reinigung abgeschlossen ist..

So läuft alles wie bisher, außer man ändert was in der Einstellung von der Instanz.. Wäre also "100% abwärtskompatibel" und man könnte dann mit Bool-Buttons/Widgets im Vis ohne "extra States" oder "CSS Klassen" arbeiten.

Was meinst du dazu @apollon77?

Gruß

[apollon77]

ENtweder oder in meinen AUgen. Durch den Adaptercode blickt dann keiner mehr durch und auch Support-technisch ist das die Hölle weil zu viel Magie da ist.

In meinen Augen ist es einfach:

• Es gibt AKTIONEN (start, backHome), die sind ein Trigger die eine Aktion starten … Und trigger sind in dem Fall immer Buttons und haben keinen Status, sind also nur "beschreibbar" Das ist der Taster an der Wand. Der weiss auch nicht ob das Licht was er schaltet gerade an oder aus ist

• Es gibt Statusfelder (enabled, cleaning, pause) die kann man lesen um einen Status zu sehen, aber mit Ihnen nichts kontrollieren

• Es gibt "Schalter". diese haben Zustände die man setzen kann 1..n, im einfachsten Fall Ein und Aus.

Aktuell hat der Adapter Statusfelder und Aktions-Trigger.

Man könnte es ändern und "Schalter" nutzen, aber nur wenn etwas passiert wenn ich auf "Aus" stelle, das macht bei so einem Gerät in meinen Augen aber keinen echten Sinn.

Für eine Visualisierung (so mache ich es) nutze ich die Statusfelder um den aktuellen Status zu sehen, ggf eigene JavaScript Statusfelder falls die Infos vom Adapter nicht reichen weil ich wissen will (Beispiel) was als letztes gestartet wurde 8welche Zone oder so). je nach Status blende ich die Buttons ein die man braucht.

• Ist er in der Ladestation dann habe ich die Trigger Buttons um Ihn zu starten

• Ist er unterwegs gibts nur "Stop "und "Ab heim"

Das ist meine Meinung dazu.

[BuZZy]

stef.73 zeig doch mal ein Screenshot von deiner VIS Seite für den Staubsauger, dann kann man vielleicht etwas besser eine "Lösung" finden.

Gruß

[stef.73]

Naja, genau das ist halt die javascript-Hölle, die vielleicht dem einen oder anderen nicht so entgegenkommt. Um es mal vorsichtig zu sagen.

Bei den Homematic-Sachen ist es klar. Drück ich den an-Knopf, geht das Licht an und der Status ist auf true. Ein Status, ein Knopf. In der Vis einfach einzubinden, kein JS-Geraffel, keine css-Klassen usw. Und wenn ich über einen anderen Weg das Licht einschalte (z.B. direkt an der Wand), dann seh ich es trotzdem ohne Umstände in der VIS.

In dem mihome-vacuum muss ich, um ähnliches zu erreichen, Hilfsstatus mit Scripten verwenden oder diverse Abhängigkeiten.

Ich find die Idee von Buzzy schön, das man es anschalten kann, dass die states zurückgesetzt (oder "von extern gesetzt") werden.

Ja, es sind dann keine Buttons, sondern Schalter. Und du (apollon) hast zwar Buttons, aber die sind auch nicht immer drückbar, sondern eben nur wenn der "<u>Schalt</u>zustand" dazu passt.

Gruß Stef

Hier noch der Screenshot wie erbeten. Es ist allerdings nicht so das ich aktuell ein akutes Problem habe, es ist nur ein massives Gefummel und könnte halt deutlich einfacher sein.

[apollon77]

Ich kann das Grundsätzlich schon verstehen und meine Steuerung ist bei weitem nicht so fancy (und cool) wie Deine … WOW!

Die Abwägung in meinem Kopf ist immer was der Adapter liefert und liefern muss und liefern sollte und was besser nicht.

Adapter mit zuviel "Magie" und Konfigurierbarkeit drin haben sich als sehr schlecht wartbar herausgestellt, weil es dann auch jeder User anders nutzt und der Teufel immer in den Edge cases steckt auf die man selbst nicht kommt Das soll jetzt kein Todschlag-Argument sein (und geht auch über die ursprüngliche Fragestellung hinaus), sondern generell mein Learning.

Man muss immer abwägen.

Die Entscheidung liegt effektiv beim aktuellen Maintainer des Adapters weil er es auch ausbügeln und den anderen Usern erklären muss

Falls Ihr auf die Idee kommt es anders zu machen kann ich aber nur empfehlen eigene States für die "neuen" Funktionen zu nutzen, weil wenn sich bei States Rollen und sonstwas ändern ist das blöd und für keinen mehr wirklich nachvollziehbar (und ja die Rollen und so sollten dann passend abgeändert werden).

[BuZZy]

Hallo Zusammen,

nach einiger Zeit der Abwesenheit wegen Renovierung etc. bin ich wieder am Start .. :lol:

Hier ein Auszug aus meiner aktuellen ToDo Liste..

( Ist jetzt nur schnell 1:1 von meiner Liste kopiert - deswegen vielleicht etwas "rudimentär" )

` > "Zonen" Tabelle im Admin - mihome-vacuum einbauen:

Tabellenlayout:

Name - Koordinaten - Anzahl der Reinigungen

…..

"Wohnzimmer" - "12225,12225,12345,12345" - "2"

"Küche" - "13334, 14444, 11111, 12333" - "3"

.....

Boolean states aus Tabelle generieren

"mihome-vacuum.0.zones.Wohnzimmer"

"mihome-vacuum.0.zones.Küche"

State für Start der Zonenreinigung

"mihome-vacuum.0.zones.START" => Split aller Zonen-States mit Status true auf max 5 pro Durchgang - wenn Durchgang beendet - nächste Zonen senden (wieder max 5)

"mihome-vacuum.0.zones.CLEANALL" => Sofort start (alle konfigurierten Zonen reinigen)

---

Pollingrate kleinstmöglich halten (temporär?) um schnell auf "finish" zu reagieren und next 5 zones senden. (Pause before Next zones?)

---

Zonen-States auf false zurücksetzen wenn Durchgang beendet `

Angenommen man hat 12 Zonen so wie stef.73

Dann kann man einfach alle Zonen-States die gereinigt werden sollen auf true setzen und anschließend mihome-vacuum.0.zones.START auf true und der Adapter arbeitet die Zonen ab die zuvor auf true gesetzt wurden..

Wenn mehr als 5 Zonen gereinigt werden sollen - wartet der Adapter bis die Reinigung der ersten 5 Zonen beendet ist - stellt die gereinigten Zonen-States zurück auf false und schickt dann die nächsten 5 Zonen an den Sauger..

Ich denke damit wäre dir auch geholfen stef.73 oder?

Gruß

[Messiahs]

Hi Buzzy,

gibt es Überlegungen bzgl. noGo-Zonen im Adapter zu erzeugen ? (also ähnlich bzw. zusätzlich zu der derzeitigen Zonenreinigung).

Grüße

Markus