Phillips Hue Sensoren vereinen

[Superposchi]

Hallo, ich habe einen Bewegungsmelder von Phillips Hue, nutze ihn zur Helligkeitserkennung, Bewegung macht ja über Fhem kaum Sinn.
Dennoch liefert der Sensor ja auch andere Werte wie Tag/Nacht und Temperatur.
Wie ich die einzelnen Werte ins Fhem kriege weiß ich, aber dafür benötigt es ja quasi dann 4 Devices.

Gibt es eine Möglichkeit die ganzen Werte in einem einzigen Device zu vereinen?
Von mir aus auch über ein zusätzliches Device in dem die Werte automatisch in entsprechende Readings geschrieben werden.

Setreading per notify auf .* müsste ja gehen, aber gibt es da keine effektiveren Wege, gerne auch mit DOIF.
Die wErte sollen halt nur bei Änderung in das Sammel-Device übertragen werden um unnötige Datenverkehr zu reduzieren.

[DeeSPe]

Bei mir macht es ein notify:

Code Auswählen Erweitern

defmod n_HUE_Sensor_sync notify ([idw]z|fl)_Sensor[23]:(lightlevel|temperature):.* {\
  my $r = substr($NAME,0,2);;\
  fhem "setreading ".$r."_Sensor1 luminance ".int($EVTPART1/1000) if ($EVTPART0 =~ /^l/);;\
  fhem "setreading ".$r."_Sensor1 temperature ".sprintf("%.1f",$EVTPART1) if ($EVTPART0 =~ /^t/);;\
}

Sensoren habe ich in den Räumen iz, dz, wz und fl - folgend als xx genannt.
Ich benutze im UI nur "xx_Sensor1".
Habe aber auch die Sensoren "xx_Sensor2" für "lightlevel" und "xx_Sensor3" für Temperatur.
Somit schreiben alle "xx_Sensor2" ihren "lightlevel" Wert (geteilt durch 1000) in das Reading "luminance" in "xx_Sensor1".
Und alle "xx_Sensor3" schreiben ihren "temperature" Wert auch in das Reading "temperature" in "xx_Sensor1".

Gruß
Dan

[Beta-User]

Falls du das "Sammeldevice" nur zur Anzeige in FHEMWEB haben willst, geht das z.B. auch über readingsGroup über den Umweg der devspec auf uniqueid:

Code Auswählen Erweitern

define innr2_all readingsGroup uniqueid=00.15.8d.00.03.28.46.70-01.*:(state|power|consumption)

Das hat den Vorteil, dass es keine weiteren Events erzeugt (dieses "Rumgeschubse" via Eventhandler (notify/DOIF) ist unter Performance-Gesichtspunkten mAn. nicht optimal).

Ansonsten fand ich das am Anfang mit HUEDevice auch irritierend, dass zusammengehörige (?) Infos auf mehrere Devices verteilt werden, aber bei temp/hum/luminance ist es doch eigentlich auch egal, oder, ob das Readings sind oder separate Devices?

[Superposchi]

Genau, es geht nur um die Anzeige in Fhemweb bzw. die Adressierung aus FTUI heraus (immer der gleiche Name für das Sensor-Device).

Die Aktualisierung im Browserfenster geschieht per longpoll und überträgt nur die jeweils geänderten Zellen. Wenn eine readingsGroup in keinem Browserfenster angezeigt wird, findet keine longpoll Aktualisierung statt.

Verstehe ich das richtig, dass die Werte aus dem Ursprungsdevice in regelmäßigen Abständen abgefragt werden und dass auch nur dann wenn die Werte im Browser angezeigt werden, also zb bei einer anzeige in FTUI würde kein Polling stattfinden.

Mehrere Devices werden durch Leerzeichen getrennt, habe ich das richtig verstanden?

Hab es ausprobiert, entspricht nicht ganz dem was ich mir vorgestellt hatte.
Was ich eigentlich suche ist ein Device, dass dann als Readings die Info's der ursprünglichen Device-Readings anzeigt, die dann mit Stateformat bearbeiten kann.
Meine erste Idee war ein Weg über Userreadings, aber weiß nicht ob das überhaupt funktionieren würde.

[Beta-User]

