Reale Behanghöhe im Item anzeigen (HmIP-FROLL)

Moderator: seppy

rbeudel
Beiträge: 294
Registriert: 6. Jun 2019 11:25
Answers: 1

Re: Reale Behanghöhe im Item anzeigen (HmIP-FROLL)

Beitrag von rbeudel »

Das habe ich auch nicht hinbekommen. In der Sitemap habe ich so wie Du beide Items nebeneinader Dargestellt. Für die neue UI gibt es Widgets bei der Beide Kanäle angegeben werden können. Dort wird die Behnghöhe zumindest bildlich Dargestellt
Viele Grüße,
Ralf


Debmatic und Openhab in Proxmox VM debian x86_64

Benutzeravatar
udo1toni
Beiträge: 15704
Registriert: 11. Apr 2018 18:05
Answers: 254
Wohnort: Darmstadt

Re: Reale Behanghöhe im Item anzeigen (HmIP-FROLL)

Beitrag von udo1toni »

Grundsätzlich gibt es immer zwei Möglichkeiten:
1. direkt verlinken
Ein Rollershutter Item, beide Channel sind direkt mit diesem Item verlinkt. Dabei ist zu beachten: Es bekommen beide Channel den Steuerbefehl, wenn openHAB ein sendCommand sendet. Wenn beide Channel tatsächlich ein Status Update senden, gewinnt der letzte empfangene Wert.
2. indirekt (über ein paar Rules) verlinken (das geht immer).
Dazu brauchst Du drei Items, nämlich je eines für die beiden Channel und ein drittes, ungebundenes.
Welchen Itemtyp Du verwendest, ist dabei individuell. Das ungebundene Item wird später in der Sitemap (bzw. UI) verwendet, es bietet sich also an, dieses als Rollershutter Item anzulegen. Die beiden anderen legst Du passend zu den beiden Channeln an. Nehmen wir an, die Items heißen RS_UI, RS_Control und RS_State, dann braucht es noch ein paar Rules:

Code: Alles auswählen

rule "update RS state"
when
    Item RS_State changed
then
    if(!(newState instanceof Number)) return; // Status keine Zahl, Abbruch
    RS_UI.postUpdate(newState) // speichere neuen Status in RS_UI
end

rule "control RS"
when
    Item RS_UI received command
then
    RS_Control.sendCommand(receivedCommand)
end
Falls der Channel nur bestimmte Befehle annimmt, kannst Du die zweite Rule auch aufwändiger bauen :) und bestimmte Befehle umschreiben oder ausfiltern.

Außerdem kann man mit den beiden Rules auch sehr leicht ein reziprokes Verhalten erreichen:
aus UP mach DOWN und umgekehrt; Bei Zahlenwerten nimm a = 100 - b

Wenn man mehrere gleichartige Antriebe hat, kann man die Itemnamen geschickt wählen (ähnlich dem Beispiel), dei Items in Gruppen zusammenfassen und dann die Rules so schreiben, dass sie jeweils auf Member of Groupitem reagieren. Dann kommt man mit je einer Rule für alle Channel aus und ide Rule wird nur unwesentlich komplexer:

Code: Alles auswählen

rule "einer Rule für alle RS Controls"
when
    Member of gRS_UI received command // z.B. RS_UI_raum1
then
    val raum = triggeringItem.name.split("_").get(2) // z.B. "raum1"
    val control = gRS_Control.members.filter[i|i.name.endsWith(raum)].head
    control.sendCommand(receivedCommand)
end
Die Gegenrichtung kann man in ähnlicher Form gestalten.
openHAB5.1.3 stable in einem Debian-Container (trixie, OpenJDK 21 headless runtime - LXC, 4 Kerne, 3 GByte RAM)
Hostsystem Proxmox VE 9.2.3 - AMD Ryzen 5 3600 6 Kerne, 12 Threads - 64 GByte RAM - ZFS Pools: Raid Z1, 3 x 20 TB HDD -> 40 TByte und Raid Z0-Mirrored 4 x 1 TByte NVMe -> 2 TByte

Antworten