Homematic wired

hglaser · 29 Juli 2014, 21:31:29

hallo gevoo

Danke fürs Update. Leider noch keine Änderung, Im Log einmal ein "set auf level 80". leider springen die Werte im STATE und Reading genau auf die Hälfte des erwarteten Wertes. Erst wenn ich im Browser aktualisiere stimmen die Werte.

Code Auswählen


==> HM485-log2014-07-29_21-13-05.log <==
2014-07-29_21:18:10 HM485_Set: cmd = level
2014-07-29_21:18:10 HM485_SetChannelState: hash = HASH(0x292de50) cmd = level value = 80
2014-07-29_21:18:10 HM485_SetChannelState: valueKey = direction deviceKey = HMW_LC_Dim1L chNr = 03
2014-07-29_21:18:10 HM485_SetChannelState: valueKey = level deviceKey = HMW_LC_Dim1L chNr = 03
2014-07-29_21:18:10 HM485_SetChannelState: chType = dimmer valueKey = level value = 80 frameValue = 160
2014-07-29_21:18:10 HM485_SendCommand: hash = HASH(0x292de50) hmwId = 00009266 data = 7802A0
2014-07-29_21:18:10 HM485_SetChannelState: valueKey = install_test deviceKey = HMW_LC_Dim1L chNr = 03
2014-07-29_21:18:10 HM485_SetChannelState: valueKey = inhibit deviceKey = HMW_LC_Dim1L chNr = 03
2014-07-29_21:18:10 HM485_SetChannelState: valueKey = working deviceKey = HMW_LC_Dim1L chNr = 03

==> fhem-2014-07-29.log <==
2014.07.29 21:18:10.322 3: HM485_LAN: TX: (225) I[0](0,F,B)(18) 00000001 -> 00009266 [5] 78(x) 02A0
2014.07.29 21:18:10.492 3: HM485_LAN: ACK: (225)
2014.07.29 21:18:10.494 3: HM485_LAN: Response: (225) 6902A000

==> HM485-log2014-07-29_21-13-05.log <==
2014-07-29_21:18:10 HM485_ProcessResponse: hmwId = 00009266 requestType = 78
2014-07-29_21:18:10 HM485_ProcessResponse: ( 53, 78) deviceKey = HMW_LC_Dim1L
2014-07-29_21:18:10 HM485_ProcessChannelState: name = HMW_LC_Dim1L_DR_JEQ0545966 Channel = 03 msgData = 6902A000 actionType = response
2014-07-29_21:18:10 HM485_ProcessChannelState: Wert = HASH(0x2b0d300) Channel = 03
2014-07-29_21:18:10 HM485_ChannelUpdate: name = HMW_LC_Dim1L_DR_JEQ0545966_03

==> fhem-2014-07-29.log <==
2014.07.29 21:18:10.533 3: HM485: HMW_LC_Dim1L_DR_JEQ0545966_03: level -> 80
2014.07.29 21:18:12.340 3: HM485_LAN: Event: I[0](0,F,B)(18) 00009266 -> 00000001 [4] 69(i) 02

==> HM485-log2014-07-29_21-13-05.log <==
2014-07-29_21:18:12 HM485_ProcessEvent: ioHash = HASH(0x2736730) msgData = 0000000118000092666902A000
2014-07-29_21:18:12 HM485_ProcessChannelState: name = HMW_LC_Dim1L_DR_JEQ0545966 Channel = 03 msgData = 6902A000 actionType = frame
2014-07-29_21:18:12 HM485_ProcessChannelState: Wert = HASH(0x2b201e0) Channel = 03
2014-07-29_21:18:12 HM485_ChannelUpdate: name = HMW_LC_Dim1L_DR_JEQ0545966_03

lg Harald

edit: Komisch, in der Room-Ansicht (nennt man das so?) ist es genau umgekeht, Hier springt der Slider zurück, aber "level_80" würde stimmen. hab noch einen Screenshot angehängt.

hglaser · 30 Juli 2014, 10:48:06

Hallo gevoo

Hier noch ein Nachtrag. Habe noch einen Fehler gefunden: Ein set HMW_LC_Dim1L_DR_JEQ0545966_03 off erzeugt auch keinen Event. "on" und alle anderen "level" erzeugen einen

off:

Code Auswählen


2014-07-30_10:35:54 HM485_Set: cmd = off

==> /opt/fhem/log/fhem-2014-07-30.log <==
Use of uninitialized value $value in concatenation (.) or string at ./FHEM/10_HM485.pm line 850.

==> /opt/fhem/log/HM485-log2014-07-30_10-31-19.log <==
2014-07-30_10:35:54 HM485_SetChannelState: hash = HASH(0x255f0d8) cmd = off value = 
2014-07-30_10:35:54 HM485_SetChannelState: valueKey = direction deviceKey = HMW_LC_Dim1L chNr = 03
2014-07-30_10:35:54 HM485_SetChannelState: valueKey = level deviceKey = HMW_LC_Dim1L chNr = 03
2014-07-30_10:35:54 HM485_SetChannelState: control = dimmer.level

==> /opt/fhem/log/fhem-2014-07-30.log <==
Use of uninitialized value $value in concatenation (.) or string at ./FHEM/10_HM485.pm line 889.