"longpoll" ist das, was du auch in der Device-Ansicht beobachten kannst: die Zeitstempel werden automatisch rot, wenn ein Wert (triggernd) aktualisiert wird. M.E. nix mit "Abfrage", das ist ein push-Mechanismus.

Was die Details zu readingsGroup angeht: Bitte cref und Wiki bemühen, es gibt da mehrere Möglichkeiten, wie man die aufbauen kann. Mein Beispiel war, das mit regex zu machen.

userReadings wird vermutlich nicht klappen, weil man damit nicht auf Events von anderen Devicen reagieren kann. Hängt auch wieder von vielen Faktoren ab, ob es (immer!) klappt, ich würde hier so oder so abraten (es sollte als Argument dagegen eigentlich schon reichen, dass man unnötige Infos erzeugt!).

EDIT: den Edit habe ich zu spät gesehen...

Du kannst auch mit stateFormat direkt auf Readings anderer Devices zugreifen, und auch readingsGroup kennt Formatierungen für alles mögliche...

[Superposchi]

Ich glaube meinen Kommentar bezüglich stateformat hast du falsch verstanden.
Ich habe bei meinem Shelly H&T per stateformat alle readings mit Zeilenumbrüchen in den STATE geschrieben (wenn man das so sagen kann). damit habe ich ein Device mit mehreren einzelnen Readings und dennoch in der Raumansicht alle Werte direkt ordentlich untereinander Dargestellt.
So in etwa ist meine Wunschvorstellung für die Hue-Sensorik ebenfalls.

Nur zum Verständnis:
Push bedeutet doch soviel, dass das Gerät seine Daten automatisch an Fhem sendet und diese dann im entsprechenden Device automatisch angezeigt werden.
(Long)Poll dagegen bedeutet, dass Fhem das Gerät alle paar Minuten um die Daten "bittet" und diese dann im entsprechenden Device anzeigt, also abruft.
Ob es sich dabei jetzt um ein Gerät (Aktor/Sensor) oder ein anderes Device handelt dürfte an der Definition doch keinen Unterschied machen, oder?
Bitte korrigiere mich wenn ich da falsch liege.

Zum Verständnis:
Userreadings würden demnach nur innerhalb eines Devices richtig funktionieren, nicht Systemübergreifen, richtig?

Werde mir cref und wiki noch mal anschauen, doch leider habe ich nur diese eine Möglichkeit gefunden, wie ich aus mehreren unterschiedlichen gezielten Devices Infos aus verschiedenen Readings abrufen kann. Hier das List meiner ReadingsGroup:

Code Auswählen Erweitern

Internals:
   CFGFN     
   DEF        wz_tempsensor:temperature wz_lightsensor:lightlevel sz_motiondetector:state
   FUUID      602b8a93-f33f-793a-c563-354ef7011eeaf7e7
   NAME       sensor_blumenecke
   NR         45303
   NTFY_ORDER 50-sensor_blumenecke
   STATE      Initialized
   TYPE       readingsGroup
   changed    0
   mayBeVisible 1
   CONTENT:
     sz_motiondetector 1
     wz_lightsensor 1
     wz_tempsensor 1
   CONTENT2:
   DEVICES:
     ARRAY(0x5df0b170)
     ARRAY(0x5cfb0020)
     ARRAY(0x5d3b59e0)
   fhem:
     lastDefChange 25
     last_update 1613466436.60799
   helper:
     DEF       
     positions:
       sz_motiondetector.state 3:1
       wz_lightsensor.lightlevel 2:1
       wz_tempsensor.temperature 1:1
     values:
       formated:
         undef
         ARRAY(0x5d341b48)
       orig:
         undef
         ARRAY(0x5d5b4cd8)
       prefixsuffix:
         undef
         ARRAY(0x5dd9b7f8)
Attributes:
   noheading  1
   notime     1
   room       Sensoren->Wohnzimmer

[Beta-User]

1. Du kannst in stateFormat beliebigen Perl-code ausführen, also z.B. auch via ReadingsVal() auf Werte von einem anderen Device zugreifen. Der Haken: Das wird nur aktualisiert, wenn stateFormat "evluiert" wird. Das passiert, wenn (irgend-) ein Reading an dem Device triggert, an dem der Code "hängt" (nicht: auf das er indirekt zugreift).
2. (Fast) dasselbe gilt für userReadings. Auch damit kann man indirekt Daten von anderen Devices "abholen". Man weiß halt nie, ob der Zeitstempel paßt, daher: not recommended!

