[HM-WIRED] HMW_IO_12_Sw7_DR Zustandsänderungen nicht bei allen Kanälen

[mago0211]

Hallo zusammen,

wie der Titel schon vermuten lässt habe ich bei manchen Switch Kanälen Problem das Stateänderungen korrekt gemeldet werden.

Grundsätzlich ist es bei mir so das die Taster und die Switches intern gepaart sind. Über Fhem werden dann noch evtl. Zusatzfunktionen ausgelöst.

Schalte ich eine Switch über Fhem ist alles wunderbar. Die States werden korrekt aktualisiert.
Schalte ich aber über den Taster kommen bei manchen Switches der neue State nicht in Fhem an. Konkret ist das bei mir Kanal 13 und 16 des HMW_IO_12_Sw7_DR.

Kurzfristig habe ich mir mit einem notify geholfen der nach einem Taster druck den aktuellen State abholt.

Code Auswählen Erweitern


HMW_IO_12_Sw7_DR_JEQ0310645_01:.* sleep 0.5;
get HMW_IO_12_Sw7_DR_JEQ0310645_13 state;
get HMW_IO_12_Sw7_DR_JEQ0310645_16 state;

Das kann aber auch nicht die goldene Lösung sein.

Da ich die Vermutung hatte das evtl. mit der Fhem HM485 Anbindung zu tun hat habe ich auf einem Raspberry https://github.com/jens-maus/RaspberryMatic installiert. Aber auch hier das gleiche Fehlerbild. Also würde ich die Implementierung als Fehlerquelle ausschließen.

Auf meinem Bus hängen derzeit zwei HMW_IO_12_Sw7_DR. Bei dem zweiten habe ich das Fehlerbild auch nur auf anderen Kanälen dort ist z.b. der Switch Kanal 15 betroffen.
Ich nutze das Originale LAN-Gateway von Homematic/eq3 Busabschluss ist auch vorhanden.

Firmware Version von meinem LAN-Gateway ist 1.0.5 (ich denke das müsste die aktuellste sein.)

Hat dieses Verhalten von euch schon mal jemand beobachtet. Ich bin ehrlich gesagt einigermaßen ratlos an was das liegen könnte?

Im Anhang sind noch screenshots mit der Peering config des betroffenen kanals. Evtl. ist ja dort was falsch?

Das HM485-Fhem modul ist ebenfalls auf dem aktuellen Stand aus Git-Hub.

Danke und Gruß
Markus

[Thorsten Pferdekaemper]

Hi,
hast Du da vielleicht eine Taste, die mit mehreren Aktoren im selben Device gepeert ist?
Wenn ja, dann ist das ein bekanntes Problem:
https://github.com/kc-GitHub/FHEM-HM485/issues/48
Ich hadere hier noch ein bisschen mit mir, ob ich da wirklich um die eq3-Fehler drum herum programmieren soll.
Gruß,
   Thorsten

[mago0211]

Hi,

hast Du da vielleicht eine Taste, die mit mehreren Aktoren im selben Device gepeert ist?

ja schon.

Also ist das ein Fehler von eq3? Wurde das den Jungs schon mal gemeldet?

Wie würde den dein Workaround aussehen? Würdest du dann auch einfach einen get state machen so wie ich im Notify?

Dann würde ich den Workaround ehrlich gesagt nicht einbauen.

Hier mal das list von einem HMW_IO_12_sw7_DR

Code Auswählen Erweitern