==> /opt/fhem/log/HM485-log2014-07-30_10-31-19.log <==
2014-07-30_10:35:54 HM485_SetChannelState: chType = dimmer valueKey = level value =  frameValue = 0

==> /opt/fhem/log/fhem-2014-07-30.log <==
Use of uninitialized value $retVal in division (/) at FHEM/lib/HM485/Device.pm line 642.

==> /opt/fhem/log/HM485-log2014-07-30_10-31-19.log <==
2014-07-30_10:35:54 HM485_SendCommand: hash = HASH(0x255f0d8) hmwId = 00009266 data = 780200
2014-07-30_10:35:54 HM485_SetChannelState: valueKey = install_test deviceKey = HMW_LC_Dim1L chNr = 03
2014-07-30_10:35:54 HM485_SetChannelState: valueKey = inhibit deviceKey = HMW_LC_Dim1L chNr = 03
2014-07-30_10:35:54 HM485_SetChannelState: valueKey = working deviceKey = HMW_LC_Dim1L chNr = 03

==> /opt/fhem/log/fhem-2014-07-30.log <==
2014.07.30 10:35:54.606 3: HM485_LAN: TX: (214) I[0](0,F,B)(18) 00000001 -> 00009266 [5] 78(x) 0200
2014.07.30 10:35:54.641 3: HM485_LAN: ACK: (214)
2014.07.30 10:35:54.643 3: HM485_LAN: Response: (214) 69020000

==> /opt/fhem/log/HM485-log2014-07-30_10-31-19.log <==
2014-07-30_10:35:54 HM485_ProcessResponse: hmwId = 00009266 requestType = 78
2014-07-30_10:35:54 HM485_ProcessResponse: ( 53, 78) deviceKey = HMW_LC_Dim1L
2014-07-30_10:35:54 HM485_ProcessChannelState: name = HMW_LC_Dim1L_DR_JEQ0545966 Channel = 03 msgData = 69020000 actionType = response
2014-07-30_10:35:54 HM485_ProcessChannelState: Wert = HASH(0x281d6d0) Channel = 03
2014-07-30_10:35:54 HM485_ChannelUpdate: name = HMW_LC_Dim1L_DR_JEQ0545966_03

==> /opt/fhem/log/fhem-2014-07-30.log <==
2014.07.30 10:35:56.619 3: HM485_LAN: Event: I[1](0,F,B)(1A) 00009266 -> 00000001 [4] 69(i) 02

==> /opt/fhem/log/HM485-log2014-07-30_10-31-19.log <==
2014-07-30_10:35:56 HM485_ProcessEvent: ioHash = HASH(0x2369718) msgData = 000000011A0000926669020000
2014-07-30_10:35:56 HM485_ProcessChannelState: name = HMW_LC_Dim1L_DR_JEQ0545966 Channel = 03 msgData = 69020000 actionType = frame
2014-07-30_10:35:56 HM485_ProcessChannelState: Wert = HASH(0x27d9b08) Channel = 03
2014-07-30_10:35:56 HM485_ChannelUpdate: name = HMW_LC_Dim1L_DR_JEQ0545966_03

on:

Code Auswählen


2014-07-30_10:44:39 HM485_Set: cmd = on

==> /opt/fhem/log/fhem-2014-07-30.log <==
Use of uninitialized value $value in concatenation (.) or string at ./FHEM/10_HM485.pm line 850.

==> /opt/fhem/log/HM485-log2014-07-30_10-31-19.log <==
2014-07-30_10:44:39 HM485_SetChannelState: hash = HASH(0x255f0d8) cmd = on value = 
2014-07-30_10:44:39 HM485_SetChannelState: valueKey = direction deviceKey = HMW_LC_Dim1L chNr = 03
2014-07-30_10:44:39 HM485_SetChannelState: valueKey = level deviceKey = HMW_LC_Dim1L chNr = 03
2014-07-30_10:44:39 HM485_SetChannelState: control = dimmer.level

==> /opt/fhem/log/fhem-2014-07-30.log <==
Use of uninitialized value $value in concatenation (.) or string at ./FHEM/10_HM485.pm line 889.

==> /opt/fhem/log/HM485-log2014-07-30_10-31-19.log <==
2014-07-30_10:44:39 HM485_SetChannelState: chType = dimmer valueKey = level value =  frameValue = 200

==> /opt/fhem/log/fhem-2014-07-30.log <==
Use of uninitialized value $retVal in division (/) at FHEM/lib/HM485/Device.pm line 642.

==> /opt/fhem/log/HM485-log2014-07-30_10-31-19.log <==
2014-07-30_10:44:39 HM485_SendCommand: hash = HASH(0x255f0d8) hmwId = 00009266 data = 7802C8
2014-07-30_10:44:39 HM485_SetChannelState: valueKey = install_test deviceKey = HMW_LC_Dim1L chNr = 03
2014-07-30_10:44:39 HM485_SetChannelState: valueKey = inhibit deviceKey = HMW_LC_Dim1L chNr = 03
2014-07-30_10:44:39 HM485_SetChannelState: valueKey = working deviceKey = HMW_LC_Dim1L chNr = 03