3. longpoll ist nach meinem Verständnis "push" aus FHEMWEB an dessen Clients, das hat erst mal nichts damit zu tun, wie das Device an sich aktualisiert wird (ob via push oder pull-Mechanismus).
Wenn ein Reading aktualisiert wird, wird das direkt an den FHEMWEB-Client weitergegeben.

4. Zu readingsGroup gibt es im Wiki einen langen Artikel: https://wiki.fhem.de/wiki/ReadingsGroup
Da sind auch Beispiele zu Formatierung etc. drin. Für das HUEDevice-Problem würde ich dem Bauchgefühl nach eher dazu tendieren, das mit uniqueid-devspec zu machen, dann kann man es einfacher portieren und es ist auch unempfindlicher gegen Umbenennungen...
EDIT: hier noch etwas zum Thema Darstellung:

Code Auswählen Erweitern

attr innr2_all cellStyle { "c:2" => 'style="text-align:right"' }
attr innr2_all mapping {'consumption' => 'Verbrauch Total: ', 'power' => 'Leistung', 'state' => 'Status:'}
attr innr2_all nonames 1
attr innr2_all valueFormat {power => "%.1f W", consumption => "%.0f Wh"}
attr innr2_all valueIcon { state => '%devStateIcon' }


5. Noch simpler: Vielleicht schaust du dir auch das group-Attribut mal an? Auch damit kannst du die Geräte in FHEMWEB einfach zusammensortieren, die Formatierung machst du direkt im Device und es gibt auch die Möglichkeit, eine Reihenfolge festzulegen (sollte in der cref zu FHEMWEB zu finden sein, wie genau).

[Superposchi]

Das mit dem Group werde ich mir anschauen, aber ich befürchte, da wird das gleiche Problem auftreten wie auch bei Readingsgroup. Nämlich, dass die abgerufenen Werte nicht als eigene Readings in dem Sammeldevice vorhanden sind. Eigentlich ja auch logisch beim Namen "Group".

Für das Stateformat und ReadingsVal müsste dann ein Dummy erstellt werden in dem  - ne das funktioniert doch auch nicht, weil der ausgegebene Wert sich nur auf ein einzelnes Reading bezieht, nämlich auf state. Da fehlt dann der zwischen Schritt die Readings aus den einzelnen Devices in jeweils einzelne Readings in einem einzigen Device zu vereinen. Erst dann sollen Sie ja mit StateFormat formatiert werden. Sonst habe ich ja beim Zugriff aus FTUI immer noch verschiedene Device-Namen.

[Beta-User]

...also doch nicht FHEMWEB! Du willst das für FTUI! MERDE!

Falls du das "Sammeldevice" nur zur Anzeige in FHEMWEB haben willst, geht das z.B. auch über readingsGroup über den Umweg der devspec auf uniqueid:

Wenn ich immer auf die Nase falle, weil du mir auf ausdrückliche Nachfrage (erst!) eine unvollständige Antwort gibst und die dann nachträglich abänderst, ohne das nochmal klarzustellen, ist es spaßfrei!

Da ich nur FHEMWEB kenne und keine Ahnung von FTUI habe, kann ich nicht helfen, vermute aber, dass FTUI sämtliche Formatierungen in FHEMWEB herzlich wurst sind.

Bin jetzt hier raus, bleibe aber bei der grundsätzlichen Aussage, dass es nicht zielführend ist, irgendwelche Infos innerhalb FHEM hin- und herzuschubsen.

[Superposchi]

Wo habe ich denn eine unvollständige Antwort gegeben und die dann später geändert? Ganz ehrlich, zeig mir das mal bitte.
Wenn sich aus einer Diskussion neue Aspekte ergeben, kann es sein, dass sich auch neue Informationen ergeben, dass ändert jedoch nichts an der Frage.