Internals:
   CHANGED
   DEF        000091DC
   FailedConfigReads 0
   IODev      HM485_LAN
   NAME       HMW_IO_12_Sw7_DR_JEQ0310645
   NR         52
   RawDeviceType 18
   RawFwVersion 774
   STATE      ACK
   TYPE       HM485
   channel_01 HMW_IO_12_Sw7_DR_JEQ0310645_01
   channel_02 HMW_IO_12_Sw7_DR_JEQ0310645_02
   channel_03 HMW_IO_12_Sw7_DR_JEQ0310645_03
   channel_04 HMW_IO_12_Sw7_DR_JEQ0310645_04
   channel_05 HMW_IO_12_Sw7_DR_JEQ0310645_05
   channel_06 HMW_IO_12_Sw7_DR_JEQ0310645_06
   channel_07 HMW_IO_12_Sw7_DR_JEQ0310645_07
   channel_08 HMW_IO_12_Sw7_DR_JEQ0310645_08
   channel_09 HMW_IO_12_Sw7_DR_JEQ0310645_09
   channel_10 HMW_IO_12_Sw7_DR_JEQ0310645_10
   channel_11 HMW_IO_12_Sw7_DR_JEQ0310645_11
   channel_12 HMW_IO_12_Sw7_DR_JEQ0310645_12
   channel_13 HMW_IO_12_Sw7_DR_JEQ0310645_13
   channel_14 HMW_IO_12_Sw7_DR_JEQ0310645_14
   channel_15 HMW_IO_12_Sw7_DR_JEQ0310645_15
   channel_16 HMW_IO_12_Sw7_DR_JEQ0310645_16
   channel_17 HMW_IO_12_Sw7_DR_JEQ0310645_17
   channel_18 HMW_IO_12_Sw7_DR_JEQ0310645_18
   channel_19 HMW_IO_12_Sw7_DR_JEQ0310645_19
   peer_act_0 channel_01 → HMW_IO_12_Sw7_DR_JEQ0310645_13
   peer_act_1 channel_02 → HMW_IO_12_Sw7_DR_JEQ0310645_13
   peer_act_10 channel_03 → HMW_IO_12_Sw7_DR_JEQ0310645_15
   peer_act_11 channel_04 → HMW_IO_12_Sw7_DR_JEQ0310645_17
   peer_act_12 channel_05 → HMW_IO_12_Sw7_DR_JEQ0310645_14
   peer_act_13 channel_03 → HMW_IO_12_Sw7_DR_JEQ0310645_16
   peer_act_14 channel_05 → HMW_IO_12_Sw7_DR_JEQ0310645_15
   peer_act_15 channel_06 → HMW_IO_12_Sw7_DR_JEQ0310645_14
   peer_act_16 channel_11 → HMW_IO_12_Sw7_DR_JEQ0310645_18
   peer_act_17 channel_12 → HMW_IO_12_Sw7_DR_JEQ0310645_18
   peer_act_18 channel_05 → HMW_IO_12_Sw7_DR_JEQ0310645_16
   peer_act_2 channel_01 → HMW_IO_12_Sw7_DR_JEQ0310645_15
   peer_act_3 channel_01 → HMW_IO_12_Sw7_DR_JEQ0310645_16
   peer_act_4 channel_02 → HMW_IO_12_Sw7_DR_JEQ0310645_15
   peer_act_5 channel_02 → HMW_IO_12_Sw7_DR_JEQ0310645_16
   peer_act_6 channel_02 → HMW_IO_12_Sw7_DR_JEQ0310645_17
   peer_act_7 channel_02 → HMW_IO_12_Sw7_DR_JEQ0310645_14
   peer_act_8 channel_03 → HMW_IO_12_Sw7_DR_JEQ0310645_17
   peer_sen_0 channel_13 ← HMW_IO_12_Sw7_DR_JEQ0310645_01
   peer_sen_1 channel_13 ← HMW_IO_12_Sw7_DR_JEQ0310645_02
   peer_sen_10 channel_17 ← HMW_IO_12_Sw7_DR_JEQ0310645_04
   peer_sen_11 channel_14 ← HMW_IO_12_Sw7_DR_JEQ0310645_05
   peer_sen_12 channel_16 ← HMW_IO_12_Sw7_DR_JEQ0310645_03
   peer_sen_13 channel_15 ← HMW_IO_12_Sw7_DR_JEQ0310645_05
   peer_sen_14 channel_16 ← HMW_IO_12_Sw7_DR_JEQ0310645_05
   peer_sen_15 channel_14 ← HMW_IO_12_Sw7_DR_JEQ0310645_06
   peer_sen_16 channel_18 ← HMW_IO_12_Sw7_DR_JEQ0310645_11
   peer_sen_17 channel_18 ← HMW_IO_12_Sw7_DR_JEQ0310645_12
   peer_sen_2 channel_15 ← HMW_IO_12_Sw7_DR_JEQ0310645_01
   peer_sen_3 channel_16 ← HMW_IO_12_Sw7_DR_JEQ0310645_01
   peer_sen_4 channel_15 ← HMW_IO_12_Sw7_DR_JEQ0310645_02
   peer_sen_5 channel_17 ← HMW_IO_12_Sw7_DR_JEQ0310645_02
   peer_sen_6 channel_14 ← HMW_IO_12_Sw7_DR_JEQ0310645_02
   peer_sen_7 channel_17 ← HMW_IO_12_Sw7_DR_JEQ0310645_03
   peer_sen_8 channel_16 ← HMW_IO_12_Sw7_DR_JEQ0310645_02
   peer_sen_9 channel_15 ← HMW_IO_12_Sw7_DR_JEQ0310645_03
   Readings:
     2017-10-30 13:47:24   D-deviceKey     HMW_IO12_SW7_DR
     2017-10-30 13:47:24   D-fwVersion     3.06
     2017-10-30 13:47:24   D-serialNr      JEQ0310645
     2017-10-30 14:19:06   R-central_address 00000002
     2017-10-30 14:19:06   R-logging_time  1.00
     2017-10-30 13:48:03   configStatus    OK
     2017-10-30 13:09:45   state           ACK
   Cache:
     01:
       allowedSets press_short:noArg press_long:noArg
       peeredChannels:
         HMW_IO_12_Sw7_DR_JEQ0310645_13
         HMW_IO_12_Sw7_DR_JEQ0310645_15
         HMW_IO_12_Sw7_DR_JEQ0310645_16
     02:
       allowedSets press_short:noArg press_long:noArg
       peeredChannels:
         HMW_IO_12_Sw7_DR_JEQ0310645_13
         HMW_IO_12_Sw7_DR_JEQ0310645_14
         HMW_IO_12_Sw7_DR_JEQ0310645_15
         HMW_IO_12_Sw7_DR_JEQ0310645_16
         HMW_IO_12_Sw7_DR_JEQ0310645_17
     03:
       allowedSets press_short:noArg press_long:noArg
       peeredChannels:
         HMW_IO_12_Sw7_DR_JEQ0310645_15
         HMW_IO_12_Sw7_DR_JEQ0310645_16
         HMW_IO_12_Sw7_DR_JEQ0310645_17
     04:
       allowedSets press_short:noArg press_long:noArg
       peeredChannels:
         HMW_IO_12_Sw7_DR_JEQ0310645_17
     05:
       allowedSets press_short:noArg press_long:noArg
       peeredChannels:
         HMW_IO_12_Sw7_DR_JEQ0310645_14
         HMW_IO_12_Sw7_DR_JEQ0310645_15
         HMW_IO_12_Sw7_DR_JEQ0310645_16
     06:
       allowedSets press_short:noArg press_long:noArg
       peeredChannels:
         HMW_IO_12_Sw7_DR_JEQ0310645_14
     07:
       allowedSets press_short:noArg press_long:noArg
       peeredChannels:
     08:
       allowedSets press_short:noArg press_long:noArg
       peeredChannels:
     09:
       allowedSets press_short:noArg press_long:noArg
       peeredChannels:
     10:
       allowedSets press_short:noArg press_long:noArg
       peeredChannels:
     11:
       allowedSets press_short:noArg press_long:noArg
       peeredChannels:
         HMW_IO_12_Sw7_DR_JEQ0310645_18
     12:
       allowedSets press_short:noArg press_long:noArg
       peeredChannels:
         HMW_IO_12_Sw7_DR_JEQ0310645_18
     13:
       allowedSets on:noArg off:noArg toggle:noArg inhibit:on,off install_test
       peeredChannels:
         HMW_IO_12_Sw7_DR_JEQ0310645_01
         HMW_IO_12_Sw7_DR_JEQ0310645_02
     14:
       allowedSets on:noArg off:noArg toggle:noArg inhibit:on,off install_test
       peeredChannels:
         HMW_IO_12_Sw7_DR_JEQ0310645_02
         HMW_IO_12_Sw7_DR_JEQ0310645_05
         HMW_IO_12_Sw7_DR_JEQ0310645_06
     15:
       allowedSets on:noArg off:noArg toggle:noArg inhibit:on,off install_test
       peeredChannels:
         HMW_IO_12_Sw7_DR_JEQ0310645_01
         HMW_IO_12_Sw7_DR_JEQ0310645_02
         HMW_IO_12_Sw7_DR_JEQ0310645_03
         HMW_IO_12_Sw7_DR_JEQ0310645_05
     16:
       allowedSets on:noArg off:noArg toggle:noArg inhibit:on,off install_test
       peeredChannels:
         HMW_IO_12_Sw7_DR_JEQ0310645_01
         HMW_IO_12_Sw7_DR_JEQ0310645_02
         HMW_IO_12_Sw7_DR_JEQ0310645_03
         HMW_IO_12_Sw7_DR_JEQ0310645_05
     17:
       allowedSets on:noArg off:noArg toggle:noArg inhibit:on,off install_test
       peeredChannels:
         HMW_IO_12_Sw7_DR_JEQ0310645_02
         HMW_IO_12_Sw7_DR_JEQ0310645_03
         HMW_IO_12_Sw7_DR_JEQ0310645_04
     18:
       allowedSets on:noArg off:noArg toggle:noArg inhibit:on,off install_test
       peeredChannels:
         HMW_IO_12_Sw7_DR_JEQ0310645_11
         HMW_IO_12_Sw7_DR_JEQ0310645_12
     19:
       allowedSets on:noArg off:noArg toggle:noArg inhibit:on,off install_test
       peeredChannels:
     Linkparams:
       Actuator:
         address_start 857
         address_step 6
         channel_param channel
         channels   01 02 03 04 05 06 07 08 09 10 11 12
         count      27
         peer_param actuator
         type       link
         parameter:
           HASH(0x1a66490)
           HASH(0x1abad20)
       Sensor:
         address_start 45
         address_step 28
         channel_param channel
         channels   13 14 15 16 17 18 19
         count      29
         peer_param sensor
         type       link
         parameter:
           HASH(0x1a83348)
           HASH(0x1ae7528)
           HASH(0x1a71948)
           HASH(0x1a80fa8)
           HASH(0x1a6b020)
           HASH(0x1a599a8)
           HASH(0x1a58080)
           HASH(0x1aac7b8)
           HASH(0x1ac9c18)
           HASH(0x1a8dc28)
           HASH(0x1b4d148)
           HASH(0x1abc8e0)
           HASH(0x1b4cb18)
           HASH(0x1ae1938)
           HASH(0x1a6af60)
           HASH(0x1ac7330)
           HASH(0x1a97f78)
           HASH(0x1ad8cf0)
           HASH(0x1b22a38)
           HASH(0x1aa0380)
           HASH(0x1aeaf78)
           HASH(0x1a94e10)
           HASH(0x1ab4360)
           HASH(0x1af17e0)
           HASH(0x1b57378)
           HASH(0x1b581d0)
           HASH(0x1a87448)
           HASH(0x1ad3938)
     Peered_act:
       0:
         channel    01
         name       000091DC_13
       1:
         channel    02
         name       000091DC_13
       10:
         channel    03
         name       000091DC_15
       11:
         channel    04
         name       000091DC_17
       12:
         channel    05
         name       000091DC_14
       13:
         channel    03
         name       000091DC_16
       14:
         channel    05
         name       000091DC_15
       15:
         channel    06
         name       000091DC_14
       16:
         channel    11
         name       000091DC_18
       17:
         channel    12
         name       000091DC_18
       18:
         channel    05
         name       000091DC_16
       2:
         channel    01
         name       000091DC_15
       3:
         channel    01
         name       000091DC_16
       4:
         channel    02
         name       000091DC_15
       5:
         channel    02
         name       000091DC_16
       6:
         channel    02
         name       000091DC_17
       7:
         channel    02
         name       000091DC_14
       8:
         channel    03
         name       000091DC_17
     Peers:
       Actuators:
         0:
           actuator   000091DC_13
           channel    01
         1:
           actuator   000091DC_13
           channel    02
         10:
           actuator   000091DC_15
           channel    03
         11:
           actuator   000091DC_17
           channel    04
         12:
           actuator   000091DC_14
           channel    05
         13:
           actuator   000091DC_16
           channel    03
         14:
           actuator   000091DC_15
           channel    05
         15:
           actuator   000091DC_14
           channel    06
         16:
           actuator   000091DC_18
           channel    11
         17:
           actuator   000091DC_18
           channel    12
         18:
           actuator   000091DC_16
           channel    05
         2:
           actuator   000091DC_15
           channel    01
         3:
           actuator   000091DC_16
           channel    01
         4:
           actuator   000091DC_15
           channel    02
         5:
           actuator   000091DC_16
           channel    02
         6:
           actuator   000091DC_17
           channel    02
         7:
           actuator   000091DC_14
           channel    02
         8:
           actuator   000091DC_17
           channel    03
       Sensors:
         0:
           channel    13
           sensor     000091DC_01
         1:
           channel    13
           sensor     000091DC_02
         10:
           channel    17
           sensor     000091DC_04
         11:
           channel    14
           sensor     000091DC_05
         12:
           channel    16
           sensor     000091DC_03
         13:
           channel    15
           sensor     000091DC_05
         14:
           channel    16
           sensor     000091DC_05
         15:
           channel    14
           sensor     000091DC_06
         16:
           channel    18
           sensor     000091DC_11
         17:
           channel    18
           sensor     000091DC_12
         2:
           channel    15
           sensor     000091DC_01
         3:
           channel    16
           sensor     000091DC_01
         4:
           channel    15
           sensor     000091DC_02
         5:
           channel    17
           sensor     000091DC_02
         6:
           channel    14
           sensor     000091DC_02
         7:
           channel    17
           sensor     000091DC_03
         8:
           channel    16
           sensor     000091DC_02
         9:
           channel    15
           sensor     000091DC_03
