Neuer ioBroker-Blog online: Monatsrückblick März/April 2026

[hberndt]

Hallo,

ich frage mich, wie man am Besten ein Fenster in den ioBroker Konzepten (Objekte / Alias, Aufzählungen, Geräte) darstellt.

Meine Fenster haben 2 Reed-Kontakte, mit denen "geschlossen", "geöffnet" und "gekippt" auseinander gehalten werden können. Außerdem haben sie ein Rollo bzw einen Raffstore, die Verfahrposition und (bei Raffstores) eine Lamellenposition haben (jeweils Stati und Verfahr-Befehle).

Alle diese Stati / Befehle sind zugänglich über den openknx Adapter - jeweils Einzelobjekte in verschiedenen Hierarchien (die KNX Gruppenadressen sind nach Funktionen aufgebaut).

Nun möchte ich diese vielen, in der Hierarchie von openknx.0. verstreuten Objekte besser für Skripte zugänglich machen. Ich möchte Dinge skripten wie

• Abfrage: Welche Fenster sind noch offen?
• Abfrage: An welchen Positionen stehen die Rollos?
• Automatisierung: Wenn es anfängt zu regnen und ein Fenster offen ist,
  fahr das Rollo runter

Mit dem Skripten selbst komme ich bislang zurecht, aber ich bin unsicher, ob ich die ioBroker Konzepte passend verwende.

1. Verrechnen der Reed-Kontakte

Ich möchte in einem einzigen Objekt den Öffnungsstatus eines Fensters ablesen können. Dazu habe ich mir einen "folder" 0_userdata.0.Fenster erzeugt, dort für jedes Fenster ein "device" eingerichtet und ein Objekt "Öffnungsstatus" erzeugt (also z.B. 0_userdata.0.Fenster.Bad.Öffnungsstatus). Objekttyp ist "Zahl", die ich aber als Bitfeld nutze: Via Skript setze ich für jeden der beiden Reed-Kontakte ein Bit (also 0: geschlossen, 1: geöffnet, 3: gekippt).

Frage: Gibt es auch Objekte mit enum-Typ, so dass ich das nicht eine Zahl als Bitfeld missbrauchen muss? Wäre so etwas passender als Alias anstatt userdata? (aber wenn ich das richtig verstehe, können bei einem Alias nicht 2 Objekte zusammengerechnet werden?)

Unterstützen Visualisierungen oder Systeme wie Alexa gekippte Fenster? Welche Datentypen erwarten die?

Sollten diese Objekte "readonly" sein? Das Skript muss sie setzen, aber sonst niemand. Logisch gesehen sind diese Objekte nicht beschreibbar - ich kann kein Fenster schliessen, indem ich das Objekt auf 0 setze. Ist das eine Anwendung für readonly plus ein spezieller Wert im ack-Flag?

2. Status-Abfragen

Um die Objekte für Status-Abfragen zu sammeln habe ich "Aufzählungen" definiert. Für "Fenster Status" habe ich Bitfelder aus userdata zusammengesammelt. Für Dachfenster und Haustüren musste kein Kipp-Status verrechnet werden, dafür gibts eigene Aufzählungen, die direkt die Objekte aus openknx sammeln. Gleiches gilt für Rolloposition, Raffstoreposition und Raffstore-Lamellenstellung.

Wie schaffe ich nun eine Zuordnung zwischen einem Fenster-Öffnungsstatus und dem zugehörigen Rollo?

Sollte ich neben 0_userdata.0.Fenster.Bad.Öffnungsstatus noch 0_userdata.0.Fenster.Bad.Rollo_Status_Position, 0_userdata.0.Fenster.Bad.Rollo_Position_anfahren etc erzeugen? Diese wären 1:1-Spiegel der jeweiligen Objekte aus openknx - also quasi Aliase, die aber nicht unter alias, sondern unter userdata liegen. Hört sich irgendwie falsch an.

Oder wäre das ein Anwendungsfall für "Geräte"? Definiert man dann ein Gerät "Fenster" mit den Zuständen "Öffnungsstatus", "Raffstore_Status_Positon", "Raffstore_Status_Lamellenstellung", "Raffstore_Position_anfahren", "Raffstore_Lamellenstellung_anfahren"?

Wenn ich allerdings ein Gerät "Fenster" erzeuge, bekomme ich als Zustand ein bool'sches "ACTUAL". Das hilft mir nicht wirklich.. Was sind diese "Indikatoren"? Und was die Symbole bei den Gerätetypen? Heisst das, dass diese Typen mit Amazon Alexa oder anderen Smart-Home Anbietern korrespondieren?

Kann jemand meine Verwirrung aufklären, oder gibt es Doku, wie das mit den Geräten gedacht ist?

[paul53]

@hberndt sagte: Gibt es auch Objekte mit enum-Typ

Ja, nennt sich Werteliste und hat die Eigenschaft common.states, z.B.

"states": {
   "0": "geschlossen",
   "1": "gekippt",
   "2": "offen"
}

@hberndt sagte in Fenster mit Reeds/Rollo/Raffstore als Gerät repräsentieren:

bekomme ich als Zustand ein bool'sches "ACTUAL".

Der Adapter "Geräte" macht es zwar für Anfänger einfach, ist aber recht unflexibel. Man kann Alias-DP auch direkt im Tab "Objekte" unter "alias.0" erstellen.

@hberndt sagte in Fenster mit Reeds/Rollo/Raffstore als Gerät repräsentieren:

"Raffstore_Status_Positon", ..., "Raffstore_Position_anfahren",

Kommando und Status lassen sich in einem Alias zusammenführen.

[hberndt]

@paul53 Vielen Dank für die Hinweise! Ich schau mir die common.states mal an, genauso das Zusammenführen von Status und Kommando in Aliasen.

Zumindest scheine ich nicht völlig auf dem Holzweg zu sein mit dem Ansatz.

Ist das dann ein

"type": "multistate"

und muss ich dann die states direkt im Freitext in den "Objektdaten" schreiben, anstatt in der "COMMON" Maske mit den klickbaren Feldern?

Ich find leider nur wenig Info zu dem Thema. Kannst du mich auf Doku o.ä. zu den Wertelisten und common.states verweisen?

[hberndt]

@paul53 Ich glaub, so langsam versteh ich die multistate Typen. Allerdings bekomme ich folgende Warnung für Aufrufe von "setState()" mit einem multistate Ziel:

You are assigning a number to the state "0_userdata.0.Fenster.Bad.Öffnungsstatus" which expects a multistate. Please fix your code to use a multistate or change the state type to number. This warning might become an error in future versions.

Wie setzt man denn einen multistate in setState()?

[paul53]

@hberndt sagte: "type": "multistate"

Nein,

"type": "number"

Zum Multistate wird es durch common.states.

@hberndt sagte in Fenster mit Reeds/Rollo/Raffstore als Gerät repräsentieren:

muss ich dann die states direkt im Freitext in den "Objektdaten" schreiben

Ja. Beispiel:

  "common": {
    "name": "Lüfter Modus",
    "role": "level.mode",
    "type": "number",
    "desc": "Manuell erzeugt",
    "states": {
      "0": "Aus",
      "1": "Stufe 1",
      "2": "Stufe 2"
    },
    "min": 0,
    "max": 2,
    "def": 0,
    "read": true,
    "write": true
  },

[hberndt]

@paul53 Prima, so sind auch die Warnungen weg. Vielen Dank!

Da frage ich mich nur, wieso man dann im "COMMON" Tab in der Auswahlmaske als Zustandstyp "multistate" auswählen kann. Mich zumindest hat das auf die falsche Fährte gelockt.