[gelöst]devStateIcon keine Funktion

Begonnen von taskkill, 02 Januar 2022, 20:22:08

Vorheriges Thema - Nächstes Thema

taskkill

habe folgendes Problem: zwei Leuchtmittel(1E90A700AA3EB07C,A5FE070000261884) in OsramBridge als Gruppe(Stehlampe) definiert, wird dann per autocreate in Fhem angelegt. Aber keine Änderung des Icon's nach on und off.
Was kann die Ursache sein oder welcher Fehler unterläuft mir ?

Einstellungen siehe Datei.
RPI 3B+ mit Raspbian Bullseye auf SSD, aktiver USB-Hub, Fhem (is klar), TI CC2652P, nanoCUL 868 WMBUS, Echo Plus 2te Gen., ESPxxxx, usw.

alanblack

Zitat von: taskkill am 02 Januar 2022, 20:22:08
habe folgendes Problem:[...] in OsramBridge als Gruppe(Stehlampe) definiert, [...] keine Änderung des Icon's nach on und off.
Was kann die Ursache sein oder welcher Fehler unterläuft mir ?
Daran hatte ich auch eine Weile zu knobeln. Es ist meiner Kenntnis nach kein FHEM-Problem. Irgendwo hatte ich in einem Phoscon-Thread gelesen, dass für Gruppen der Status nicht funktioniert. Ist auch im Nachhinein betrachtet logisch, wenn Du bedenkst, dass Du bspw. eine Gruppe mit fünf Lampen einschaltest und dann eine von den Lampen einzeln wieder ausschaltest. Was ist dann der Status der Gruppe?

Probier es über die einzelnen Lampen!

Also ein
defmod OG_Kind_DI1 HUEDevice 29  IODev=HUE_0
hat hinterher einen funktionierenden state. Ggf. legst Du noch eine FHEM-structure darüber.

Grüße


FHEM 6.0 auf raspi3&ODROID XU4 mit HMLAN und HM-MOD-RPI-PCB, LaCrosse via JeeLink, COC868 und CUL433, Xiaomi Aqara+div. Zigbee via deCONZ, Dooya via SIGNALDuino, ZWave mit Danalock
Jeder Witz kann ein Einzeiler sein mit genügend Semikolons

Beta-User

Zitat von: alanblack am 03 Januar 2022, 15:56:13
Irgendwo hatte ich in einem Phoscon-Thread gelesen, dass für Gruppen der Status nicht funktioniert.
Geht, wo ist das Problem?

Anfangen mit "createGroupReadings". Mehr Tipps gibt es ggf., falls was anderes wie screenshots geliefert wird...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

taskkill

defmod LIGHTIFYGroup1 HUEDevice group 1  IODev=Osram
attr LIGHTIFYGroup1 userattr createActionReadings:1,0 createGroupReadings:1,0
attr LIGHTIFYGroup1 IODev Osram
attr LIGHTIFYGroup1 alias Stehlampe
attr LIGHTIFYGroup1 color-icons 2
attr LIGHTIFYGroup1 createGroupReadings 1
attr LIGHTIFYGroup1 delayedUpdate 1
attr LIGHTIFYGroup1 devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
attr LIGHTIFYGroup1 room HOME,LIGHTIFY

setstate LIGHTIFYGroup1 2022-01-03 16:35:15 IODev Osram



Gruppendevice Typ Huedevice

defmod Osram LIGHTIFY 192.168.178.76
attr Osram pollDevices 1
attr Osram room LIGHTIFY

setstate Osram connected
setstate Osram 2022-01-03 16:35:27 lastError for cmd: 68: err: 15
setstate Osram 2022-01-03 16:42:05 state connected



bridge Typ Lightify

keine Attr.createGroupReadings
RPI 3B+ mit Raspbian Bullseye auf SSD, aktiver USB-Hub, Fhem (is klar), TI CC2652P, nanoCUL 868 WMBUS, Echo Plus 2te Gen., ESPxxxx, usw.

Beta-User

Zitat von: taskkill am 03 Januar 2022, 16:47:08
keine Attr.createGroupReadings
Doch. Das scheint aber bei diesem GW-Typ keine Auswirkungen zu haben:
Zitat

setstate LIGHTIFYGroup1 2022-01-03 16:35:15 IODev Osram


Bei mir (deconz) sieht das auszugsweise so aus:
attr Licht_Essen devStateIcon gr.1:on:off gr.0:off:on
attr Licht_Essen stateFormat gr:any_on
attr Licht_Essen webCmd pct:ct

