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.
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 (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
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
Hi,
Zitat von: Thorsten Pferdekaemper am 30 Oktober 2017, 14:51:31
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
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 1Gruß
Markus
Zitat von: mago0211 am 30 Oktober 2017, 15:02:55
Also ist das ein Fehler von eq3?
Meiner Meinung nach schon. Vielleicht ist das aber auch ein "Feature", um den Bus zu entlasten.
ZitatWurde 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.
ZitatWie 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.
ZitatDann 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
Zitat von: Thorsten Pferdekaemper am 30 Oktober 2017, 15:20:55
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.
Zitat von: Thorsten Pferdekaemper am 30 Oktober 2017, 15:20:55
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 ::) 8) ;D
ZitatNaja, 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 :-X :(
Gru
Markus
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
Zitat von: habl am 31 Oktober 2017, 09:32:22Ein 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
Moin Thorsten,
Zitat von: Thorsten Pferdekaemper am 31 Oktober 2017, 10:09:02
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
Zitat von: habl am 31 Oktober 2017, 11:01:21Logging Time sind bei mir auf allen Geräten 1 sec. und Logging ist immer on.
Ok, dann sollte es auch kommen.
Zitat
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
Ich weiss nicht ob ich dich dabei unterstützen kann aber ich habe mal den Verbose vom Gateway hochgesetzt:
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 :o 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
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
Zitat von: habl am 31 Oktober 2017, 12:12:46
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?
Zitat
Hast Du eine Erklärung?
Nein.
Zitat von: habl am 31 Oktober 2017, 13:02:18
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.
Zitat
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
ZitatWas 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.
ZitatWarum? ...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
Zitat von: habl am 31 Oktober 2017, 13:39:09
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
ZitatHast 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