[GELÖST] Philips DIM-Schalter u. Auslöseverzögerung (Conbee II/DeConz/Phoscon)

Begonnen von daedalus0815, 05 Januar 2024, 10:26:33

Vorheriges Thema - Nächstes Thema

daedalus0815

Hallo,

kleines Totzeitproblem  :(

...ich habe den Conbee II -Stick und die Phoscon SW 2.24.2 läuft im docker  (FHEM is uptodate).
Conbe II mit FW 26780700.

Löse ich den DIM-Schalter aus, sehe ich unmittelbar in der Phoscon SW die Auslösung.
In FHEM kommt das im Event-Monitor aber erst ca. 10s später an.

Diverse Neustarts FHEM/DeConz/Phoscon brachten keine Verbesserung.


defmod mydeconz HUEBridge 192.168.178.52:80
attr mydeconz DbLogExclude .*
attr mydeconz comment DEF 192.168.178.47:8081 66
attr mydeconz createEventTimestampReading 1
attr mydeconz eventstreamTimeout 43200
attr mydeconz httpUtils 1
attr mydeconz icon hue_filled_bridge_v2
attr mydeconz key xxxxxxxxxxx
attr mydeconz noshutdown 1
attr mydeconz queryAfterEvent 1
attr mydeconz room HUEDevice,Osram
attr mydeconz verbose 1

setstate mydeconz connected
setstate mydeconz 2020-12-18 19:24:02 alert none
setstate mydeconz 2024-01-05 07:33:17 groups 5
setstate mydeconz 2024-01-05 07:38:17 lastError Internal error, 951
setstate mydeconz 2020-12-19 17:14:46 lastseen 2020-12-19T09:05Z
setstate mydeconz 2024-01-05 09:59:12 lights 25
setstate mydeconz 2020-12-19 17:14:46 reachable 0
setstate mydeconz 2022-01-28 08:27:18 rules 8
setstate mydeconz 2022-01-28 08:27:18 scenes 0
setstate mydeconz 2022-01-28 08:27:18 schedules 0
setstate mydeconz 2023-03-26 11:25:42 sensors 17
setstate mydeconz 2024-01-05 10:19:12 state connected


Ein Downgrade der DeConz-SW auf 2.23.01 hat das gleiche Verhalten gezeigt.

docker run -d \
    --name=deconz15 \
    --restart=always \
    -p 80:80 \
    -p 443:443 \
    -v /etc/localtime:/etc/localtime:ro \
    -v /opt/deconz:/opt/deCONZ \
    --device=/dev/ttyACM0 \
    deconzcommunity/deconz:2.23.01   

Ansonsten gibt es keine Probleme im HUE network :-)

Internals:
   DEF        192.168.178.52:80
   FUUID      5fd0ed5e-f33f-71f8-62af-9e9477432eccc4d1
   FVERSION   30_HUEBridge.pm:0.264380/2022-09-22
   INTERVAL   60
   NAME       mydeconz
   NOTIFYDEV  global
   NR         473
   NTFY_ORDER 50-mydeconz
   STATE      connected
   TYPE       HUEBridge
   apiversion 1.16.0
   bridgeid   00212EFFFF065CE1
   eventCount 15
   host       192.168.178.52:80
   is_deCONZ  1
   mac        02:42:ac:11:00:02
   manufacturer Royal Philips Electronics
   modelName  Philips hue bridge 2015
   modelid    deCONZ
   name       Phoscon-GW
   swversion  2.24.2
   updatestate 0
   websocketport 443
   zigbeechannel 15


Hatte jemand das gleiche Problem ?...und es lösen können ?

daedalus0815

...hab' jetzt eine Info von Otto123 gefunden in:

https://forum.fhem.de/index.php?topic=119919.msg1143667#msg1143667


docker run -d \
    --name=deconz7 \
    -p 80:80 \
    -p 443:443 \
    --restart=always \
    -v /opt/deconz:/opt/deCONZ \
    --device=/dev/ttyACM0 \
    -e DECONZ_WEB_PORT=80 \
    -e DECONZ_WS_PORT=443 \
    deconzcommunity/deconz:stable 

... Schalter ist aber immer noch im Trödelmodus  :))

daedalus0815

#2
Gefunden.... ;D

In den Internals stand bei mir unter INTERVALL ein Leerstring, also quasi nix.

Dies scheint aus meiner Sicht eine Standardpause der Verarbeitung von ca. 10s zu provozieren....

Mit Intervall=1 (kleiner geht nicht)..läuft alles wie es soll.

defmod HUESwitch3 HUEDevice sensor 12 1 IODev=mydeconz

Ob das vom Modulentwickler so gedacht war, keine Ahnung  8)

bug or feature ?



P.S:
Zitat aus: https://forum.fhem.de/index.php?topic=50991.0
@CoolTux:
Die Ausführung des Schaltvorganges findet übrigens nicht sofort statt, sondern wirklich in der Zeit des eingestellten Intervalls. Schade eigentlich. Aber mit 1 Sekunde ist das vollkommen o. k.