Symbol für Gruppen

[MarkoP]

Hallo, kann man einer Gruppe die aus Hue per autocreate erzeugt wurde auch einen State zuweisen?
Bei mir steh da immer nur unknown, egal ob die Gruppe on oder off ist.

Ich würde der Gruppe gerne mit devstateicon ein Icon zuweisen, doch das geht natürlich nur wenn die Gruppe einen defnirten Zustand hat.

[Beta-User]

"State" kann man sicher auch zuweisen, aber den Sinn dahinter müßtest du mir erklären, für mich machen nur "state" oder "STATE" Sinn .

Ansonsten solltest du mal einen kritischen Blick auf ein "list" von so einem Device werfen bzw. darauf, welche Readings sich ändern, wenn alle/keines/ein Teil der Geräte an sind und dich danach mit stateFormat beschäftigen .

[MarkoP]

Sorry, ich meinte STATE. Ich vergesse immer dass es das state in Kleinbuchstaben auch noch gibt.
Der Sinn ist ganz einfach, dass ich gerne erkennen würde ob eine Lichtgruppe (also alle zugewiesenen Lampen einer Gruppe) eingeschaltet sind oder nicht.
In den meisten Fällen schalte ich wahrscheinlich die Gruppe und nicht die einzelnen Gruppenmitglieder.
Im Moment wird der STATE kontinuierlich mit "Unknown" angegeben, weshalb keine Zuweisung mit devstateicon möglich ist. Es wird konstant ein nichts sagendes Icon mit einem Fragezeichen drin angezeigt.

stateformat dient doch der Formatierung, oder? Was soll ich damit bewirken können?
Die Readings der "Gruppenmitglieder" sind eigentlich egal, da sie sich ja ändern und der STATE der Gruppe trotzdem "Unknown" bleibt.
Das einzige was mir einfällt wäre mit Hilfe eines structure die STATE der Gruppenmitglieder "auszulesen" und das dann dem Gruppendevice zuzuordnen, aber dann kommt wieder ein überflüssiger Dummy (structure) ins Spiel. Außerdem wüsste ich nicht wie ich den Wert aus dem structure an den STATE der Gruppe übergeben kann, das ginge doch nur mit userreadings.

P.S.:
Nur zur Klarstellung, ich rede von automatisch erzeugten Gruppen, die in der Hue-App angelegt wurden, nicht von Devices die in Fhem als Gruppe angelegt worden sind.
Welcher Art entsprechen die über autocreate angelegten HUE-Gruppen-Device eigentlich? Ist das ein extra Device-Typ? Offensichtlich ja kein structure-device, oder?

P.P.S.:
Worin besteht eigentlich der genaue Unterschied zwischen STATE und state, das habe ich noch nicht kapiert? In der Regel sind die beinhalteten Werte identisch.

[Beta-User]

1. Liefere bitte ein list (von dem HUEDevice der fraglichen Gruppe).
2. Bitte verlinke die Doku zu stateFormat, die du zu Rate gezogen hast.

[MarkoP]

Hier das List:

Code Auswählen Erweitern

Internals:
   CFGFN     
   DEF        group 12  IODev=Hue_Bridge
   FUUID      5f51483c-f33f-b8b5-6246-f595145d182b9ae4
   FVERSION   31_HUEDevice.pm:0.218370/2020-05-02
   ID         G12
   INTERVAL   
   IODev      Hue_Bridge
   NAME       HUEGroup12
   NR         70865
   STATE      unknown
   TYPE       HUEDevice
   class      Bedroom
   desired    0
   lights     3,4
   name       Nachtische
   type       Zone
   READINGS:
     2020-09-03 21:56:50   all_on          0
     2020-09-04 05:55:49   any_on          0
   helper:
     devtype    G
     fromAutocreate 1
     update_timeout 1
     json:
       class      Bedroom
       name       Nachtische
       type       Zone
       action:
         alert      select
         bri        254
         colormode  xy
         ct         153
         effect     none
         hue        0
         sat        254
         xy:
           0.2142
           0.0813
       lights:
         3
         4
       sensors:
       state:
     lights:
       3          1
       4          1
Attributes:
   IODev      Hue_Bridge
   alias      Nachtische
   color-icons 2
   delayedUpdate 1
   devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
   group      Licht
   room       20_Schlafzimmer
   userattr   createActionReadings:1,0 createGroupReadings:1,0

Doku kann ich keine Verlinken, der Satz bezog sich auf verschiedene gelesene Information bei Rechergen zu anderen Befehlen und die daraus abgeleiteten Schlüsse.