Attributes:
   IODev      HM485_LAN
   alias      IO12_7_NR.1
   event-on-change-reading state
   group      HM485_device
   room       99sys_HM485
   verbose    1

Gruß
Markus

[Thorsten Pferdekaemper]

Also ist das ein Fehler von eq3?

Meiner Meinung nach schon. Vielleicht ist das aber auch ein "Feature", um den Bus zu entlasten.

Wurde das den Jungs schon mal gemeldet?

Zumindest nicht von mir. Da müsste man ja erst einmal nachweisen, dass die CCU das Problem nicht hat. Dazu müsste ich aber erst einmal wieder eine CCU installieren und dazu habe ich keine Lust.

Wie würde den dein Workaround aussehen? Würdest du dann auch einfach einen get state machen so wie ich im Notify?

Ja, in etwa so würde ich das auch machen. Ich habe aber das Problem bei mir nicht wirklich, da ich (fast) immer nur eine 1:1-Zuordnung habe. Ich schalte zwar auch manchmal mehrere Aktoren mit einer Taste, aber das geht dann sowieso über notify.

Dann würde ich den Workaround ehrlich gesagt nicht einbauen.

Naja, ich habe mir überlegt, dass ich im HM485-Modul etwas einbaue, das in etwa Deinem notify entspricht, halt nur generisch. Das Modul weiß ja im Prinzip, was mit was gepeert ist und könnte dann so ein get state absetzen, wenn es zu einem Sensor mehrere Aktoren gibt.