==> /opt/fhem/log/fhem-2014-07-30.log <==
2014.07.30 10:44:39.177 3: HM485_LAN: TX: (241) I[2](0,F,B)(1C) 00000001 -> 00009266 [5] 78(x) 02C8
2014.07.30 10:44:39.345 3: HM485_LAN: ACK: (241)
2014.07.30 10:44:39.348 3: HM485_LAN: Response: (241) 6902C800

==> /opt/fhem/log/HM485-log2014-07-30_10-31-19.log <==
2014-07-30_10:44:39 HM485_ProcessResponse: hmwId = 00009266 requestType = 78
2014-07-30_10:44:39 HM485_ProcessResponse: ( 53, 78) deviceKey = HMW_LC_Dim1L
2014-07-30_10:44:39 HM485_ProcessChannelState: name = HMW_LC_Dim1L_DR_JEQ0545966 Channel = 03 msgData = 6902C800 actionType = response
2014-07-30_10:44:39 HM485_ProcessChannelState: Wert = HASH(0x18e8ce8) Channel = 03
2014-07-30_10:44:39 HM485_ChannelUpdate: name = HMW_LC_Dim1L_DR_JEQ0545966_03

==> /opt/fhem/log/fhem-2014-07-30.log <==
2014.07.30 10:44:39.386 3: HM485: HMW_LC_Dim1L_DR_JEQ0545966_03: level -> 100
2014.07.30 10:44:41.210 3: HM485_LAN: Event: I[1](2,F,B)(5A) 00009266 -> 00000001 [4] 69(i) 02

==> /opt/fhem/log/HM485-log2014-07-30_10-31-19.log <==
2014-07-30_10:44:41 HM485_ProcessEvent: ioHash = HASH(0x2369718) msgData = 000000015A000092666902C800
2014-07-30_10:44:41 HM485_ProcessChannelState: name = HMW_LC_Dim1L_DR_JEQ0545966 Channel = 03 msgData = 6902C800 actionType = frame
2014-07-30_10:44:41 HM485_ProcessChannelState: Wert = HASH(0x27dab38) Channel = 03
2014-07-30_10:44:41 HM485_ChannelUpdate: name = HMW_LC_Dim1L_DR_JEQ0545966_03

==> /opt/fhem/log/fhem-2014-07-30.log <==
2014.07.30 10:45:01.251 3: HM485_LAN: Alive: (242) 3030

lg Harald

gevoo · 30 Juli 2014, 20:05:17

Hallo Harald,

bitte um den nächsten Test mit Version 0.2.44

Gruß Gevoo

hglaser · 31 Juli 2014, 01:44:00

hallo gevoo

nun gehts! sehr schön, nun sind die Anzeigen syncron.
Einziger Fehler ist, daß nun kein event bei "set HMW_LC_Dim1L_DR_JEQ0545966_03 level 80" im Status Monitor erscheint. bei "on" und "off" funktioniert es.

dimmen auf level 80:

Code Auswählen


==> HM485-log2014-07-31_01-19-04.log <==
2014-07-31_01:29:14 HM485_Set: cmd = level
2014-07-31_01:29:14 HM485_SetChannelState: hash = HASH(0x26f5770) cmd = level value = 80
2014-07-31_01:29:14 HM485_SetChannelState: DefinitionsPfad = HMW_LC_Dim1L/channels/dimmer/params/values/
2014-07-31_01:29:14 HM485_SetChannelState: valueKey = direction deviceKey = HMW_LC_Dim1L chNr = 03
2014-07-31_01:29:14 HM485_SetChannelState: valueKey = level deviceKey = HMW_LC_Dim1L chNr = 03
2014-07-31_01:29:14 HM485_SetChannelState: chType = dimmer valueKey = level value = 80 frameValue = 160
2014-07-31_01:29:14 HM485_SetChannelState: hash = HASH(0x26f5770) valueKey = level frameData = HASH(0x2afe0a0)
2014-07-31_01:29:14 HM485_SendCommand: hash = HASH(0x26f5770) hmwId = 00009266 data = 7802A0
2014-07-31_01:29:14 HM485_SetChannelState: valueKey = install_test deviceKey = HMW_LC_Dim1L chNr = 03
2014-07-31_01:29:14 HM485_SetChannelState: valueKey = inhibit deviceKey = HMW_LC_Dim1L chNr = 03
2014-07-31_01:29:14 HM485_SetChannelState: valueKey = working deviceKey = HMW_LC_Dim1L chNr = 03

==> fhem-2014-07.log <==
2014.07.31 01:29:14 3: HM485_LAN: TX: (106) I[0](0,F,B)(18) 00000001 -> 00009266 [5] 78(x) 02A0
2014.07.31 01:29:14 3: HM485_LAN: ACK: (106)
2014.07.31 01:29:14 3: HM485_LAN: Response: (106) 6902A000

==> HM485-log2014-07-31_01-19-04.log <==
2014-07-31_01:29:14 HM485_ProcessResponse: hmwId = 00009266 requestType = 78
2014-07-31_01:29:14 HM485_ProcessResponse: ( 53, 78) deviceKey = HMW_LC_Dim1L
2014-07-31_01:29:14 HM485_ProcessChannelState: name = HMW_LC_Dim1L_DR_JEQ0545966 Channel = 03 msgData = 6902A000 actionType = response
2014-07-31_01:29:14 HM485_ProcessChannelState: Channel = 03
2014-07-31_01:29:14 HM485_ChannelUpdate: name = HMW_LC_Dim1L_DR_JEQ0545966_03
2014-07-31_01:29:14 HM485_ChannelDoUpdate: name = HMW_LC_Dim1L_DR_JEQ0545966_03 value = 80