setstate Licht_Essen gr:1
setstate Licht_Essen 2022-01-03 16:24:31 all_on 1
setstate Licht_Essen 2022-01-03 16:24:31 any_on 1


Weiß nicht, ob man da bei LIGHTIFY auch noch irgendwas setzen kann, auf die Schnelle gibt die commandref nichts her. Vielleicht verschiebst du den Thread nach ZigBee und änderst den Titel so, dass justme1968 erkennen kann, wo dein Problem liegt, ansonsten wäre es vielleicht auch eine gute Investition, die Pferde zu wechseln...?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

alanblack

Zitat von: Beta-User am 03 Januar 2022, 17:10:29
Doch. Das scheint aber bei diesem GW-Typ keine Auswirkungen zu haben:

Das müsste an etwas anderem liegen, denn mit deconz

defmod HUEGroup19 HUEDevice group 19  IODev=HUE_0
attr HUEGroup19 userattr createActionReadings:1,0 createGroupReadings:1,0
attr HUEGroup19 IODev HUE_0
attr HUEGroup19 color-icons 2
attr HUEGroup19 delayedUpdate 1
attr HUEGroup19 devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
attr HUEGroup19 group HUEGroup
attr HUEGroup19 room HUEDevice

setstate HUEGroup19 2021-12-30 21:29:57 IODev HUE_0
setstate HUEGroup19 2022-01-03 17:21:08 all_on 0
setstate HUEGroup19 2022-01-03 17:21:08 any_on 0

hatte ich die GroupReadings auch noch nicht gesehen.

Grüße
FHEM 6.0 auf raspi3&ODROID XU4 mit HMLAN und HM-MOD-RPI-PCB, LaCrosse via JeeLink, COC868 und CUL433, Xiaomi Aqara+div. Zigbee via deCONZ, Dooya via SIGNALDuino, ZWave mit Danalock
Jeder Witz kann ein Einzeiler sein mit genügend Semikolons

Beta-User

...und was ist das...?!?
Zitat von: alanblack am 03 Januar 2022, 17:53:02
setstate HUEGroup19 2022-01-03 17:21:08 all_on 0
setstate HUEGroup19 2022-01-03 17:21:08 any_on 0

hatte ich die GroupReadings auch noch nicht gesehen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

JensS

#7
Für das LIGHTIFY-Gruppendevice mit dem Type HUEDevice gibt es kein passendes huedevice.template.
Genaugenommen dürfte nicht mal ein "STATE" gesetzt werden können.
Seltsam dass es keinen eigenen LIGHTIFYGroup-Type gibt und dafür automatisch ein HUEDevice angelegt wird.
30_LIGHTIFY.pm hat einige vorgesehene Routinen, die im Sande verlaufen, wie "getGroupInfo", "getGroup", etc..

Gruß Jens
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten, zigbee2mqtt, ESPEasy etc.

alanblack

#8
Zitat von: Beta-User am 03 Januar 2022, 18:00:24
...und was ist das...?!?
[all_on und any_on]
Die zählen dazu? Ok! Die sind bei mir auch da, aber auch, wenn ich "createGroupReadings" (nicht ...Action...) auf 0 gesetzt hatte.

Aber was ist mit
gr:any_on
gr.1:on:off gr.0:off:on

?
Hast Du das hier
https://forum.fhem.de/index.php/topic,81711.msg757691.html#msg757691
in ähnlicher Form noch laufen?

Zitat von: JensS am 03 Januar 2022, 19:10:25
Für das LIGHTIFY-Gruppendevice mit dem Type HUEDevice gibt es kein passendes huedevice.template.
Genaugenommen dürfte nicht mal ein "STATE" gesetzt werden können.
Seltsam dass es keinen eigenen LIGHTIFYGroup-Type gibt und dafür automatisch ein HUEDevice angelegt wird.
30_LIGHTIFY.pm hat einige vorgesehene Routinen, die im Sande verlaufen, wie "getGroupInfo", "getGroup", etc..

Gruß Jens
Ok, das erklärt es dann. Danke!
Grüße

FHEM 6.0 auf raspi3&ODROID XU4 mit HMLAN und HM-MOD-RPI-PCB, LaCrosse via JeeLink, COC868 und CUL433, Xiaomi Aqara+div. Zigbee via deCONZ, Dooya via SIGNALDuino, ZWave mit Danalock
Jeder Witz kann ein Einzeiler sein mit genügend Semikolons

