gelöst: HUE Schalter nach Umzug von FHEM Server langsam

Begonnen von geiercasi, 04 Juli 2016, 11:10:42

Vorheriges Thema - Nächstes Thema

geiercasi

Moin Moin Zusammen,

nach dem Umzug des FHEM Servers auf einen VServer schaltet das Licht sehr verzögert.
Die HUE Bridge, Lampen, Schalter, Kontakte, Etc scheinen sauber erkannt zu sein. Wenn nun am Schalter (alle mit Dimmer) geschaltet wird, leuchtet dessen LED sofort grün. Das Licht ändert seinen Zustand aber erst nach ca 45 Sekunden.
Die Hardware hat langeweile, Max2% CPU, kein Swap, Load avarage 0.10 0.09 0.03.
Ich habe die Brdiges am neuen Server gepairt, dann die Config von der alten Maschiene ohne anpassungen verwendet. Die Config des Pair vorgangs ist seperat gespeichert.
Im FHEM Log gibt es ständig "Device is not available." als Medlung. Keine AHnung, welches gemeint ist :) Ein "update all" ist gemacht.
Könnt Ihr mir bitte auf die Sprünge helfen ?

Gruß und danke

P.S. Due HM Lan Kontakte schalten Das Licht ohne Verzögerung. auch das Webinterface braucht keine Pause

geiercasi

#1
das ist ein Schalter aus der Config:

define Schalter_Buero HUEDevice sensor 7 1 IODev=HUEBridge_whz
attr Schalter_Buero IODev HUEBridge_whz
attr Schalter_Buero color-icons 2
attr Schalter_Buero devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
attr Schalter_Buero group HUEGroup
attr Schalter_Buero room -Büro,.Schalter
attr Schalter_Buero subType dimmer

define Buerolicht_An notify Schalter_Buero:100.* set Taglicht_Buero on
define Buerolicht_Aus notify Schalter_Buero:400.* set Taglicht_Buero off

define Taglicht_Buero dummy
attr Taglicht_Buero room -Büro,.Lampen
define Taglicht_Buero_An notify Taglicht_Buero:on set HUEDevice17 rgb f93f0c;; set HUEDevice16 rgb ffba65
define Taglicht_Buero_Aus notify Taglicht_Buero:off set Buero_Lampe off

nach einem statusRequest im Webinterface wird der Zustand sofort geändert.

Tyllux

Hi,

vielleicht hilft das ja:

Korrigiere die "31_HUEDevice.pm", damit die Dimmer schneller reagieren.

In der Zeile mit folgendem Inhalt:

$interval = 60 if( $interval && $interval < 10 );

den Wert auf 1 heruntersetzen:

$interval = 60 if( $interval && $interval < 1 );

Sobald du allerdings ein Update deines FHEMs durchführst und auch die "31_HUEDevice.pm" aktualisiert werden sollte, ist diese Anpassung natürlich weg ..

geiercasi


Grindrand

Hallo zusammen,

Ich habe ein ähnliches Problem,
Ich habe ein Notify das auf einen Hue Dimschalter reagiert.
Das Notify braucht immer so zwischen 10-60 Sekunden bis es reagiert.

Ich steh ein bisschen auf dem Schlauch, wo finde ich diese 31_HUEDevice.pm ?
Unter Edit files finde ich die nicht.

MfG Christoph

binford6000

Hallo Christoph,
mal abgesehen davon dass der Thread hier über 6(!) Jahre alt ist und es zig Updates zu besagtem Modul gab würde ich an deiner Stelle...

a) ... nicht ohne Weiteres in Modulen rum editieren und...
b) eher noch ein paar Informationen zu deinem Setup liefern:
    - Welche Hardware setzt du ein?
    - Tritt der Fehler auch unter den nativen Apps (Philips HUE, IKEA, Deconz usw.) auf?
    - Löst das NOTIFY wirklich erst so spät aus? -> triggeredByDev triggeredByEvent Readings?
    - Was sagt der Event monitor wenn du den Dimmer betätigst?

Damit könnten wir dann evtl. etwas schneller Licht ins Dunkel bringen  ;D

VG Sebastian


Grindrand

Hallo Sebastian,

vielen Dank fürs bewahren vorm rumpfuschen in den Modulen.

Die Installation sieht folgendermaßen aus:

Fhem auf Raspberry mit CUL

Der zu Schaltende Aktuator ist ein FS20SU

Reagieren soll ein Notify auf einen Hue Dimmschalter (Schlafzimmerschalter_1:200.* set SZ_Deckenlampe off)




Wenn ich den FS20SU (SZ_Deckenlampe) in Fhem Schalte reagiert er sofort.