ein off:

Code Auswählen

==> HM485-log2014-07-31_01-19-04.log <==
2014-07-31_01:33:24 HM485_Set: cmd = off
Use of uninitialized value $value in concatenation (.) or string at ./FHEM/10_HM485.pm line 850.
2014-07-31_01:33:24 HM485_SetChannelState: hash = HASH(0x26f5770) cmd = off value = 
2014-07-31_01:33:24 HM485_SetChannelState: DefinitionsPfad = HMW_LC_Dim1L/channels/dimmer/params/values/
2014-07-31_01:33:24 HM485_SetChannelState: valueKey = direction deviceKey = HMW_LC_Dim1L chNr = 03
2014-07-31_01:33:24 HM485_SetChannelState: valueKey = level deviceKey = HMW_LC_Dim1L chNr = 03
2014-07-31_01:33:24 HM485_SetChannelState: control = dimmer.level
Use of uninitialized value $value in concatenation (.) or string at ./FHEM/10_HM485.pm line 889.
2014-07-31_01:33:24 HM485_SetChannelState: chType = dimmer valueKey = level value =  frameValue = 0
2014-07-31_01:33:24 HM485_SetChannelState: hash = HASH(0x26f5770) valueKey = level frameData = HASH(0x2b187b8)
Use of uninitialized value $value in concatenation (.) or string at ./FHEM/10_HM485.pm line 902.
2014-07-31_01:33:24 HM485_SendCommand: hash = HASH(0x26f5770) hmwId = 00009266 data = 780200
2014-07-31_01:33:24 HM485_SetChannelState: valueKey = install_test deviceKey = HMW_LC_Dim1L chNr = 03
2014-07-31_01:33:24 HM485_SetChannelState: valueKey = inhibit deviceKey = HMW_LC_Dim1L chNr = 03
2014-07-31_01:33:24 HM485_SetChannelState: valueKey = working deviceKey = HMW_LC_Dim1L chNr = 03

==> fhem-2014-07.log <==
2014.07.31 01:33:24 3: HM485_LAN: TX: (119) I[1](0,F,B)(1A) 00000001 -> 00009266 [5] 78(x) 0200
2014.07.31 01:33:24 3: HM485_LAN: ACK: (119)
2014.07.31 01:33:24 3: HM485_LAN: Response: (119) 69020000

==> HM485-log2014-07-31_01-19-04.log <==
2014-07-31_01:33:24 HM485_ProcessResponse: hmwId = 00009266 requestType = 78
2014-07-31_01:33:24 HM485_ProcessResponse: ( 53, 78) deviceKey = HMW_LC_Dim1L
2014-07-31_01:33:24 HM485_ProcessChannelState: name = HMW_LC_Dim1L_DR_JEQ0545966 Channel = 03 msgData = 69020000 actionType = response
2014-07-31_01:33:24 HM485_ProcessChannelState: Channel = 03
2014-07-31_01:33:24 HM485_ChannelUpdate: name = HMW_LC_Dim1L_DR_JEQ0545966_03
2014-07-31_01:33:24 HM485_ChannelDoUpdate: name = HMW_LC_Dim1L_DR_JEQ0545966_03 value = 0

==> fhem-2014-07.log <==
2014.07.31 01:33:24 3: HM485: HMW_LC_Dim1L_DR_JEQ0545966_03: level -> 0

==> HM485-log2014-07-31_01-19-04.log <==
2014-07-31_01:33:24 HM485_ChannelDoUpdate: name = HMW_LC_Dim1L_DR_JEQ0545966_03 State = level_ valueKey = level value = 0
2014-07-31_01:33:24 HM485_ChannelDoUpdate: name = HMW_LC_Dim1L_DR_JEQ0545966_03 State = level_0

und noch ein on:

Code Auswählen

==> HM485-log2014-07-31_01-19-04.log <==
2014-07-31_01:34:51 HM485_Set: cmd = on
Use of uninitialized value $value in concatenation (.) or string at ./FHEM/10_HM485.pm line 850.
2014-07-31_01:34:51 HM485_SetChannelState: hash = HASH(0x26f5770) cmd = on value = 
2014-07-31_01:34:51 HM485_SetChannelState: DefinitionsPfad = HMW_LC_Dim1L/channels/dimmer/params/values/
2014-07-31_01:34:51 HM485_SetChannelState: valueKey = direction deviceKey = HMW_LC_Dim1L chNr = 03
2014-07-31_01:34:51 HM485_SetChannelState: valueKey = level deviceKey = HMW_LC_Dim1L chNr = 03
2014-07-31_01:34:51 HM485_SetChannelState: control = dimmer.level
Use of uninitialized value $value in concatenation (.) or string at ./FHEM/10_HM485.pm line 889.
2014-07-31_01:34:51 HM485_SetChannelState: chType = dimmer valueKey = level value =  frameValue = 200
2014-07-31_01:34:51 HM485_SetChannelState: hash = HASH(0x26f5770) valueKey = level frameData = HASH(0x2afab08)
Use of uninitialized value $value in concatenation (.) or string at ./FHEM/10_HM485.pm line 902.
2014-07-31_01:34:51 HM485_SendCommand: hash = HASH(0x26f5770) hmwId = 00009266 data = 7802C8
2014-07-31_01:34:51 HM485_SetChannelState: valueKey = install_test deviceKey = HMW_LC_Dim1L chNr = 03
2014-07-31_01:34:51 HM485_SetChannelState: valueKey = inhibit deviceKey = HMW_LC_Dim1L chNr = 03
2014-07-31_01:34:51 HM485_SetChannelState: valueKey = working deviceKey = HMW_LC_Dim1L chNr = 03