Beta-User

Zitat von: alanblack am 03 Januar 2022, 19:21:54
Die zählen dazu? Ok! Die sind bei mir auch da, aber auch, wenn ich "createGroupReadings" (nicht ...Action...) auf 0 gesetzt hatte.

Aber was ist mit
gr:any_on
gr.1:on:off gr.0:off:on

?
...das sind meine Einstellungen, und damit klappt das - ganz ohne irgendwelchen externen Perl-Code...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

taskkill

Internals:
   DEF        group 2  IODev=Osram
   FUUID      61d1c4bd-f33f-9a8d-2a37-6bbcb25676ee874e
   FVERSION   31_HUEDevice.pm:0.253510/2021-12-17
   ID         G2
   INTERVAL   
   IODev      Osram
   NAME       LIGHTIFYGroup2
   NR         110
   STATE      gr:any_on
   TYPE       HUEDevice
   desired    1
   lights     E38A0B0000261884,B7710B0000261884,D5FE070000261884
   READINGS:
     2022-01-03 18:11:26   IODev           Osram
   helper:
     all_on     -1
     any_on     -1
     devtype    G
     on         -1
     update_timeout 1
     json:
Attributes:
   IODev      Osram
   alias      Wohnzimmer
   color-icons 2
   createActionReadings 1
   createGroupReadings 1
   delayedUpdate 1
   devStateIcon gr.1:on:off gr.0:off:on
   room       HOME,LIGHTIFY
   stateFormat gr:any_on
   subType    dimmer
   userattr   createActionReadings:1,0 createGroupReadings:1,0
   webCmd     on:off


geht bei mir leider nicht
RPI 3B+ mit Raspbian Bullseye auf SSD, aktiver USB-Hub, Fhem (is klar), TI CC2652P, nanoCUL 868 WMBUS, Echo Plus 2te Gen., ESPxxxx, usw.

Beta-User

Zitat von: taskkill am 03 Januar 2022, 20:36:03
Internals:
   DEF        group 2  IODev=Osram
   FUUID      61d1c4bd-f33f-9a8d-2a37-6bbcb25676ee874e
   FVERSION   31_HUEDevice.pm:0.253510/2021-12-17
   ID         G2
   INTERVAL   
   IODev      Osram
   NAME       LIGHTIFYGroup2
   NR         110
   STATE      gr:any_on
   TYPE       HUEDevice
   desired    1
   lights     E38A0B0000261884,B7710B0000261884,D5FE070000261884
   READINGS:
     2022-01-03 18:11:26   IODev           Osram
   helper:
     all_on     -1
     any_on     -1
     devtype    G
     on         -1
     update_timeout 1
     json:
Attributes:
   IODev      Osram
   alias      Wohnzimmer
   color-icons 2
   createActionReadings 1
   createGroupReadings 1
   delayedUpdate 1
   devStateIcon gr.1:on:off gr.0:off:on
   room       HOME,LIGHTIFY
   stateFormat gr:any_on
   subType    dimmer
   userattr   createActionReadings:1,0 createGroupReadings:1,0
   webCmd     on:off


geht bei mir leider nicht
qed. Daher hatte ich geschrieben:
Zitat von: Beta-User am 03 Januar 2022, 17:10:29
Doch. Das scheint aber bei diesem GW-Typ keine Auswirkungen zu haben:

[...]
Weiß nicht, ob man da bei LIGHTIFY auch noch irgendwas setzen kann, auf die Schnelle gibt die commandref nichts her. Vielleicht verschiebst du den Thread nach ZigBee und änderst den Titel so, dass justme1968 erkennen kann, wo dein Problem liegt, ansonsten wäre es vielleicht auch eine gute Investition, die Pferde zu wechseln...?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

alanblack

Die mögliche Lösung, die habe ich von hier https://forum.fhem.de/index.php/topic,81711.msg759257.html#msg759257
Zitatzum testen reicht es wenn man im Bridge device createGroupReadings auf 1 setzt.
Grüße
FHEM 6.0 auf raspi3&ODROID XU4 mit HMLAN und HM-MOD-RPI-PCB, LaCrosse via JeeLink, COC868 und CUL433, Xiaomi Aqara+div. Zigbee via deCONZ, Dooya via SIGNALDuino, ZWave mit Danalock
Jeder Witz kann ein Einzeiler sein mit genügend Semikolons