deCONZ - configuration tool wird immer zu hue Lampe geändert

Begonnen von rcmcronny, 04 April 2020, 08:35:38

Vorheriges Thema - Nächstes Thema

rcmcronny

Hallo,

das Configuration Tool (bei mir DevID 4) verhält sich komisch, eigentlich brauch ich es ja gar nicht, da es aber sonst bemerkert wird, habe ich es hinzugefügt. Leider wird es automatisch nach kurzer Zeit geändert auf DevID 1 (was einer Hue Lampe entspricht) Auch devStateIcon und webCmd  wird immer automatisch wieder hinzugefügt, bringt aber ja nix.



#hier wurde ein update gemacht und fhem neugestartet
2020.04.03 08:32:54 3: deCONZ_HUEGroup4: I/O device is deCONZ
[...]
2020.04.03 13:16:08 2: moving deCONZ_HUEDevice4 [00:21:2e:ff:ff:05:4d:cd-01] from deCONZ to deCONZ
2020.04.03 13:16:08 3: deCONZ_HUEDevice4: I/O device is deCONZ
[...]
2020.04.03 13:18:56 3: deCONZ: message for unknown device received: deCONZ-4
[...]


Vielleicht kann man ja den type "Configuration tool" anders behandeln ?


Hier ein List des Devices bevor es mit ID1 angepaßt wird :)


Internals:
   DEF        4  IODev=deCONZ
   FUUID      5e6a62c5-f33f-e150-32a5-bae99c377c2503f2
   FVERSION   31_HUEDevice.pm:0.214800/2020-03-22
   ID         4
   INTERVAL   
   IODev      deCONZ
   NAME       deCONZ_HUEDevice4
   NR         234
   STATE      on
   TYPE       HUEDevice
   manufacturername dresden elektronik
   modelid    ConBee II
   name       Configuration tool 4
   swversion  0x26530700
   type       Configuration tool
   uniqueid   00:21:2e:ff:ff:05:4d:cd-01
   READINGS:
     2020-04-03 13:16:56   alert           none
     2020-04-03 13:16:56   bri             254
     2020-04-03 13:16:56   colormode       ct
     2020-04-03 13:16:56   ct              380 (2631K)
     2020-04-03 13:16:56   effect          none
     2020-04-03 13:16:56   hue             10953
     2020-04-03 13:16:56   onoff           0
     2020-04-04 08:26:52   pct             100
     2020-04-04 08:26:52   reachable       1
     2020-04-03 13:16:56   rgb             ffc494
     2020-04-03 13:16:56   sat             254
     2020-04-04 08:26:52   state           on
     2020-04-03 13:16:56   xy              0.5267,0.4133
   helper:
     alert     
     battery    -1
     bri        -1
     colormode 
     ct         -1
     devtype   
     effect     
     hue        -1
     mode       
     on         -1
     pct        100
     reachable  1
     rgb       
     sat        -1
     update_timeout 1
     xy         
     json:
       etag       0675569571583c25ccd4a17c5d64448f
       manufacturername dresden elektronik
       modelid    ConBee II
       name       Configuration tool 4
       swversion  0x26530700
       type       Configuration tool
       uniqueid   00:21:2e:ff:ff:05:4d:cd-01
       state:
Attributes:
   IODev      deCONZ
   alias      Configuration tool 4
   color-icons 2
   devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
   group      HUEDevice
   model      ConBee II
   room       HUEDevice
   subType    extcolordimmer
   webCmd     rgb:rgb ff0000:rgb DEFF26:rgb 0000ff:ct 490:ct 380:ct 270:ct 160:toggle:on:off


Danke Ronny

siggel

#1
Ich kann auch so ein Problem bestätigen, nachdem ich ein Update gemacht habe.
Der (schon immer vorhandene) ConBee II Stick erscheint seitdem als (neues) HueDevice6 mit Lampenfunktion. Ich habe dafür dann Raum, Gruppe, Icon, ... definiert und war zufrieden - bis sich ohne mein Zutun die ID zu 1 änderte, die aber mit einer (aktuell nicht eingeschraubten) Glühlampe belegt ist. Diff fhem.cfg vorher nachher:

1666c1666
< define HUEDevice6 HUEDevice 6  IODev=ZigbeeGateway
---
> define HUEDevice6 HUEDevice 1 IODev=ZigbeeGateway
1675a1676
> attr HUEDevice6 subType dimmer

Im fhem Log tauchen dann minütlich Fehler auf:

2020.04.10 14:00:03 3: ZigbeeGateway: message for unknown device received: ZigbeeGateway-6
2020.04.10 14:00:03 3: ZigbeeGateway: message for unknown device received: ZigbeeGateway-1