==> fhem-2014-07.log <==
2014.07.31 01:34:51 3: HM485_LAN: TX: (124) I[2](0,F,B)(1C) 00000001 -> 00009266 [5] 78(x) 02C8
2014.07.31 01:34:51 3: HM485_LAN: ACK: (124)
2014.07.31 01:34:51 3: HM485_LAN: Response: (124) 6902C800

==> HM485-log2014-07-31_01-19-04.log <==
2014-07-31_01:34:51 HM485_ProcessResponse: hmwId = 00009266 requestType = 78
2014-07-31_01:34:51 HM485_ProcessResponse: ( 53, 78) deviceKey = HMW_LC_Dim1L
2014-07-31_01:34:51 HM485_ProcessChannelState: name = HMW_LC_Dim1L_DR_JEQ0545966 Channel = 03 msgData = 6902C800 actionType = response
2014-07-31_01:34:51 HM485_ProcessChannelState: Channel = 03
2014-07-31_01:34:51 HM485_ChannelUpdate: name = HMW_LC_Dim1L_DR_JEQ0545966_03
2014-07-31_01:34:51 HM485_ChannelDoUpdate: name = HMW_LC_Dim1L_DR_JEQ0545966_03 value = 100

==> fhem-2014-07.log <==
2014.07.31 01:34:51 3: HM485: HMW_LC_Dim1L_DR_JEQ0545966_03: level -> 100

==> HM485-log2014-07-31_01-19-04.log <==
2014-07-31_01:34:51 HM485_ChannelDoUpdate: name = HMW_LC_Dim1L_DR_JEQ0545966_03 State = level_ valueKey = level value = 100
2014-07-31_01:34:51 HM485_ChannelDoUpdate: name = HMW_LC_Dim1L_DR_JEQ0545966_03 State = level_100

Vielen Dank, nun gefällt es mir. Solltest du noch mehr Logs brauchen, mach ich gerne für dich. Ich habe hier auch noch einen CUNO, der dank owagner HM485 kann, einmal zwischen ccu1 und fhem zum mitlauschen gehängt, falls ich hier auch noch mit Logs aushelfen sollte.

lg Harald

ps. könnte man nicht diese "2014.07.31 02:08:27 3: HM485_LAN: Alive: (254) 3030" Logmeldungen nicht auf verbose 4 oder 5 setzten, die nerven ganz schön.

gevoo · 31 Juli 2014, 10:03:18

Hallo Harald,

damit ist die Meldung weg. Die hat mich auch genervt.

Gruß gevoo

hglaser · 31 Juli 2014, 12:12:47

Zitatdamit ist die Meldung weg. Die hat mich auch genervt.

Danke gevoo
lg Harald

hglaser · 02 August 2014, 17:24:34

hallo gevoo,

falls du noch interessiert bist, könnten wir ja einmal mit der Konfiguration weitermachen. (Eventuell könnte man ja einen eigenen thread aufmachen, falls erwünscht). hier stimmt ja leider noch irgendwas nicht so ganz. Der Dimmer, und so wie es aussieht nicht nur der, ignoriert mich. Wenn ich z.B beim Dimmer Channel 3 das Logging einschalten will, sollte ja eigentlich so etwas wie

Code Auswählen


57 000010FF1400000001FFFF0AFF0AFFFFFFFFFF

am Ende, an das device geschickt werden. Tatsächlich geschickt wird aber nur so ein kurzer Teil,

Code Auswählen


57 000B0100

und ich gehe mal davon aus, daß der Dimmer diesen Befehl so nicht versteht.

Bisher habe ich leider nur Teile des Befehls "57" verstanden, und das auch nur für den dimmer, aber damit könnte man ja schon einmal anfangen. Dann tät ich mir mit der Nachvollziehbarkeit und dem Verständniss leichter.

Code Auswählen


Befehl 57 (write eeprom)
 
00 00 10 FF 14 00000001 FF FF 0A FE 0A FF 00009624
            ^  ^        ^  ^  ^  ^  ^  ^  ^
            |  |        |  |  |  |  |  |  |peeradresse vom IO_12_Sw7 wen nicht gepeert FFFFFFFF
            |  |        |  |  |  |  |  |ch:3 logging FF=ein ,FE=aus
            |  |        |  |  |  |  |ch:2 Zeit langer Tastendruck in ms
            |  |        |  |  |  |Schalter ch:2 FC,FD,FE,FF gleich wie ch:1
            |  |        |  |  |ch:1 Zeit langer Tastendruck in ms
            |  |        |  |schalter ch:1 FC=Schalter gesperrt, FD=Taster gesperrt, FE=Schalter, FF=Taster
            |  |        |noch keine ahnung bleibt bis jetzt immer gleich
            |  |zentrale
            |logging delay in ms