Ich habe von Anfang an gefragt ob und wenn wie es möglich ist, die Readings aus verschiedenen Devices in ein Device zu übernehmen. wie diese dann im neuen Device dargestellt sind, habe ich nichts zu gesagt, da mir nicht klar war, dass es überhaupt eine andere Möglichkeit gibt, als in Readings/UserReadings. Weshalb dieser Punkt für mich nicht weiter erwähnenswert ist.

ReadingsGroup bringt nun mal das Problem mit sich, dass die Daten nicht in Readings gelistet sind, sondern sonst irgendwie. Offenbar werden ja separate Unterdevices erzeugt. Denn das Device hat weder ein STATE noch Readings.

Was FTUI angeht, ok wenn du dich damit nicht auskennst ist das kein Ding, aber grundsätzlich funktioniert es genau wie in Fhem auch, es wird auf ein Device verwiesen und ggf. zusätzlich auf ein Reading/Internal/etc. zur Eingrenzung.
Wenn ich schreibe, dass ich aus FTUI heraus auf das Sammeldevice zuzugreifen, dann eben einfach nur aus dem Grund, nicht für jeden Wert einzelne Devices und Readings vorgeben zu müssen, sondern ein Device mit unterschiedlichen Readings. Also einfach zur Vereinfachung.

Falls du das "Sammeldevice" nur zur Anzeige in FHEMWEB haben willst, geht das z.B. auch über readingsGroup über den Umweg der devspec auf uniqueid:

Um es also noch mal ganz deutlich zu sagen: Ja es geht so, aber nicht im Sinne wie ich es nutzen will, weshalb es mir nichts bringt.

[Beta-User]

Ging um den Beitrag von 9:57.

Code Auswählen Erweitern

« Letzte Änderung: Heute um 10:09:18 von Superposchi »  Hatte dann zwar den unteren Edit gesehen, bin aber ziemlich sicher, dass in der Ausgangsfassung oben noch nix von FTUI stand.

Nochmal zur Klarstellung: Es hat mAn. einen triftigen Grund, warum FHEMWEB und FTUI (=TabletUI) je einen eigenen Unterforenbereich haben, und wir hatten afaik neulich schon mal die Diskussion darüber, ob es dasselbe ist. Da warst du leider auch nicht überzeugt, dass es zwei Paar Stiefel sind. Genau daher hatte ich sehr deutlich angemerkt, dass readingsGroup (nur) eine Lösung für FHEMWEB ist. (Man kann rG allerdings wohl auch in FTUI übernehmen, aber da gibt es Probleme mit der Aktualisierung, die keiner genau zu verstehen scheint).

Ansonsten kennst du ja jetzt meine Meinung: Readings zu vervielfachen, nur um sie in einem Sammeldevice zu haben ist (aus FHEM-Sicht) keine Vereinfachung, sondern eine Vervielfältigung von Problemen, die man ohne diese Art Würgaround nicht hat. Von daher würde ich weiter empfehlen, die händische Zusammenfassung eben in FTUI vorzunehmen, und nicht FHEM mit dieser Art Eventgenerierung sich selbst beschäftigen zu lassen.

[Superposchi]

« Letzte Änderung: Heute um 10:09:18 von Superposchi »

Sorry, wie man es macht ist es verkehrt. Ich bin schon sooft angepfiffen worden, dass man keine Doppelpostings erstellen soll, sondern lieber das alte Ergänzen. Man kann es nicht jedem Recht machen.

und wir hatten afaik neulich schon mal die Diskussion darüber, ob es dasselbe ist.

Und auch da wolltest du nicht einsehen, dass der Zugriff auf die gleiche Art und Weise erfolgt, nämlich in dem ein Device und ggf ein Reading/Intervall/etc. angegeben wird.
Es geht nicht darum wie die Daten in FTUI verarbeitet, berechnet oder sonst wie benutzt werden, sondern ausschließlich wie die Datenquelle aussieht und wo sie her kommt. Und da ist in beiden Fällen eben ein Device auf dem Server. Ob dies in Fhemweb oder FTUI abgefragt wird spielt keine Rolle.

Was die doppelte Datenvorhaltung angeht, gebe ich dir natürlich recht. Daten doppelt zu führen birgt immer das Risiko auch einen Fehler zu verdoppeln. Doch in ausgewählten Fällen ist es manchmal doch von Vorteil, wenn man Daten zentralisiert und ordentlich aufbereitet.