Ein autocreate erzeugt wieder eine neue (!) Glühlampe mit ID1, die alte Instanz ist also im Eimer, und außerdem den ConBee II Stick wieder mit ID6.
Und dann geht das ganze nach einiger Zeit wieder von vorne los :( Die Kombi HueBridge und deCONZ scheint aktuell also unbrauchbar  >:(
RPi 3B+, ConBee II, OSRAM/Ledvance Plug/Light/Switch mini, Aqara Contact/Multisensor/Motion Sensor/Magic Cube, IKEA Tradfri Dimmer/Switch, Shelly 1/1PM/2.5/i3/uni/Plug S, Gosund SP111 (Tasmota), D1mini (Tasmota/WLED), Echo Dot, Fire Tablet (FTUI), Indego, Homematic IP CCU3/eTRV2/eTRV-B/STHO-A

siggel

Möglicherweise ein Workaround:

  • Ich habe in Phoscon nachgesehen und da den ConBeeII auch als Gerät mit Symbol Glühlampe und ID 6 gefunden. Dort habe ich ihn dann gelöscht.
  • Mit einem Autodetect - aus fhem heraus - wurde er prompt wieder angelegt, diesmal als Unknown mit ID 7. Also erneut gelöscht und das autodetect besser künftig sein lassen...
  • Dann nochmal alle vorigen Instanzen in fhem gelöscht (ConBeeII Stick und die Glühlampe mit der kollidierenden ID 1)
  • Dann in fhem ein autocreate, das hat dann nur die Glühlampe neu angelegt
Im Log sind nun keine Fehler mehr. Ich hoffe, dass das so bleibt und nicht trotzdem von selbst wieder der ConBeeII in fhem auftaucht und erneut ID-Kollisionen entstehen.
RPi 3B+, ConBee II, OSRAM/Ledvance Plug/Light/Switch mini, Aqara Contact/Multisensor/Motion Sensor/Magic Cube, IKEA Tradfri Dimmer/Switch, Shelly 1/1PM/2.5/i3/uni/Plug S, Gosund SP111 (Tasmota), D1mini (Tasmota/WLED), Echo Dot, Fire Tablet (FTUI), Indego, Homematic IP CCU3/eTRV2/eTRV-B/STHO-A

justme1968

ich bräuchte mal ein log mit verbose 5 wenn es diese probleme gibt.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

justme1968

ich habe eben eine änderung eingecheckt mit der das problem unter umständen behoben ist.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

rcmcronny

Danke Andre,

ich habe verbose 5 laufen, bisher ist es noch nicht wieder passiert, dauert manchmal etwas leider.

Ronny

rcmcronny

Hi,

das hier scheint es zu sein, wenn ich die uniqueid anschaue. Das scheint mir aber der virtuelle Tageslichtsensor zu sein, keine Ahnung ,warum da das Huedevice4 (das Configuration Tool) angepaßt wird.
Genau ab dem Zeitpunkt, hat HueDevice4 nun das Dev  geändert


ALT:  DEF 4 IODev=deCONZ
NEU: DEF 1 IODev=deCONZ



2020.04.16 21:28:02 5: deCONZ: websocket data: $VAR1 = {
  'e' => 'changed',
  'id' => '1',
  'r' => 'sensors',
  'state' => {
    'dark' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' ),
    'daylight' => bless( do{\(my $o = 0)}, 'JSON::PP::Boolean' ),
    'lastupdated' => '2020-04-16T19:28:02',
    'status' => 220,
    'sunrise' => '2020-04-16T04:15:33',
    'sunset' => '2020-04-16T18:09:25'
  },
  't' => 'event',
  'uniqueid' => '00:21:2e:ff:ff:05:4d:cd-01'
};

2020.04.16 21:28:02 2: moving deCONZ_HUEDevice4 [00:21:2e:ff:ff:05:4d:cd-01] from deCONZ to deCONZ
2020.04.16 21:28:02 3: deCONZ_HUEDevice4: I/O device is deCONZ


Achja, der Sensor ist im FHEM nicht eingebunden,

Ronny

justme1968

wenn ich das richtig sehe hat der stick aus dem listing ganz oben die gleiche uniqueid wie der sensor?

wenn ja: bitte auf github bei deCONZ als fehler melden.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

rcmcronny

Hi,

ja, sieht wirklich so aus, wobei aber sensor != light ist, ich habe nen issue mal aufgemacht:
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2698

Ronny

rcmcronny

Seit dem Fix vom 16.4. von Dir, tritt aktuell das Verhalten bei mir auch nicht mehr auf :)

Ronny

Gunther

wofür ist das configuration tool eigentlich gut? Hatte das (soweit ich weiß) vor meinem Deconz-Update nicht.
FHEM@Proxmox@Nuc: TabletUI als User-Interface (4 Wandtablets) / IOs per ser2net gekapselt
Homematic: Heizung, Fenster, Bewegung | Jeelink: Temperatur | Z-Wave: Bewegung, Temperatur | FS20: Temperatur, Fenster | Viessmann-Heizung eingebunden