Könntest du wieder so schöne Logging messages reinbauen, und ich probier dann mal alles durch.

hier noch das logging wie es das 10_HM458 schickt:

Code Auswählen


H000092661E0000000157000B0100
H000000017900009266
H00009266180000000143
H000000011900009266

und hier wie es die CCU schickt:

Code Auswählen


H00009266780000000157000010FF1400000001FFFF0AFF0AFFFFFFFFFF
H000000011900009266
H000092667A0000000143
H000000013900009266

die komische Formatierung tut mir leid, aber so formatiert der CUNO die befehle am Bus, und mit dem kann man so schön mitlasuchen.

lg harald

geri · 03 August 2014, 13:32:21

Zitat von: gevoo am 28 Juli 2014, 21:07:09
Hallo Gerald,

das Konfigurationsproblem ließ sich nicht mit 10_HM485.pm lösen. Da mußte der Configurationsmanager ran. Den findest Du im Unterverzeichnis /FHEM/lib/HM485.
Neueste Version beiliegend.

Gruß gevoo

Hallo gevoo!

konntest du die entwicklung vorantreiben?

hab noch etwas rumprobiert. kann derzeit nur die config des channel 01 verändern. wenn ich die eingänge auf masse hänge kommt am eventmonitor bei channel 01, 07, 08, 10 und 12 ein "press_short" die anderen bleiben ohne werte

Code Auswählen

2014.08.03 13:17:33.733 3: HM485_LAN: Event: I[0](0,Y,F,B)(98) 0000DA42 -> FFFFFFFF [16] 41(A) 06190003014C45513032353233
2014.08.03 13:17:33.711 3: HM485: HMW_Sen_SC_12_DR_LEQ0252304_07: sensor -> 0
2014.08.03 13:17:33.671 3: HM485_LAN: Event: I[3](0,Y,F,B)(9E) 0000DA42 -> FFFFFFFF [4] 69(i) 06
2014.08.03 13:17:30.462 3: HM485_LAN: Event: I[3](1,Y,F,B)(BE) 0000B97B -> FFFFFFFF [16] 41(A) 0B120003064C45513030313635
2014.08.03 13:17:30.430 3: HM485: HMW_IO_12_Sw7_DR_LEQ0016534_12: press_short -> press_short 25
2014.08.03 13:17:30.369 3: HM485_LAN: Event: I[2](1,Y,F,B)(BC) 0000B97B -> FFFFFFFF [4] 4B(K) 0B
2014.08.03 13:17:27.949 3: HM485_LAN: Event: I[1](1,Y,F,B)(BA) 0000B97B -> FFFFFFFF [16] 41(A) 09120003064C45513030313635
2014.08.03 13:17:27.917 3: HM485: HMW_IO_12_Sw7_DR_LEQ0016534_10: press_short -> press_short 3
2014.08.03 13:17:27.863 3: HM485_LAN: Event: I[0](1,Y,F,B)(B8) 0000B97B -> FFFFFFFF [4] 4B(K) 09
2014.08.03 13:17:25.883 3: HM485_LAN: Event: I[3](1,Y,F,B)(BE) 0000B97B -> FFFFFFFF [16] 41(A) 07120003064C45513030313635
2014.08.03 13:17:25.850 3: HM485: HMW_IO_12_Sw7_DR_LEQ0016534_08: press_short -> press_short 43
2014.08.03 13:17:25.801 3: HM485_LAN: Event: I[2](1,Y,F,B)(BC) 0000B97B -> FFFFFFFF [4] 4B(K) 07
2014.08.03 13:17:24.726 3: HM485_LAN: Event: I[1](1,Y,F,B)(BA) 0000B97B -> FFFFFFFF [16] 41(A) 06120003064C45513030313635
2014.08.03 13:17:24.694 3: HM485: HMW_IO_12_Sw7_DR_LEQ0016534_07: press_short -> press_short 54
2014.08.03 13:17:24.649 3: HM485_LAN: Event: I[0](1,Y,F,B)(B8) 0000B97B -> FFFFFFFF [4] 4B(K) 06
2014.08.03 13:17:16.897 3: HM485_LAN: Event: I[3](1,Y,F,B)(BE) 0000B97B -> FFFFFFFF [16] 41(A) 00120003064C45513030313635
2014.08.03 13:17:16.865 3: HM485: HMW_IO_12_Sw7_DR_LEQ0016534_01: press_short -> press_short 36
2014.08.03 13:17:16.692 3: HM485_LAN: Event: I[2](1,Y,F,B)(BC) 0000B97B -> FFFFFFFF [4] 4B(K) 00

was brauchst du um die entwicklung weiter voranzutreiben?

ich verwende derzeit die 0.2.44.

gruss
Gerald

gevoo · 03 August 2014, 19:03:39

Hallo Harald und Gerald,