[Beta-User]

OK, dann melde dich wieder, wenn du den Abschnitt readingFnAttributes in https://fhem.de/commandref_modular.html gelesen hast (oder die DE-Version) und die Doku zu HUEDevice (https://fhem.de/commandref_modular.html#HUEDevice). Ich werde dann entscheiden, ob ich dir eine funktionierende RAW-Definition von so einem Device zeige. Meine Erwartung ist, Bemühungen erkennen zu können, das zu verstehen.
Ansonsten bin ich hier raus.

[MarkoP]

Also soweit ich das verstehe - und ich bin mir bei vielem nicht sicher - soll ich per stateformat den Inhalt aus state an STATE übergeben. Dabei kann der übergebene Inhalt formatiert werden oder auch nicht. Ist das so richtig? Habe mir auf die schnelle die google-Übersetzung der englischen Seiten durchgelesen, aber die ist natürlich nicht wirklich gut.

Falls ja bestehen zwei Probleme:
1. ich habe in der Gruppe kein reading state, einzig all_on und any_on, keins der angegebenen readings in der Devicebeschreibung ist vorhanden.
2. die readings all_on und any_on reagieren nr wenn man die Gruppe ein-/ausschaltet und wechseln zwischen 0 und 1, was man ja noch mit an und aus oder on und off umformatieren könnte. Aber es bringt ja nichts wenn die readings beim direkten Schalten der Lampe auf 0 stehen bleiben.

P.S.:
List liefere ich später nach, kriege ich vom Handy aktuell mal wieder nicht hin.

[Beta-User]

Wow, translator statt https://fhem.de/commandref_modular_DE.htm...

Nein, wie du schon richtig beobachtet hast, entspricht STATE state, wenn man _nichts_ macht. Dieses dafault-Verhalten kann durch (mind) zwei Stellschrauben GEÄNDERT werden: eventMap und stateFormat. Damit bekommt man also _etwas anderes_ nach STATE. Lesetipp: https://wiki.fhem.de/wiki/DeviceOverview_anpassen