Gruß,
   Thorsten

[mago0211]

Zumindest nicht von mir. Da müsste man ja erst einmal nachweisen, dass die CCU das Problem nicht hat. Dazu müsste ich aber erst einmal wieder eine CCU installieren und dazu habe ich keine Lust.

Naja da ich das gleiche verhalten mit RaspberryMatic nachstellen konnte und die ja auch den SourceCode von der CCU nutzen, ist es mit einer CCU vermutlich das gleiche. Ich werden dem Support mal schreiben bin gespannt was die antworten.

Ja, in etwa so würde ich das auch machen. Ich habe aber das Problem bei mir nicht wirklich, da ich (fast) immer nur eine 1:1-Zuordnung habe. Ich schalte zwar auch manchmal mehrere Aktoren mit einer Taste, aber das

Das hab ich jetzt davon weil ich jede Lampe einzeln schalten will 

Naja, ich habe mir überlegt, dass ich im HM485-Modul etwas einbaue, das in etwa Deinem notify entspricht, halt nur generisch. Das Modul weiß ja im Prinzip, was mit was gepeert ist und könnte dann so ein get state absetzen, wenn es zu einem Sensor mehrere Aktoren gibt.

Für den Endanwender natürlich eine feine Sache. Die Frage ist nur ob man einen Workaround im Code haben will wo so gut wie keine Aussicht besteht das das Problem jemals "richtig" gelöst wird 