zur Cofiguration bin ich noch nicht gekommen. Ich kämpfe im Moment daran, daß der Raspi alle Kanäle vom HMW-IO-12-Sw14-DR erkennt. Wenn das fertig ist, machen wir mit der Configuration weiter. Bei mir haut das auch nicht hin ( Rolladen- Modul). Bitte noch etwas Geduld.
Die Sache mit dem neuen Thread ist eine gute Idee. Da reden wir dann nur über Configuration HMW.

Lg gevoo

Thorsten Pferdekaemper · 03 August 2014, 22:36:35

Hi,
vielleicht kann ich zu den EEPROM und Config-Geschichten etwas beitragen:

Der "W"-Befehl (0x57) ist so aufgebaut:
Nach dem "W" kommt die Startadresse im EEPROM (2 Byte), danach die Anzahl der zu schreibenden Bytes (ein Byte). Danach kommen die Daten. Die Anzahl der Datenbytes sollte 32 nicht überschreiten. Eine CCU scheint immer in 16er-Blöcken zu schreiben, daher auch die "000010" am Anfang.
Das Modul schreibt alles ohne zu prüfen ins EEPROM, was man ihm auf diese Art vorwirft. Insbesondere kann man das ganze EEPROM mit 0xFF vollschreiben. Das entspricht einem Factory-Reset.

Was der Kram im EEPROM bedeutet, kann man sich im Prinzip aus den Geräte-XMLs rauslesen. Die bekommt man mit der CCU-Firmware im Verzeichnis /Firmware/hs485types. Das für den HMW-LC-SW2-DR habe ich hier mal drangehängt. Dort findet man mit etwas Phantasie für die ersten 16 Bytes:
Byte 0: nichts, also 0xFF
Byte 1: logging delay in 100ms Schritten. 0x14 bedeutet also 2 Sekunden
Byte 2 bis 5: Adresse der Zentrale. Ich glaube, dass das Modul daran auch erkennt, dass es an eine Zentrale gepairt ist.
Byte 6: Das erste Bit steht für "DIRECT_LINK_DEACTIVATE". Ich nehme an, dass man damit Direktverknüpfungen zu anderen Modulen verhindern kann.
Byte 7, Bit 0: Wenn dieses Bit gelöscht wird, dann sendet das Modul beim Drücken und beim Loslassen jeweils ein Event.
Bit 1: Wenn dieses Bit gelöscht wird, dann werden Tastendrücke nicht mehr gesendet
Byte 8: Zeit für langen Tastendruck in 100ms. 0x0A ist also 1 Sekunde.
Byte 9 + 10: Dasselbe wie oben für Kanal 2, 7 und 8 sind für Kanal 1. (Das sind die Eingänge S1 und S2)
Byte 11, Bit 0: Logging für Ausgang 1. Wenn das gelöscht wird, dann sendet das Modul keine Änderungen am Ausgang mehr.
Byte 12: Wahrscheinlich leer (0xFF)
Byte 13, Bit 0: Logging für Ausgang 2
Byte 14: Wahrscheinlich leer (0xFF)

Ab Byte 15: Hier kommen 30 Blöcke zu je 28 Bytes. Jeder Block beschreibt einen Peer zu einem der beiden Aktoren (Ausgänge):
- Adresse des Sensors
- Kanal des Sensors
- Kanal des LC-SW2
- ...und viel Kram zu der genauen Funktion des Peerings, das ist mir bisher zu viel.

Ab Byte 0x357 kommen 28 Blöcke zu je 6 Bytes mit "ausgehenden" Links der Taster-Eingänge zu (anderen) Modulen.

Meiner Meinung nach sollte eine gute Implementierung immer nur das schreiben, was auch tatsächlich geändert wird. Wenn also nur ein Byte geändert wird, dann sollte man auch nur ein Byte schreiben. Bei Byte 7 geht glaube ich momentan was schief. Da müsste die FHEM-Implementierung wahrscheinlich korrigiert werden.

Noch eine Anmerkung zur CCU: Wenn man außerhalb der CCU die Konfig eines HMW-Moduls ändert, dann "sieht" die CCU das nicht. Die CCU lädt einmal beim Pairing den Inhalt des EEPROMs (mit einer Kombination aus E, e und R Messages) und geht danach davon aus, dass nur die CCU das jemals wieder ändert. Da die CCU (glaube ich) das EEPROM immer in 16er Blöcken schreibt, kann wahrscheinlich ziemlicher Blödsinn passieren.
FHEM sollte da etwas anders vorgehen. Am besten einmal öfter das EEPROM lesen. Das tut nicht weh, im Gegensatz zum übertriebenen Schreiben des EEPROM.

Gruß,
Thorsten

Dirk · 03 August 2014, 23:59:08

Hallo gevoo,

ich lese hier die letzten Tage im Tread leider nur gelegentlich mit. Wege fehlender Hardware im Urlaub konnte ich leider nicht so viel Beitragen. Dennoch danke dass du hier bei der Fehlerbehebung hilfst.

Der Urlaub ist nun vorbei und damit wollte ich auch wieder die HM485-Module weiter entwickeln.
Kannst du mir kurz zusammenfassend sagen was du alles gefixt hast, gerne auch per PM.

