Reale Behanghöhe im Item anzeigen (HmIP-FROLL)
Moderator: seppy
-
rbeudel
- Beiträge: 294
- Registriert: 6. Jun 2019 11:25
Re: Reale Behanghöhe im Item anzeigen (HmIP-FROLL)
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
Ralf
Debmatic und Openhab in Proxmox VM debian x86_64
- udo1toni
- Beiträge: 15704
- Registriert: 11. Apr 2018 18:05
- Wohnort: Darmstadt
Re: Reale Behanghöhe im Item anzeigen (HmIP-FROLL)
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:
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:
Die Gegenrichtung kann man in ähnlicher Form gestalten.
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
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
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
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