Danke für deine Antworten. Mit besserer Suche hätte ich das auch irgenwie selber finden können 

Gru
Markus

[habl]

Hi,

Dieses Fehlerbild passt zum angegebenen hier:
Ein Tastereingang mit einem Schaltausgang auf dem selben HMW_IO_12_sw7_DR gepeert, sonst keine zusätzlichen peerings der beiden Kanäle vorhanden. short_on_time ist gesetzt. Auch hier bekommt fhem nichts davon mit, wenn der Aktor nach der parametrierten Zeit wieder zurückschaltet.

Gerade noch einmal getestet, wenn Aktor und Sensor auf verschiedenen HMW_IO_12_sw7_DR liegen, geht es.

Da werde ich wohl ein wenig in der Verteilung umklemmen...

VG
  habl

[Thorsten Pferdekaemper]

Ein Tastereingang mit einem Schaltausgang auf dem selben HMW_IO_12_sw7_DR gepeert, sonst keine zusätzlichen peerings der beiden Kanäle vorhanden. short_on_time ist gesetzt. Auch hier bekommt fhem nichts davon mit, wenn der Aktor nach der parametrierten Zeit wieder zurückschaltet.

Das ist dann aber meiner Meinung nach was anderes. Das hier diskutierte Fehlerbild stellt sich nur ein, wenn mindestens zwei Aktorkanäle desselben Devices mit demselben Sensor-Kanal gepeert sind. Dabei ist es meiner Meinung nach auch egal, ob externes oder internes Peering.
Wie ist denn logging_time (im Device) und logging (im Aktor-Kanal) eingestellt?
Gruß,
   Thorsten