Wenn ich jetzt im Event Monitor Beobachte was passiert wenn ich den Dimmschalter betätige passiert etwas komisches.

2022-12-07 19:10:07 CUL_FHTTK FE_Spielezimmer Window: Closed
2022-12-07 19:10:07 CUL_FHTTK FE_Spielezimmer Reliability: ok
2022-12-07 19:10:07 CUL_FHTTK FE_Spielezimmer batteryState: ok
2022-12-07 19:10:07 CUL_FHTTK FE_Spielezimmer Closed
2022-12-07 19:10:24 FS20 SZ_Deckenlampe off
2022-12-07 19:09:57 HUEDevice Schlafzimmerschalter_1 2002
2022-12-07 19:09:57 HUEDevice Schlafzimmerschalter_1 reachable: 1
2022-12-07 19:09:57 HUEDevice Schlafzimmerschalter_1 batteryPercent: 100
2022-12-07 19:09:57 HUEDevice Schlafzimmerschalter_1 battery: 100

Ich habe den Schalter um 19:09:57 gedrückt aber er erscheint nicht im Event Monitor
erst passiert nichts dann kommt eine Info von einem Fensterschalter und um 19:10:24 geht das Licht aus und das Event des drückens vom Dimmschalter wird mit der Zeit gelockt zu der ich Ihn gedrückt habe.
Kann mein Fhem Zeitreisen?

mfg Christoph

binford6000

Hi Christoph,
das ist allerdings seltsam...
Aber wie ich bereits vor einer Woche gefragt habe:
- Gibt es diese Verzögerung auch am Gateway?
- Welches Gateway ist im Einsatz?


Grindrand

Ich weiß nicht hundert pro was Du mit Gateway meinst aber ich vermute du meinst die Hue Bridge.
Wenn ich in der Hue app auf den Dimmschalter gehe und drücke eine Taste erscheint dort unmittelbar "Taste gedrückt".
Also vom Dimmschalter zur Hue Bridge gibt es wohl keine Verzögerung.

moskito

Also wenn der Event Monitor die richtige Zeit erfasst, aber erst eine halbe Minute später zur Anzeige bringt, klingt das für mich so als würde FHEM blockiert.
Das schalten der Deckenlampe aus FHEM heraus funktioniert korrekt und ich denke mal das notify zum schalten wird das System auch nicht blockieren.
Dann bleibt eigentlich nur noch die Verbindung FHEM/HUE Bridge.
Damit habe ich aber leider keine Erfahrungen mehr, da ich vor langer Zeit zu deconz gewechselt bin.

Gruß
Danny
FHEM auf Intel NUC/Proxmox & Debian 12 + HM-CFG-USB + zigbee2mqtt + Zwave + Enocean

binford6000

Moin,
ja das klingt nach irgendwas blocking. Ein LogAUSSCHNITT mit verbose 4/5 könnte evtl. etwas mehr Infos liefern.

VG Sebastian

MadMax-FHEM

#11
Ich bin ja nicht so ganz sicher aber war/ist das nicht so:

deCONZ hat push

echte HUE-Bridge: da pollt doch das HUEBridge-Modul/-Device?

Außer man hat eine "Spezialversion" wo die (immer noch nicht offizielle?) push API von der HUE-Bridge (Philips) unterstützt wird?
Oder ist das schon in der offiziellen Version des HUEBridge-Moduls/-Devices (fhem) drin?

EDIT: https://forum.fhem.de/index.php/topic,122075.msg1166634.html#msg1166634
Aber ist wohl mittlerweile im Modul drin (?)

Kann aber auch sein, dass ich falsch liege...


Falls fhem blockiert: Freezemon?

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Sany

Ich hatte das beschriebene Verhalten nach einem Update von deConz:
-Lichter schalten von fhem aus sofort
- diverse Taster und Sensoren (hab nicht alle überprüft) melden sichtbar in der Phoscon-App, in fhem passiert aber erst 30-50sec später etwas. In den Logs steht dann aber der korrekte Zeitspempel. Fhem läuft ganz normal, kein freeze, da alles andere funktioniert.
Ein fhem-Neustart hat das Problem beseitigt.

Vielleicht hilfts.



Sany
fhem auf Zotac ZBox nano als LXC auf Proxmox, weitere LXC mit ZigBee2MQTT, MariaDB und Grafana. Homematic, FS20, mySensors, MQTT2, Tasmota, Shelly, Z-Wave  ....

Grindrand

Sorry für die Späte Antwort,

bin leider ein paar Tage mit Fieber im Bett gelegen.

Es ist mir jetzt extra peinlich dass das Problem nach einem Neustart vorerst weg ist, da meine Grundregel eigentlich besagt: erst mal alles neustarten......

mfg Christoph