Ich habe vor dem Urlaub noch begonnen die Konfigurationsfiles der HMW-Devices umzustellen.
Dabei habe ich auch einige Fehler behoben. Auch die Konfiguration wird sich hier ggf. noch einmal ändern.
Somit sollten wir sehen dass wir deine Änderungen hier mit meinem Code zusammenführen können.

Leider ist der Code noch nicht auf dem Stand dass ich den veröffentlichen kann.

Zitat von: Thorsten Pferdekaemper am 03 August 2014, 22:36:35
Meiner Meinung nach sollte eine gute Implementierung immer nur das schreiben, was auch tatsächlich geändert wird.

So hatte ich das ursprünglich auch mal geplant.
Bei Umfangreichen Änderungen macht es aber ggf. trotzdem Sinn blockweise zu schreiben. Ansonsten hat man recht viele Einzelmessages mit EEPROM-Daten.

ZitatBei Byte 7 geht glaube ich momentan was schief. Da müsste die FHEM-Implementierung wahrscheinlich korrigiert werden.

Ich glaube da gibt es noch ein paar Bugs.

ZitatAm besten einmal öfter das EEPROM lesen. Das tut nicht weh, im Gegensatz zum übertriebenen Schreiben des EEPROM.

Normalerweise sollte nur eine Zentrale die Kontrolle über die Devices haben. Davon geht auch die CCU aus. Das Ziel ist es, das FHEM alles machen kann was die CCU macht.
In FHEM gibt es aber jetzt schon die Möglichkeit desn EEPROM der Devices gezielt auszulesen. Das kann die CCU so nicht. Ich denke das sollte ausreichen. Ansonsten müsste man vor jeder Config-Änderung erst die Daten lesen.

Gruß
Dirk

gevoo · 04 August 2014, 13:17:45

Hallo Dirk,

ich habe im Wesentlichen das Modul 10_HM485.pm weiterentwickelt. Wichtige Punkte sind:
- Verzögerung der Initialisierung beim Startvorgang, da sonst Raspi und auch der Bus bei mehreren Modulen nicht hinterherkommen.
--> siehe Define
- HM485_GetConfig habe ich erweitert, so daß alle Channels angelegt werden, auch ohne zutun des Benutzers. Alle States der Channels werden abgefragt und gespeichert. Beim HMW_IO_12_SW14 gibt es da noch Probleme bei den Eingängen. Dort wird in Device:getChannelBehaviour der falsche Pfad zu den Werrten ermittelt.
- in HM485_ProcessResponse wurde eine kontinuierliche Abfrage des Level für Rollo- und Dimm- Modul eingebaut, solange sich was bewegt. Für den HMW_IO_12_SW14 wurde Response 72 eingefügt, weils sonst bei diesem Modul die Channels nicht gesetzt werden.
- In HM485_ProcessEvent wird die kontinuierliche Abfrage des Level für Rollo- und Dimm- Modul angestoßen, wenn einer eine Taste betätigt.
- Weiterhin noch einige Kleinigkeiten, die zur Funktionsverbesserung führen.

Alle Module, die am Anfang des Quelltextes erwähnt werden funktionieren mittlerweile ohne nennenswerte Probleme.

Ich würde die Arbeiten an diesem Modul noch fertig machen. Du kannst dich parallel mit der Problematik Konfiguration beschäftigen.

Lg gevoo

gevoo · 04 August 2014, 13:21:29

Hallo Torsten,

ich habe leider auch keine CCU, deshalb standen mir die xml- Dateien bisher nicht zur Verfügung. Würde es nicht Sinn machen mit einem xml- Parser die Verküpfungen gleich zu übernehmen. Dann könnte man auf Veränderungen schnell reagieren bzw. Verbessherungen außerhalb des Quelltextes der Module einbringen.

Gruß gevoo

Dirk · 04 August 2014, 13:34:04

Hi gevoo.

Ich schaue mir das mal an. Kann sein dass ich hier auch schon was davon gefixt hatte.

Zitat von: gevoo am 04 August 2014, 13:21:29
Würde es nicht Sinn machen mit einem xml- Parser die Verküpfungen gleich zu übernehmen. Dann könnte man auf Veränderungen schnell reagieren bzw. Verbessherungen außerhalb des Quelltextes der Module einbringen.

Das brauchen wir nicht. In den Device-PM-Files steht der Inhalt vom XML für FHEM transformiert drinn.
Derzeit aber noch nicht für alle Devices und noch nicht ganz korrekt.
Das habe ich hier aber schon geändert und ergänzt. Dafür gab es aber auch ein paar Änderungen im Parsing.
Im Prinzip muss "nur" noch das Parsing dieser Files fertig gemacht werden.

Gruß
Dirk

Thorsten Pferdekaemper · 04 August 2014, 15:07:40

Zitat von: gevoo am 04 August 2014, 13:21:29ich habe leider auch keine CCU, deshalb standen mir die xml- Dateien bisher nicht zur Verfügung.

Ich habe auch keine. Du kannst Dir aber zumindest für die CCU1 die Firmware von eq3 runterladen. Ich glaube, dass das als .tar.gz-File kommt. Wenn man das auspackt, dann kommt man im Prinzip an alles dran. (Genau weiß ich's momentan auch nicht mehr...).
Gruß,
Thorsten

Homematic wired

hglaser

hglaser

hglaser

hglaser

hglaser