[habl]

Moin Thorsten,

Wie ist denn logging_time (im Device) und logging (im Aktor-Kanal) eingestellt?

Logging Time sind bei mir auf allen Geräten 1 sec. und Logging ist immer on.

Laienhaft hätte ich es jetzt so vermutet, dass es nicht nach extern auf dem Bus kommuniziert werden muss wenn Aktor und Sensor auf einem Gerät liegen?!

VG
  habl

[Thorsten Pferdekaemper]

Logging Time sind bei mir auf allen Geräten 1 sec. und Logging ist immer on.

Ok, dann sollte es auch kommen.

Laienhaft hätte ich es jetzt so vermutet, dass es nicht nach extern auf dem Bus kommuniziert werden muss wenn Aktor und Sensor auf einem Gerät liegen?!

Doch, weil logging auf "on" steht. Dann sollte das Teil auch jede Zustandsänderung melden.
Es gibt aber tatsächlich einen Teil der Kommunikation, die bei internen Peerings nicht stattfindet: Bei externen Peerings sendet das Sensor-Device das Event an das Aktor-Device. Daraufhin sendet das Aktor-Device mindestens ein ACK, aber ich habe auch gesehen, dass das Aktor-Device sogar den momentanen/neuen Zustand sendet. Das passiert sofort (also innerhalb 200ms oder so). Dieser Teil fällt bei internen Peerings weg.
Zusätzlich gibt es aber noch das "logging", welches an die Zentrale geht. Dieser Teil sollte nicht wegfallen.
Das gilt insbesondere für Timer-Aktionen, die ja vom Sensor-Event entkoppelt sind.