Nichts desto trotz funktioniert es ja nicht, da ReadingsGroup die Daten eben nicht in eigenen Readings abbildet. Damit ist immer noch ein Unterschied zu den restlichen Sensoren, weshalb ich es dann auch ganz sein lassen kann.

[Beta-User]

Nichts desto trotz funktioniert es ja nicht, da ReadingsGroup die Daten eben nicht in eigenen Readings abbildet. Damit ist immer noch ein Unterschied zu den restlichen Sensoren, weshalb ich es dann auch ganz sein lassen kann.

Genau weil readingsGroup nur eine Anzeigeoption (eigentlich) speziell für FHEMWEB ist, war meine Einleitung sinngemäß: FALLS ES NUR DARUM GEHT...

FTUI ist eben an der einen oder anderen Stelle eine eigene Lösung, auch wenn - logischweise - der Basisdatenlieferant immer FHEM ist. Von daher glaube ich immer noch, dass die verkürzendere Sichtweise auf diese Dinge eher nicht auf dieser Seite der Diskussion sitzt, aber wie bereits angemerkt, habe ich von FTUI keine vertiefte Ahnung, und am Ende willst ja du dein Problem gelöst haben, also mußt du deine Welt verstehen. Dass ich das nochmal hochgeholt hatte, hat nur damit zu tun, dass ich neulich schon mal versucht hatte zu erklären, dass es aus meiner Wahrnehmung nicht dasselbe ist, und du das hättest wissen können...

Und das Problem ist nicht nur die Datendoppelung, sondern noch viel mehr noch die Event-Vermehrung. WENN man schon eine Art Abstraktionsebene einziehen will, dann sollte man mAn. wirklich alles "aufbereitet" an eine zentrale Stelle schieben, und den aufbereiteten Datenbestand _nicht im selben FHEM_ halten. In jedem Fall meine ich, die Aufbereitung in FTUI sei effizienter, vorausgesetzt, man braucht die "aufbereiteten Daten" dann wieder nur für FTUI (was bei dir der Fall zu sein scheint).

[Superposchi]

FALLS ES NUR DARUM GEHT...

Wir leben einfach in zwei völlig unterschiedlichen Welten.
Für mich ist die Darstellung - egal ob in Fhemweb oder FTUI - eine reine Designgeschichte und anpassbar wie man es will, da gibt es keine Grenzen. Genau deshalb wurden cascading Style Sheets erfunden.
Die Vorhaltung der Daten jedoch macht einen großen Unterschied. Ob man nun 3 Devices mit jeweils einem state-Wert hat, ein Device mit einem state-Wert, der in drei Zeilen aufgeteilt ist oder ein Device , dass drei werte als einzelne Readings bereit stellt ist ein großer Unterschied, da der Abruf sich unterscheidet.
Nur mal so als Verständnis für meine Denkweise.

Für FTUI gilt das gleiche Grundlagenprinzip wie in Fhemweb. es wird per Abruf von Device und ggf. Reading/Internals/etc. auf bereitgestellt Werte zugegriffen bzw. diese Zurückübertragen. Wie diese dabei in FTUI angezeigt werden ist ebenfalls uninteressant, da ebenfalls von css und persönlichen Einstellungen abhängig ist. Es macht jedoch genau wie bei Fhemweb einen großen Unterschied wie die Daten bereitgestellt werden.

Da du mehrfach betont hast, dass du kein FTUI nutzt, würde mich aber interessieren welches Frontend bei dir zum Einsatz kommt.

Das Sammeldevice gebe ich erst mal auf, da der Aufwand und die Probleme den nutzen überwiegen. War ja eh nur als Schönheits- und Vereinfachungsoption gedacht und keine funktionelle Verbesserung.

[sinus61]

Zum Verständnis:
Userreadings würden demnach nur innerhalb eines Devices richtig funktionieren, nicht Systemübergreifen, richtig?

Warum? Die Aqara Sensoren sind z.B in Fhem als 3 Devices sichtbar, ich mache dann am Temperatursensor ein Userreading:

Code Auswählen Erweitern

humidity { ReadingsVal("Sensorname","humidity",0) }

Und schon hat man die Feuchtigkeit auch im Temperatur Device. Genauso mit dem Luftdruck.