(noch kein) neues Modul - Generische Raumübersicht

Begonnen von KernSani, 07 Januar 2023, 23:14:07

Vorheriges Thema - Nächstes Thema

KernSani

Hallo zusammen,

Nach ewigen Zeiten habe ich mich mal aufgerafft und versucht ein bisschen Doku zu machen.

Grundidee der "Generischen Raumübersicht" ist, durch die Definition eines Devices eine einheitliche Übersicht raumspezifischer Informationen zu bekommen. Einmal definiert, kann das Device beliebigen Räumen zugeordnet werden und stellt dann diese Informationen auf den Raum bezogen in bunten Boxen dar.
Dabei gibt es verschiedene Möglichkeiten:
* Status - zeigt eine Box mit dem aktuellen Status (z.B. Licht an oder aus, Rollläden offen oder geschlossen usw...)
* Reading - zeigt den Wert eines Readings (z.B. Temperatur)
* ReadingSumme - zeigt die Summe von n readings (z.B. aktueller Energieverbrauch aller Strom-messenden-Devices im Raum)

Die Boxen werden zustands- oder wertabhängig eingefärbt, mit Icons versehen etc...
Zusätzlich geht auch die Möglichkeit einer tabellarischen Darstellung, mit der sich z.B. der Stromverbrauch der einzelnen Geräte im Raum darstellen lässt.

Disclaimer Die Geschichte läuft bei mir und ich bin soweit glücklich damit. Ich fürchte aber, dass es in anderen Systemumgebungen oder Konstellationen durchaus krachen könnte, daher würde ich empfehlen, nicht gleich im Live-FHEM zu experimentieren. Es gibt sicher einiges was man verbessern und erweitern kann und ich baue gerne Community-Feedback ein.


Kurzdoku
Definiert wird ein generisches Raumdevice mit
define <name> GenRoom
die Informationen, die in den Räumen dargestellt werden sollen, werden in einem Attribut "devices" definiert und haben pro Box folgenden Aufbau:
<name> <devspec> <dtype> <weitere Parameter>
name: ist ein eindeutiger Name für die jeweilige Informationsquelle, also z.B. "lights"
devspec: ist eine DevSpec zum Auffinden der relevanten Geräte, bei mir Enden beispielsweise die Namen aller Lampen mit "_Licht", devspec kann auch eine komma-getrennte Liste mehrerer Devspecs sein.   
dtype: beschreibt, um welche der oben dargestellten Möglichkeiten es sich handelt, derzeit gibt es "states", "reading" und "readingSum" sowie "table". Bei "table" handelt es sich um einen Sonderfall, der weiter unten detailliert beschrieben wird.

dtype=reading: Zeigt den Wert eines numerischen Readings an, z.B. die Raumtemperatur. Entsprechen mehrere Geräte im Raum der Devspec, ist es mehr oder weniger Zufall, welches Gerät genutzt wird, daher sollte die Devspec eindeutig sein, oder die blacklist (s.u.) genutzt werden. Wenn eine Box vom Typ "reading" erstellt wird, ist zwingend auch der Parameter "reading" notwendig, der - wie der Name schon sagt, das darzustellende reading angibt (Beispiel "reading=temperature"). Es ist auch eine komma-getrennte Liste von Readings möglich, um den Fall abzudecken, dass unterschiedliche Geräte unterschiedliche Readingbezeichnungen für den selben Inhalt haben ("power" und "ENERGY_Power").
dtype=readingSum: Entspricht "reading", mit dem Unterschied, dass die gefundenen Werte aufsummiert werden (also beispielsweise die momentanen Verbräuche aller strommessenden Geräte im Raum), auch hier ist der Parameter "reading" notwendig.

Zur Formatierung von "reading" und "readingSum" gibt es folgende Parameter:
bgcolors: Die Hintergrundfarbe der Box ist abhängig vom dargestellten Wert (kalt = blau, warm = rot), dafür wird dem Parameter entweder eine komma-separierte Liste übergeben:
<Farbschema>,<Wert-Untergrenze>,<Mittlerer Wert>,<Wert-Obergrenze>
Farbschema ist dabei einer der Werte: pahColor (Verlauf von blau über grün nach rot), gyr (Verlauf von grün über gelb bis rot) oder hum (Verlauf von sandbraun nach blau) 
oder - alternativ, ein einzelner RGB-Hex-Farbwert.
fcolors: Die Schriftfarbe, entspricht vom Aufbau der Hintergrundfarbe
format: einen sprintf-Formatierungsanweisung
index: eine Zahl, zur Sortierung der Boxen

dtype="states": Zeigt den Status (=reading "state") eines oder mehrerer Geräte an. Diese Anzeige kann drei Werte annehmen, state1, state2 oder keiner der beiden. Die folgenden Parameter sollten daher immer drei Werte beinhalten:
states: <state1>,<state2>,<undefined>   
bgcolors: <Hintergrundfarbe wenn Gerät den state1 hat><Hintergrundfarbe wenn Gerät den state2 hat><Hintergrundfarbe wenn Gerät keinen der beiden states hat>
fcolors: entspricht bgcolors für die Schrift- bzw. Iconfarbe
icons: <Icon bei state1><Icon bei state2><icon bei keinem der beiden> Icon ist dabei ein FHEM-SVG-Icon oder - wenn es mit fa- beginnt ein Font Awsome Icon.
index: s.o.