Ich glaube, ich muss das selbst mal ausprobieren.

Gruß,
    Thorsten   

[habl]

Ich weiss nicht ob ich dich dabei unterstützen kann aber ich habe mal den Verbose vom Gateway hochgesetzt:

Code Auswählen Erweitern


2017.10.31 11:40:15 5: myHM485: Dispatch: FD0FC865FFFFFFFFBA00016DFE4B09000E
2017.10.31 11:40:15 5: myHM485: dispatch �\017�e�����\000\001m�K\t\000\016
2017.10.31 11:40:15 5: myHM485: HM485_Parse: MsgId: 200
2017.10.31 11:40:15 5: myHM485: HM485_Parse: ProcessEvent
2017.10.31 11:40:15 5: myHM485: HM485_ProcessEvent: hmwId = 00016DFE msgData = 4B09000E
2017.10.31 11:40:15 5: myHM485: HM485_LAN_parseIncommingCommand: MsgId: 201 Cmd: 101
2017.10.31 11:40:15 4: myHM485: Event:HASH(0x8066f78)
2017.10.31 11:40:15 5: myHM485: Dispatch: FD1BC965FFFFFFFFBC00016DFE4109120003064E455131353133313634
2017.10.31 11:40:15 5: myHM485: dispatch �\e�e�����\000\001m�A\t\022\000\003\006NEQ1513164
2017.10.31 11:40:15 5: myHM485: HM485_Parse: MsgId: 201
2017.10.31 11:40:15 5: myHM485: HM485_Parse: ProcessEvent
2017.10.31 11:40:15 5: myHM485: HM485_ProcessEvent: hmwId = 00016DFE msgData = 4109120003064E455131353133313634
2017.10.31 11:40:16 5: myHM485: HM485_LAN_parseIncommingCommand: MsgId: 202 Cmd: 101
2017.10.31 11:40:16 4: myHM485: Event:HASH(0x804e910)
2017.10.31 11:40:16 5: myHM485: Dispatch: FD0FCA65000000013E00016DFE6911C840
2017.10.31 11:40:16 5: myHM485: dispatch �\017�e\000\000\000\001>\000\001m�i\021�@
2017.10.31 11:40:16 5: myHM485: HM485_Parse: MsgId: 202
2017.10.31 11:40:16 5: myHM485: HM485_Parse: ProcessEvent
2017.10.31 11:40:16 5: myHM485: HM485_ProcessEvent: hmwId = 00016DFE msgData = 6911C840
2017.10.31 11:40:31 5: myHM485: HM485_LAN_parseIncommingCommand: MsgId: 203 Cmd: 101
2017.10.31 11:40:31 4: myHM485: Event:HASH(0x7d8dc88)
2017.10.31 11:40:31 5: myHM485: Dispatch: FD0FCB65000000013800016DFE69110000
2017.10.31 11:40:31 5: myHM485: dispatch �\017�e\000\000\000\0018\000\001m�i\021\000\000
2017.10.31 11:40:31 5: myHM485: HM485_Parse: MsgId: 203
2017.10.31 11:40:31 5: myHM485: HM485_Parse: ProcessEvent
2017.10.31 11:40:31 5: myHM485: HM485_ProcessEvent: hmwId = 00016DFE msgData = 69110000
2017.10.31 11:40:51 5: myHM485: HM485_LAN_Write TX: 209
2017.10.31 11:40:51 5: SW: fd02d14b
2017.10.31 11:40:51 5: myHM485: HM485_LAN_parseIncommingCommand: MsgId: 209 Cmd: 97
2017.10.31 11:40:51 5: myHM485: HM485_LAN_parseIncommingCommand: Alive: (209) 00 AliveStatus: 00


