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
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 >:(
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.
ich bräuchte mal ein log mit verbose 5 wenn es diese probleme gibt.
ich habe eben eine änderung eingecheckt mit der das problem unter umständen behoben ist.
Danke Andre,
ich habe verbose 5 laufen, bisher ist es noch nicht wieder passiert, dauert manchmal etwas leider.
Ronny
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
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.
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
Seit dem Fix vom 16.4. von Dir, tritt aktuell das Verhalten bei mir auch nicht mehr auf :)
Ronny
wofür ist das configuration tool eigentlich gut? Hatte das (soweit ich weiß) vor meinem Deconz-Update nicht.