Einzelne Boxen werden durch "|" separiert, am Verständlichsten wird das Ganze vermutlich bei einem Blick auf den Inhalt meines "devices" Attributes.

lights devspec=".*_Licht.?"  dtype="states"  states="on,off,undefined"  bgcolors="#E19E20,#a0acbd,#fff7d6"  fcolors="white,white,#a0acbd" icons="fa-lightbulb,fa-regular fa-lightbulb,fa-lightbulb"  index=10
|temp devspec=".*_Temp.?" dtype="reading" bgcolors="pahColor,17,21,27" fcolors="white" reading="temperature" format="%.1f&deg;" index=20
|hum devspec=".*_Temp.?" dtype="reading" bgcolors="hum,30,60,100" fcolors="white" reading="humidity" format="%.0f%%" index=21
|blinds devspec=".*_Rollo" dtype="states" states="open,closed,undefined" bgcolors="#a0acbd,#2E5E87,#85AFDD" fcolors="white,white,white" icons="fts_shutter_10,fts_shutter_100,fts_shutter_50" index=30
|presence devspec="hz_.*" dtype="states" states="present,absent,undefined" bgcolors="#276733,#a0acbd,#38c190" icons="fa-user-check,fa-user-xmark,fa-user-clock" fcolors="white,white,white" index=40
|energy devspec="r:0_energyCurrentW!=" dtype="readingSum" bgcolors="gyr,0,100,1000" fcolors="white" reading="0_energyCurrentW" format="%.0fW" index=50

Zusätzlich gibt es noch eine "blacklist", in der (kommagetrennt) devspecs für auszuschließende Geräte aufgelistet werden können.
Entscheidend ist dann natürlich noch das "rooms" Attribut, in dem alle Räume angekreuzt werden, in denen die Boxen auftauchen sollen.

Der Spezialfall "Table" entstand aus meinem Bedürfnis, zu sehen, wie sich die "ReadingsSum" oben zusammen setzt und ist (aktuell zumindest) relativ spezifisch auf meine Bedürfnisse zugeschnitzt und ich bin mir nicht so ganz sicher, ob das allgemein übertragbar ist. Ich würde empfehlen Boxen und Tabellen nicht zu mischen, sondern für die Tabelle ein eigenes GenRoom Device anzulegen.
Die Tabelle braucht auch eine devspec und ein reading (entsprechend dem "reading" bzw. "readingSum"-Fall). Der Wert dieses Readings wird in der ersten Spalte der Tabelle dargestellt. Für alle weiteren Spalten gibt es den Parameter "readingPattern", in dem kommagetrennt weitere Device:Reading-Paar aufgeführt werden. Als Variable stehen dabei %device% und %reading% zur Verfügung, die durch die DevSpec-Reading-Kombination aus den ersten Paramtern ersetzt werden.
Als Beispiel:
devspec=".*_energy" reading="power,ENERGY_Power" --> Dies führt dazu, dass alle Energy-Devices die entweder "power" oder "ENERGY_Power" haben gefunden werden. Der jeweilige Wert wird dargestellt.
über das readingPattern="%device%:consumptionTotal,%device%:ENERGY_Total" würde dann zum jeweiligen Device noch die Gesamtleistung ausgelesen und in der nächsten Spalte dargestellt. GenRoom geht dabei stumpf von vorne nach hinten durch und stellt alles dar, was gefunden wird.   


 

Grüße,

Oli
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

taskkill

Na klar, warum nicht. Anschauen, Ausprobieren und dann schauen ob's man gebrauchen kann...
Von alleine entwickelt sich nichts  ;)
RPI 3B+ mit Raspbian Bullseye auf SSD, aktiver USB-Hub, Fhem (is klar), TI CC2652P, nanoCUL 868 WMBUS, Echo Plus 2te Gen., ESPxxxx, usw.

thburkhart

1 RASPI4B, 1 RASPI3B, 2 CUL, 2 Jeelink, 60 Tuya-Devices (Schalter, Dimmer, Sensoren, Cameras), 30 HUE-Lampen, 5 MAX! WTs, 16 MAX! HTs, 12 MAX! FKs, 1 Bresser 5in1, 1 OilFox, 8 ALEXA Echos und Dots, FHEM, 5 Tasmota-Devices, SonOff -Bridge, PowerFox, Buderus KM200

ergerd

FHEM auf RasPi 4, CUNO, ZigBee, 1Wire2WLAN, DS2423, Buderus KM200, LaCrosseGateway, PCA301, ConBee II, LuftdatenInfo, OneWireGW, Div. ESPs u. Shellys

DeeSPe

Die Idee an sich finde ich gut!
Ich denke schon einige Zeit darüber nach wie man daraus evtl. eine Modulfamilie ähnlich zu RESIDENT-ROOMMATE-GUEST-PET machen könnte.
So etwa ESTATE-BUILDING-FLOOR-ROOM.
Die müssten dann ja alle irgendwie ineinandergreifen.
Bin aber bisher noch nicht auf eine brauchbare Idee gekommen.
Aber evtl. macht das auch alles gar keinen Sinn?

Gruß
Dan
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

KernSani

Ups... Habe garnicht gesehen, dass hier Antworten kamen  ??? Ich schnitze mal noch ein bisschen dran und werfe es dann hier rein...

RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

KernSani

Hat zwar ein paar Tage gedauert, aber jetzt habe ich mich mal aufgerafft... siehe erster Post
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...