dabei ist mir aufgefallen, das es jetzt auch wieder in fhem angezeigt wird    Bin jetzt ein wenig konfus.

Also schnell die Warmwasserpumpe eingeschaltet, Anzeige im fhem bleibt an --> ok,bin doch nicht so blöd
on Time runtergesetzt, wollte schliesslich nicht immer so lange warten, und es wird jetzt in fhem wieder brav angezeigt.

Jetzt weiss ich nicht mehr weiter, kann den Fehler also nicht mehr Nachvollziehen?!?

Hast Du eine Erklärung?

VG
  habl

[habl]

ok, noch einen gefunden bei dem es nicht geht.

ich werde jetzt mal alle peerings neu schreiben. Kann man das mit einem Befehl absetzen oder muss ich alle peerings einzeln anpacken?

VG
  habl

[Thorsten Pferdekaemper]

Ich weiss nicht ob ich dich dabei unterstützen kann aber ich habe mal den Verbose vom Gateway hochgesetzt:

Das sieht gut aus. Es kann nur sein, dass irgendwas mit dem Pairing nicht stimmt. Was steht denn in D-central_address?

Hast Du eine Erklärung?

Nein.

ich werde jetzt mal alle peerings neu schreiben.

Warum? ...und was genau meinst Du damit?
Wenn Du vermutest, dass das, was in FHEM angezeigt ist, nicht das ist, was in den Devices gespeichert ist, dann mach mal ein "set ... getConfig". Dann warten bis configStatus wieder OK und nochmal schauen.

Kann man das mit einem Befehl absetzen oder muss ich alle peerings einzeln anpacken?

Ich weiß zwar nicht so genau, was Du meinst, aber wahrscheinlich jedes Peering einzeln.

Gruß,
   Thorsten

[habl]

Was steht denn in D-central_address?

Habe ich leider nicht gefunden, aber ein R-central_address --> 00000001

Es funktioniert sonst im Prinzip ja auch alles.

Warum? ...und was genau meinst Du damit?

Peering Configuration --> Configure Peering --> Write to Device

Danach funktioniert es wieder und der Staus wird in fhem wieder korrekt angezeigt.


Merkwürdig ist das ganze schon ein wenig.

VG
  habl

[Thorsten Pferdekaemper]

Peering Configuration --> Configure Peering --> Write to Device
Danach funktioniert es wieder und der Staus wird in fhem wieder korrekt angezeigt.
Merkwürdig ist das ganze schon ein wenig.

Ja, vor Allem da das "Nochmal ins Device schreiben" gar nicht wirklich etwas ändern dürfte, außer wenn irgendwie der Inhalt des EEPROM mit dem was in FHEM angezeigt wird auseinander gelaufen ist.
Es kann auch sein, dass das Device selbst sein eigenes EEPROM nicht richtig gelesen hatte oder so. Das "Write to Device" sagt dem Device nämlich auch, dass es bitte seine Konfiguration nochmal lesen soll. Vielleicht war es das.

Hast Du vielleicht noch einen anderen Mechanismus zum Konfigurieren Deiner Geräte? Eine CCU vielleicht oder hast Du das direkt über die Knöpfe am Gerät gemacht?

Gruß,
   Thorsten

[habl]

Hast Du vielleicht noch einen anderen Mechanismus zum Konfigurieren Deiner Geräte? Eine CCU vielleicht oder hast Du das direkt über die Knöpfe am Gerät gemacht?

Nein, eine CCU habe ich gar nicht, läuft alles über das fhem-Modul.

Ein letztes peering mit Zeitautomatik hatte ich noch, da habe ich dann im Vorfeld auf das Modul noch ein set getConfig angestossen - Ohne Besserung.
Und das peering neu geschrieben, danach war es wieder in Ordnung.

Da ich jetzt mittlerweile alle peerings mit Zeitautomatik neu beschrieben habe und deshalb nicht weiter analysieren kann, vermerke ich das Thema erstmal als gelöst. Werde aber weiterhin ein Auge darauf halten.

vielen Dank für deine Bemühungen

VG
  habl