Hallo zusammen,
ich habe alle Lichter im EG in einem Structure zusammengefasst.
Zwei Lampen sind HM Dimmer und eine ist ein FS20 Dimmer.
Mein Problem ist nun, dass die beiden HM Dimmer brav an und aus schalten, der FS20 jedoch nicht geschaltet wird. Das Icon ändert sich allerdings auf on oder off. Nur bei dem Dimmer kommt nichts an.
Direkt über das Webinterface, oder Schalter schaltet er problemlos ohne Verzögerung.
Nehme ich nur den FS20 Dimmer in die Structure, schaltet er auch ohne Probleme.
Im Log steht folgendes: (Loglevel 3)
2014.08.31 22:17:31 3: CUL_HM set EG_KU_DI off
2014.08.31 22:17:31 3: FS20 set EG_KU_DL off
2014.08.31 22:17:31 3: CUL_HM set EG_KZ_DI off
Structure sieht folgendermaßen aus:
define ST_HI_Licht structure room EG_KZ_DI EG_KU_DI EG_KU_DL
attr ST_HI_Licht room Licht
Ich habe den FS20 Dimmer schon an allen Positionen gehabt. Habe ihn sogar schon zweimal drin gehabt. Nix zu machen. Schaltet einfach nicht im Structure wenn mit HM zusammen.
Irgend ne Idee, was ich da machen kann?
Ich hatte gestern bei der Suche einen ähnlichen Beitrag gesehen, finde ihn aber leider nicht mehr :-(
Beste Grüße,
Sebastian
Kannst Du bitte den structure-Schaltvorgang mit "attr global verbose 5" protokollieren und das Log hier anhaengen.
Here you go...
Hab mal alles aus dem Log gefischt, was mit dem Dimmer nach Loglevel = 5 und Restart von Fhem gelogged wurde:
2014.09.01 11:36:18 5: Cmd: >attr global userattr EG_KU_DI EG_KU_DI_map EG_KU_DL EG_KU_DL_map EG_KZ_DI EG_KZ_DI_map devStateIcon
2014.09.01 11:36:29 5: Cmd: >define ST_HI_Licht structure room EG_KU_DL EG_KZ_DI EG_KU_DI<
2014.09.01 11:36:29 5: Loading ./FHEM/98_structure.pm
2014.09.01 11:36:30 5: Cmd: >attr ST_HI_Licht group Dimmer<
2014.09.01 11:36:30 5: Cmd: >attr ST_HI_Licht room Licht<
2014.09.01 11:51:47 5: Triggering NF_Presence_Licht_Aus
2014.09.01 11:51:47 4: NF_Presence_Licht_Aus exec set ST_HI_Licht off
2014.09.01 11:51:47 5: Cmd: >set ST_HI_Licht off<
2014.09.01 11:51:47 5: CUL_HM EG_KU_DI protEvent:CMDs_pending pending:1
2014.09.01 11:51:47 5: Triggering EG_KU_DI (1 changes)
2014.09.01 11:51:47 5: Notify loop for EG_KU_DI set_off
2014.09.01 11:51:48 4: eventTypes: CUL_HM EG_KU_DI set_off -> set_off
2014.09.01 11:51:48 4: eventTypes: CUL_HM EG_KU_DI state: set_off -> state: set_off
2014.09.01 11:51:48 3: CUL_HM set EG_KU_DI off
2014.09.01 11:51:48 5: HMLAN_Send: HMLAN1 S:+188566,00,01,00
2014.09.01 11:51:48 5: HMLAN_Send: HMLAN1 S:S30A0A881 stat: 00 t:00000000 d:01 r:30A0A881 m:2E A011 2574C4 188566 0201000000
2014.09.01 11:51:48 5: CUL_HM EG_KU_DI protEvent:CMDs_processing... pending:0
2014.09.01 11:51:48 3: FS20 set EG_KU_DL off
2014.09.01 11:51:48 5: Sending 8109041301010177990000
2014.09.01 11:51:48 5: Triggering EG_KU_DL (1 changes)
2014.09.01 11:51:48 5: Notify loop for EG_KU_DL off
2014.09.01 11:51:48 4: eventTypes: FS20 EG_KU_DL off -> off
2014.09.01 11:51:48 4: eventTypes: FS20 EG_KU_DL state: off -> state: off
2014.09.01 11:51:48 5: CUL_HM EG_KZ_DI protEvent:CMDs_pending pending:1
2014.09.01 11:51:48 5: Triggering EG_KZ_DI (1 changes)
2014.09.01 11:51:48 5: Notify loop for EG_KZ_DI set_off
2014.09.01 11:51:48 4: eventTypes: CUL_HM EG_KZ_DI set_off -> set_off
2014.09.01 11:51:48 4: eventTypes: CUL_HM EG_KZ_DI state: set_off -> state: set_off
2014.09.01 11:51:48 3: CUL_HM set EG_KZ_DI off
2014.09.01 11:51:48 5: Triggering ST_HI_Licht (1 changes)
2014.09.01 11:51:48 5: Notify loop for ST_HI_Licht off
2014.09.01 11:51:48 4: eventTypes: structure ST_HI_Licht off -> off
2014.09.01 11:51:48 4: eventTypes: dummy HomeStatus 0 -> .*
2014.09.01 11:51:48 4: eventTypes: dummy HomeStatus state: 0 -> state: .*
2014.09.01 11:51:48 5: HMLAN/RAW: /R30A0A881,0001,33E89FBA,FF,FFB5,2E80021885662574C40101000046
2014.09.01 11:51:48 5: HMLAN_Parse: HMLAN1 R:R30A0A881 stat:0001 t:33E89FBA d:FF r:FFB5 m:2E 8002 188566 2574C4 0101000046
2014.09.01 11:51:48 5: HMLAN1 dispatch A0E2E80021885662574C40101000046::-75:HMLAN1
2014.09.01 11:51:48 5: CUL_HM EG_KU_DI protEvent:CMDs_done
2014.09.01 11:51:48 5: Triggering EG_KU_DI (1 changes)
2014.09.01 11:51:48 5: Notify loop for EG_KU_DI off
2014.09.01 11:51:48 5: Update structure 'ST_HI_Licht' to undefined because device EG_KU_DI has changed
2014.09.01 11:51:48 5: Triggering ST_HI_Licht (3 changes)
2014.09.01 11:51:48 5: Notify loop for ST_HI_Licht LastDevice: EG_KU_DI
2014.09.01 11:51:48 4: eventTypes: structure ST_HI_Licht LastDevice: EG_KU_DI -> LastDevice: EG_KU_DI
2014.09.01 11:51:48 4: eventTypes: structure ST_HI_Licht LastDevice_Abs: EG_KU_DI -> LastDevice_Abs: EG_KU_DI
2014.09.01 11:51:48 4: eventTypes: structure ST_HI_Licht undefined -> undefined
2014.09.01 11:51:48 4: eventTypes: structure ST_HI_Licht state: undefined -> state: undefined
2014.09.01 11:51:48 4: eventTypes: CUL_HM EG_KU_DI off -> off
2014.09.01 11:51:48 4: eventTypes: CUL_HM EG_KU_DI state: off -> state: off
2014.09.01 11:51:48 5: HMLAN_Send: HMLAN1 S:+188523,00,01,00
2014.09.01 11:51:48 5: HMLAN_Send: HMLAN1 S:S30A0AA73 stat: 00 t:00000000 d:01 r:30A0AA73 m:2F A011 2574C4 188523 0201000000
2014.09.01 11:51:48 5: CUL_HM EG_KZ_DI protEvent:CMDs_processing... pending:0
2014.09.01 11:51:48 5: HMLAN/RAW: /E13E8C9,0000,33E8A0B2,FF,FFBF,1EA25813E8C913F19C0000
2014.09.01 11:51:48 5: HMLAN_Parse: HMLAN1 R:E13E8C9 stat:0000 t:33E8A0B2 d:FF r:FFBF m:1E A258 13E8C9 13F19C 0000
2014.09.01 11:51:48 5: HMLAN1 dispatch A0B1EA25813E8C913F19C0000::-65:HMLAN1
2014.09.01 11:51:48 5: Triggering EG_KZ_V1 (2 changes)
2014.09.01 11:51:48 5: Notify loop for EG_KZ_V1 set_0
2014.09.01 11:51:48 4: eventTypes: CUL_HM EG_KZ_V1 set_0 -> set_.*
2014.09.01 11:51:48 4: eventTypes: CUL_HM EG_KZ_V1 ValveDesired: 0 -> ValveDesired: .*
2014.09.01 11:51:48 4: eventTypes: CUL_HM EG_KZ_V1 state: set_0 -> state: set_.*
2014.09.01 11:51:48 5: HMLAN/RAW: /R30A0AA73,0001,33E8A0E3,FF,FFC8,2F80021885232574C40101000038
2014.09.01 11:51:48 5: HMLAN_Parse: HMLAN1 R:R30A0AA73 stat:0001 t:33E8A0E3 d:FF r:FFC8 m:2F 8002 188523 2574C4 0101000038
2014.09.01 11:51:48 5: HMLAN1 dispatch A0E2F80021885232574C40101000038::-56:HMLAN1
2014.09.01 11:51:48 5: CUL_HM EG_KZ_DI protEvent:CMDs_done
2014.09.01 11:51:48 5: Triggering EG_KZ_DI (1 changes)
2014.09.01 11:51:48 5: Notify loop for EG_KZ_DI off
2014.09.01 11:51:48 5: Update structure 'ST_HI_Licht' to off because device EG_KZ_DI has changed
2014.09.01 11:51:48 5: Triggering ST_HI_Licht (3 changes)
2014.09.01 11:51:48 5: Notify loop for ST_HI_Licht LastDevice: EG_KZ_DI
2014.09.01 11:51:48 4: eventTypes: structure ST_HI_Licht LastDevice: EG_KZ_DI -> LastDevice: EG_KZ_DI
2014.09.01 11:51:48 4: eventTypes: structure ST_HI_Licht LastDevice_Abs: EG_KZ_DI -> LastDevice_Abs: EG_KZ_DI
2014.09.01 11:51:48 4: eventTypes: structure ST_HI_Licht off -> off
2014.09.01 11:51:48 4: eventTypes: structure ST_HI_Licht state: off -> state: off
2014.09.01 11:51:48 4: eventTypes: CUL_HM EG_KZ_DI off -> off
2014.09.01 11:51:48 4: eventTypes: CUL_HM EG_KZ_DI state: off -> state: off
Danke schon mal!
Sebastian
Ich vermute, dass das FHZ1x00 loslegt, und die parallel gesendeten HMLAN Signale den Sendevorgang stoeren. Koenntest du diese Theorie testen, indem du in FHEM/00_FHZ.pm jeweils nach der Zeile mit
$hash->{PortObj}->write($bstring) if($hash->{PortObj});
folgende einfuegst (es sind zwei solche Zeilen):
sleep(1);
und es mit dem Schalten wieder versuchst.
Wenn du fuer beide Protokolle ein CUL verwenden wuerdest, dann koennte man beide mit dem sendpool Attribut versehen, um das Problem zu loesen. So ist aber Programmcode notwendig, um das Problem richtig zu loesen.
Etwas ähnliches hatte ich, bei der Kombination von FS20-Dosen und PCA301 als local master. Ein sleep 0.5 quiet zwischen den Befehlen half. Dabei habe ich allerdings keine Struktur verwendet sonder nur die Befehle kombiniert.
Wobei ich ebenfalls den Verdacht hege, dass sich bei mir die Signale der beiden nah beieinandersitzenden Sticks (cul, jeelink) gegenseitig beeinträchtigen.
In meinen Szenario kann ich rudolfkoenigs Theorie bestätigen.
Gesendet von meinem iPhone mit Tapatalk
das scheint geholfen zu haben.
Ich werde das noch weiter beobachten.
Entstehen daraus irgendwelche Nachteile?
Was passiert bei einem Update? Wird die Datei dann durch eine neue ersetzt?
ZitatEntstehen daraus irgendwelche Nachteile?
Ja, FHEM ist in dieser Zeit blockiert, und mindestens HM fuehlt sich dadurch benachteiligt. Die anderen Module evtl. auch. War auch nicht als Loesung sondern als Beweis fuer meine Theorie gedacht.
ZitatWird die Datei dann durch eine neue ersetzt?
Ja, allerdings ist die Gefahr gering, dass ich an dem FHZ Modul etwas aendere.
Hoechstens nur um genau dieses Problem zu beheben.
gut, ich habe nur das eine FS20 device. Da sollten sich die Auswirkungen in Grenzen halten.
Ich lasse das erst mal so und warte ab ob es einen finalen Fix gibt.
habe in den letzten Tagen Fhem neu installiert und bin wieder in das Problem gelaufen.
Es hat sich herausgestellt, dass das Update die angepasste Datei überschreibt, auch wenn sich daran nichts geändert hat.
Lösung:
exclude_from_update angelegt und die Datei 00_FHZ.pm wurde nicht mehr vom Update überschrieben.
attr global exclude_from_update 00_FHZ.pm