Ich muß zugeben, dass mich das Verhalten der Gruppe beim Schalten einzelner Devices daraus bisher nicht sonderlich interessiert hat, weil ich die wenn, dann nur in der Gruppe schalte bzw. dimme. Ich gehe aber davon aus, dass justme68 auch da einen guten Job gemacht hat und man sinnvolle Ergebnisse erhalten kann, wenn man die gruppenbezogenen Spezialattribute an HUEDevice nutzt. (da gibt's die cref allerdings nur in englisch, aber evtl. kannst du die Attributnamen ja als Schlagworte für die Suche im Wiki bzw. Forum nutzen, falls der englische Text mit etwas Ausprobieren nicht weiterhilft (Trockenübungen sind Sch..., aber das hatten wir auch schon, oder?)).

[MarkoP]

Sorry, aber woher soll ich wissen dass es die URL https://fhem.de/commandref_modular_DE.htm... gibt. auf der von dir verlinken Seite wurde nirgendwo ein Link zu einer deutschen Version angezeigt (so wie in der CommandRef).
Allgemein habe ich nicht das Problem mit Englisch, doch leider sind in den Artikeln zu viele Abkürzungen und Fachbegriffe enthalten für die man die Übersetzung erst recherchieren muss. Dafür fehlt mir während der Arbeit aber leider die Zeit. Darum hatte ich auf den Translator zurückgegriffen., der war/ist der schnellste Weg. Sicher nicht die beste Möglichkeit aber das beste was ohne das Wissen und ohne Zeit geht.

Aber egal, zum Thema:
Mein Problem ist ja eben, dass ich das reading state in der HueGruppe nicht bekomme. Wie geschrieben sind die einzigen beiden readings "all_on" und " any_on". Wobei der Sinn der beiden readings nicht wirklich schlüssig ist, da sie immer beide entweder 1 oder 0 sind. Und eben auch nur schalten, wenn die Gruppe direkt geschaltet wird. Schaltet man die einzelnen Lampen die in der Gruppe enthalten sind einzeln, bleiben beide readings auf 0, selbst wenn alle Lampen eingeschaltet sind.

Was verstehst du unter gruppenbezogene Spezialattribute? Kann man die wieder über den Butten unter dem Device finden? Welche cref meinst du? die normale CommandRef?

Gibt es das reading state auch wenn es nicht angezeigt wird?

[Beta-User]

Na ja, die CommandRef gibt es eben in englisch und machmal in deutsch (https://wiki.fhem.de/wiki/Dokumentationsstruktur), aber im Prinzip ist unter allen Links immer das zu finden, was du auch mit dem entsprechenden help-Befehl in FHEM sehen würdest bzw. den Button "device specific help" unten in der Detailansicht eines Geräts, auf die du dich vermutlich beziehst. Es ist daher (fast) völlig gleichgültig, ob du über modular, commandref_join (das, was hier im Forum verlinkt ist: https://commandref.fhem.de/) oder die https://fhem.de/commandref_DE.html auf die entsprechenden Seiten kommst.

Da man in der commandref_modular nur die jeweils relevanten Teile sieht, verlinke ich eben gerne auf die, die ist besser zu durchsuchen und da nur die englische verpflichtend ist, ist die auch immer vorhanden. Bis auf wenige Ausnahmen ist die auch in der Regel technisch besser als die DE-Variante.

Den betreffenden commandref-Abschnitt hatte ich bereits genannt, ebenso Stellen, wo Antworten auf die diversen noch offenen Fragen zu finden sind. Bitte lies ggf. einfach nochmal den gesamten Thread hier durch, vielleicht wird dann mein Geschreibsel auch nochmal etwas verständlicher, ist mir auch mal so gegangen, dass ich nicht alles beim ersten Mal verstanden hatte (bzw. das geht mir heute nicht ganz selten immer noch so).
Ansonsten schaust du dir das bitte an deinem FHEM heute abend in Ruhe an und experimentierst mit den Attributen von HUEDevice ein bißchen rum.

Wie bereits mehrfach betont, geht es nicht darum, dass du schnell antwortest, sondern dass du möglichst schnell Antworten findest. Meine Überzeugung ist die: Du wirst schneller Antworten finden, wenn du langsamer, aber gründlich vorgehst und wohl oder übel die grundlegenden Dinge lernst. Dazu gehört vor allem auch das Verständnis, wie die Doku zu lesen ist.

Dann warte ich jetzt mal ab, was deine abendlichen Versuche so an Erkenntnissen ergeben .

Vielleicht machst du dir auch die Mühe, mal meine ersten Fragmente eines aktuellen Einsteiger-pdf's zu lesen, das ermöglicht ggf. auch nochmal einen anderen Blick auf manches: https://svn.fhem.de/fhem/branches/epdf2020/frame.adoc. Leider funktionieren die darin enthaltenen links zu Bildern usw. noch nicht so richtig usw., aber vielleicht wird das auch irgendwann nochmal was...

[MarkoP]

Danke für die Hinweise zur Commandref, da wird einiiges klarer. Hatte immer gedacht, dass es verschiedene Quellen sind.
Wie gesagt mit dem englischen ist das so die Sache, dass man die Abkürzungen und Fachbegriffe recherchieren muss, die kenne ich halt nicht. Das dauert immer etwas, darum kürzt man gerne mal ab.

Werde mich mal durcharbeiten und schauen was ich machen kann.
Bin leider mit dem Versuchen sehr vorsichtig geworden, da ich mir das laufende System zu oft durch sowas zerschossen habe.

[Beta-User]

Ich hatte für fleißiges Lesen ein list ausgelobt...

Da du das in dem anderen Thread ausgiebig unter Beweis gestellt hast hier mal eine RAW-Definition (in der Hoffnung, dass dir klar ist, was der Unterschied zu einem "normalen" list ist):

Code Auswählen Erweitern

defmod Licht_Essen HUEDevice group 240  IODev=phoscon
attr Licht_Essen userattr createActionReadings:1,0 createGroupReadings:1,0
attr Licht_Essen IODev phoscon
attr Licht_Essen alias Licht Essen
attr Licht_Essen color-icons 2
attr Licht_Essen delayedUpdate 1
attr Licht_Essen devStateIcon gr.1:on:off gr.0:off:on
attr Licht_Essen group Licht
attr Licht_Essen icon light_control
attr Licht_Essen room Esszimmer
attr Licht_Essen stateFormat gr:any_on
attr Licht_Essen webCmd pct:ct
(Bitte vor eventuellen Fragen Device-Overview anpassen im Wiki nachlesen...)

[MadMax-FHEM]

Bin leider mit dem Versuchen sehr vorsichtig geworden, da ich mir das laufende System zu oft durch sowas zerschossen habe.

Drum hab ich mindestens 1 Testsystem (aktuell sogar 2 )...

Da probiere ich rum und auch "neue" ("unbekannte") Module etc. aus...

Wenn ich dann die Funktionalität "brauche"/will und mir das Modul zusagt -> Hauptsystem

Ebenso andere "Spielereien" inkl. OS-Pakete (nach)installieren: erst mal auf dem Testsystem(en) und da auch mitnotieren, was ich tun musste um es zum Laufen zu kriegen (inkl. "Verifikation" eines "geradlinigen" Wegs [weil oft geht's mal "hin-und-her"   ])...

Und gleiches: wenn ich' dann "haben will", dann kommt es auf's Hauptsystem...

WEIL: mein Hauptsystem ist WICHTIG und soll (ohne Probleme) 24/7 laufen! Da kann ich keine "Spielereien" brauchen...

Gruß, Joachim

[Beta-User]

Drum hab ich mindestens 1 Testsystem (aktuell sogar 2 )...

...ja, auch ein interessantes Thema...

Ich habe auch mehrere (kleine) Testumgebungen, aber wenn es darum geht, irgendwie in Interaktion mit Hardware zu treten oder Wechselwirkungen zwischen verschiedenen Teilen zu testen, kommt man - je nachdem - kaum drumrum, manches im Hauptsystem "reifen" zu lassen (Bananenprinzip läßt grüßen, ich wünsche dir (MarkoP) eine geduldige Partnerin ).

Es ist nicht ganz so einfach, da eine Empfehlung für den Anfang zu geben, ich würde dazu tendieren, (funktionierende) Zwischenstände wegzuspeichern (also die cfg. unter passendem Namen zu kopieren) und dann ggf. tatsächlich (mit Bedacht) am Hauptsystem weiterzumachen.

Was auch helfen kann: configDB (@sqlite)! Da kannst du auch mehrere Versionen von einem Device "behalten", diffs ausgeben und ggf. dann auch mal einen alten Stand einzelner Devices rekonstruieren. (Ich nutze am Hauptsystem configDB und speichere daraus dann aber schon bei Gelegenheit/nach größeren Umbauten auch schon mal einfach nur die cfg unter dem aktuellen Datum raus. Im Übrigen wäre dann irgendwann auch das Thema Backup-Strategie (und Restore-Testen) ein wichtiger Themenkreis.)

Grundsätzlich würde ich aber dazu raten, immer nur eine Baustelle zu bearbeiten und dann die jeweils wieder auf einen Stand zu bringen, den man erst mal wieder so stehen lassen kann - daher habe ich mit dem RAW auch gewartet, bis das Thema "Schlaferkennung durch Qi-Schale?" (nicht) erledigt (aber erst mal abgehakt) ist .

[MarkoP]

Das mit dem Testsystem ist sicher eine gute Idee, wobei ich mir die Frage stelle wie ihr dabei verhindert, dass beide Systeme parallel reagieren bzw. Prozesse auslösen und es so zu ungewollten Aktionen kommt.
Backups werden bei mir jede Nacht um Mitternacht gemacht, das habe ich erst vor kurzem so eingerichtet. Außerdem müsste jedes mal eins gemacht werden wenn die Config gespeichert wird. Ich hoffe mal das sollte ausreichend sein.
Das mit dem ConfigDB ist mir ein Begriff, habe ich aber bisher komplett ignoriert. Genau um da nicht eine weitere Baustelle aufzumachen und auch weil es so wie ich es verstehe wohl eine Grundsatzentscheidung ist welches System man nutzt, eine DB oder die CFG.

Grundsätzlich würde ich aber dazu raten, immer nur eine Baustelle zu bearbeiten und dann die jeweils wieder auf einen Stand zu bringen, den man erst mal wieder so stehen lassen kann - daher habe ich mit dem RAW auch gewartet, bis das Thema "Schlaferkennung durch Qi-Schale?" (nicht) erledigt (aber erst mal abgehakt) ist

Stimme ich voll und Ganz zu und versuche das auch nach Möglichkeit einzuhalten, leider bauen zu oft Sachen auf einander auf oder greifen derart ineinander, dass dies nur bedingt möglich ist. Ich komme im Moment ja nicht mal bei diesen zwei Baustellen weiter. Neue werde ich definitiv erst nach einer Klärung beginnen. Habe mir seit Freitag mindestens ein halbes Dutzend Mal vorgenommen das Intervall bei der QI-Sache festzustellen und dann die Sache mit einem Watchdog erst mal abzuschließen, doch jedes mal wenn ich denke ich habe mal eine halbe Stunde Zeit, kommt wieder etwas anderes dazwischen