Hi,
ich habe bisher mit einem recht alten Stand der HM485_LAN Lib gearbeitet, um meine Homematic Geräte einzubinden. (Ich hatte mal (Jahre her) ein Update probiert, aber es hat nicht alles funktioniert, also bin ich beim alten Stand geblieben.)
Nun läuft mein FHEM recht instabil (irgendwas verursacht Aussetzer von mehreren Minuten :-( ). Um das zu beheben, kann ich ja hier nicht fragen mit einem uralten Stand. Also: update all.
Startet wieder, läuft, aber der alte Fehler, nicht alle Wired Devices werden richtig geladen.
Der configStatus bleibt bei READING. Und bei einem set ... getConfig findet sich im Log nur: HM_LAN: Initialisierung von Modul 00009BB3
. Nicht gefolgt von diesem Lese Eeprom etc.
Was ich habe und auch jetzt Jahre lief ist eine physische CCU2 mit einem LAN-GW und ein extra LAN-GW für fhem. Dieses hab ich jetzt auch nochmal gegen einen Digitus getauscht, leider ohne Erfolg.
Ein list vom Device sieht so aus:
Internals:
DEF 00009BB3
FUUID 5cd535f1-f33f-a63b-c286-534af787190434f8
FVERSION 10_HM485.pm
FailedConfigReads 0
IODev HM_LAN
NAME Kueche_Rollo_rechts
NR 298
STATE ???
TYPE HM485
channel_01 Kueche_Rollo_rechts_01
channel_02 Kueche_Rollo_rechts_02
channel_03 Kueche_Rollo_rechts_03
eventCount 4
READINGS:
2022-08-07 12 IODev HM_LAN
2022-08-07 12 configStatus READING
cache:
sets Unknown argument ?, choose one of getConfig raw reset
01:
allowedSets
sets Unknown argument ?, choose one of
02:
allowedSets
sets Unknown argument ?, choose one of
03:
allowedSets
sets Unknown argument ?, choose one of
linkParams:
actuator:
channels 00
sensor:
channels 00
Attributes:
IODev HM_LAN
room Kueche
Und vom IODev (z.Z. der Stick) so:
Internals:
DEF localhost:2000
DeviceName localhost:2000
FD 4
FUUID 62ef641e-f33f-ef2a-0cf0-f2efce13c66a29a3
FVERSION 00_HM485_LAN.pm:?/2022-08-05
HM485d_CommandLine ./FHEM/lib/HM485/HM485d/HM485d.pl --hmwId 00000002 --serialNumber SGW0123456 --device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AH02G0VD-if00-port0 --localPort 2000 --logfile log/HM_LAN-Stick-%Y-%m.log
HM485d_PID 25259
HM485d_STATE started
HM_LAN_MSGCNT 69
HM_LAN_TIME 2022-08-07 12:34:07
InterfaceType HMW-SOFT-GW
LASTInputDev HM_LAN
Last_Sent_RAW_CMD 0000BCDA 1A 00000002 6E
Last_Sent_RAW_CMD_State NACK
MSGCNT 69
NAME HM_LAN
NR 26
PARTIAL
ProtokolVersion 01
STATE opened
SerialNumber SGW0123456
TYPE HM485_LAN
Version 0.2.2
currentQueueId 0
eventCount 1
hmwId 00000002
msgCounter 142
queueId 58
queueRunning 0
READINGS:
2022-08-07 12:13:04 state opened
centrals:
00000001:
DEF 00000001
FUUID 5cd535ef-f33f-a63b-813e-2c3586ed097c6ddb
FVERSION 10_HM485.pm:0.081600/2019-11-15
FailedConfigReads 0
IODev HM_LAN
NAME CCU
NR 56
STATE ACK
TYPE HM485
channel_01 CCU_01
channel_02 CCU_02
channel_03 CCU_03
channel_04 CCU_04
channel_05 CCU_05
channel_06 CCU_06
channel_07 CCU_07
channel_08 CCU_08
channel_09 CCU_09
channel_10 CCU_10
channel_11 CCU_11
channel_12 CCU_12
channel_13 CCU_13
channel_14 CCU_14
channel_15 CCU_15
channel_16 CCU_16
channel_17 CCU_17
channel_18 CCU_18
channel_19 CCU_19
channel_20 CCU_20
channel_21 CCU_21
channel_22 CCU_22
channel_23 CCU_23
channel_24 CCU_24
channel_25 CCU_25
channel_26 CCU_26
channel_27 CCU_27
channel_28 CCU_28
channel_29 CCU_29
channel_30 CCU_30
channel_31 CCU_31
channel_32 CCU_32
channel_33 CCU_33
channel_34 CCU_34
channel_35 CCU_35
channel_36 CCU_36
channel_37 CCU_37
channel_38 CCU_38
channel_39 CCU_39
channel_40 CCU_40
channel_41 CCU_41
channel_42 CCU_42
channel_43 CCU_43
channel_44 CCU_44
channel_45 CCU_45
channel_46 CCU_46
channel_47 CCU_47
channel_48 CCU_48
channel_49 CCU_49
channel_50 CCU_50
eventCount 4
virtual 1
READINGS:
2022-08-07 12:13:07 D-deviceKey HMW_CENTRAL
2022-08-07 12:11:35 IODev HM_LAN
2022-08-07 12:13:07 configStatus OK
2022-08-07 12:13:07 state ACK
cache:
peers
ctrl:
00007462 1A
00007470 1C
00007477 1A
00007655 1C
00007B47 1C
00007B55 1C
00007B60 1A
000081A3 1C
000092CF 1C
0000936D 1C
00009B31 1C
00009B74 1C
00009B7D 1C
00009B81 1C
00009DD1 1C
0000A7D3 1A
0000BCDA 1A
0000BD92 1C
0000C2B2 1C
0000D500 1C
0000D501 1C
keepalive:
ok 1
retry 0
sendQueue:
Attributes:
HM485d_bind 1
HM485d_device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AH02G0VD-if00-port0
HM485d_logfile log/HM_LAN-Stick-%Y-%m.log
HM485d_startTimeout 8
hmwId 00000002
room System
Wenn ich in dem verbose: 5 setze und dann ein set ... getConfig mache, sieht das Log so aus:
2022.08.07 12:44:57 5: HM_LAN: HM485_GetNewMsgQueue
2022.08.07 12:44:57 3: HM_LAN: Initialisierung von Modul 00009BB3
2022.08.07 12:45:01 5: HM_LAN: HM485_LAN_Write TX: 147
2022.08.07 12:45:01 5: DevIo_SimpleWrite HM_LAN: fd02934b
2022.08.07 12:45:01 5: HM_LAN: HM485_LAN_parseIncommingCommand: MsgId: 147 Cmd: 97
2022.08.07 12:45:01 5: HM_LAN: HM485_LAN_parseIncommingCommand: Alive: (147) 00 AliveStatus: 00
Wenn noch was fehlt, bitte einfach melden.
Probiert habe ich noch, eine neue cfg mit nur dem Stick zu nehmen und dann ein discovery zu machen. Der Stick hat dann die wohl 60 Devices gefunden, aber nur 2 angelegt :-(. Bei allen anderen derselbe Fehler: Device not completely loaded yet. Try again later.
Bin für alle Tipps dankbar,
auch warum ich nicht mein altes fhem Verzeichnis (mit der alten Lib) nehmen kann und alles wieder ist wie vorher. Auch wenn ich das tue, werden jetzt meine Devices nicht mehr richtig geladen. :-(
Homatrix
Was ich jetzt nicht verstehe, sind die Geräte jetzt nun per CCU2 oder per HM-Stick (über FHEM) angebunden?
Könntest Du uns zusätzlich mehr Technische Daten geben?
Auf was für einer Maschine, mit welcher Distri in welcher version etc.
Das mit der CCU2 war nur eine Info. Die läuft und die Geräte lassen sich steuern.
Nebenher läuft noch ein FHEM z.Z. mit dem Digitus (vorher mit einem HM-LAN-GW), von dem ich die Geräte bisher auch steuern konnte.
FHEM läuft auf einem Raspi, der wiederrum läuft mit Raspbian GNU/Linux 10.
Hi,
hängt da jetzt im selben HM-Wired-"Netzwerk" sowohl der Digitus mit FHEM drin als auch die CCU2 mit einem HM-Original-Gateway? Wenn das so ist, dann wundere ich mich stark, dass das tatsächlich jemals funktioniert hat. Hast Du schon einmal versucht, die CCU2 abzuklemmen (bzw. das HM-Gateway)?
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 07 August 2022, 22:06:50
Hi,
hängt da jetzt im selben HM-Wired-"Netzwerk" sowohl der Digitus mit FHEM drin als auch die CCU2 mit einem HM-Original-Gateway? Wenn das so ist, dann wundere ich mich stark, dass das tatsächlich jemals funktioniert hat.
Genau so ist es.
Du willst andeuten, dass das gar nicht gehen sollte? (Das tat es zumindest in den letzten Jahren.)
Muss man sich also entscheiden, FHEM oder CCU? Ich hatte das damals mit dem Gedanken 'wenn mal das eine ausfällt, hab ich wenigstens noch das andere' aufgebaut.
Wenn ich nun die CCU wählen würde (und in FHEM die HMCCUDEV Lib), dann würde es ja immer über die CCU laufen. :(
Dann weiß jetzt schon, was ausfällt kurz vorm nächsten Urlaub. ;D
Zitat
Hast Du schon einmal versucht, die CCU2 abzuklemmen (bzw. das HM-Gateway)?
Abgeklemmt hab ich die noch nicht. Ich hatte mal das LAN Kabel gezogen, damit keine Daten Richtung CCU gehen, während eines getConfig, aber das half nicht.
Ich werds mal mit abklemmen probieren.
Du könntest es auch einfach mit "Strom aus" probieren ...
So hab ich es gemacht. CCU2 aus, GW aus, FHEM neu gestartet.
Der configStatus von allen WIRED Geräten bleibt READING, ein paar tun, viele nicht.
:(
Wenn ich jetzt ignorieren würde, dass es jahrelang lief (was mir echt schwer fällt ;) ), welche Möglichkeiten habe ich denn dann?
Da die CCU2 ganz hervorragend läuft, möchte ich die behalten. Dann könnt ich nur mittels HMCCUDEV die Geräte importieren und dann steuern, oder? Gibt es noch andere Möglichkeiten?
Homatrix
Du kannst auch zum Testen mal in der "HM485d_CommandLine" --verbose 4 zufügen,
und dann bei einem "set ... getConfig" einen log Auszug und die log/HM_LAN-Stick.. posten
Gruß Ralf
Hm, bei 4 hab ich nix gesehen. Daher nochmal mit verbose 5. Da scheint auch nix anzukommen, wenn ich set .. getConfig mache.
2022.08.08 15:24:28.050 3: SERIAL device opened
2022.08.08 15:24:28.053 3: HM485d: SERIALbaudrate=19200, databits=8, parity=even, stopbits=1, handshake=none
2022.08.08 15:24:28.054 2: HM485d: SERIAL connected to device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AH02G0VD-if00-port0
2022.08.08 15:24:28.054 1: HM485d: Server started ...
2022.08.08 15:24:28.323 4: Connection accepted from HM485d_127.0.0.1_38512
2022.08.08 15:24:28.324 4: HM485d: Tx: H00,01,HMW-SOFT-GW,0.2.2,SGW0123456
2022.08.08 15:24:28.347 4: HM485d: Rx: FD3E30312C303030300D0A
2022.08.08 15:24:48.351 4: HM485d: Rx: FD02024B
2022.08.08 15:24:48.351 4: HM485d: Tx: FD03026100
2022.08.08 15:25:08.436 4: HM485d: Rx: FD02034B
2022.08.08 15:25:08.437 4: HM485d: Tx: FD03036100
2022.08.08 15:25:28.448 4: HM485d: Rx: FD02044B
2022.08.08 15:25:28.449 4: HM485d: Tx: FD03046100
Aber im fhem Log taucht schon dieses "HM_LAN: Initialisierung von Modul 00009BB3" auf.
ZitatDer Stick hat dann die wohl 60 Devices gefunden, aber nur 2 angelegt
Hast Du demnach 60 Homematic Wired module?
Was für Typen sind die beiden die angelegt wurden?
Was für Typen sind der Rest?
Wenn Du an einem Modul angeschlossenen Taster oder Kontakt betätigst, dann müsste eigentlich im HM_LAN-Stick log was stehen.
z.B.
2022.08.08 15:46:19.776 3: HM485d: Rx: I[1](0,Y,F,B)(9A) 42ABFFEE -> FFFFFFFF [6] 4B(K) 170042 {98FA}
2022.08.08 15:46:19.776 4: HM485d: Tx: FD0F0065FFFFFFFF9A42ABFFEE4B170042
2022.08.08 15:47:35.528 3: HM485d: Rx: I[0](0,Y,F,B)(98) 42ABFFEE -> 00000004 [6] 69(i) 00C800 {ECE8}
2022.08.08 15:47:35.528 4: HM485d: Tx: FD0F0065000000049842ABFFEE6900C800
4B ist der Taster und 69 ist der Kontakt.
Bei einem get config oder get info sollte eigentlich im HM_LAN-Stick log was stehen.
z.B.
2022.08.08 15:59:28.720 3: HM485d: Tx: (205:1) I[0](0,F,B)(18) 00000004 -> 42ABFFEE [3] 68(h) {6604}
2022.08.08 15:59:28.770 3: HM485d: Rx: Response: (205) I[2](0,F,B)(1C) 42ABFFEE -> 00000004 [4] 97(�) 01 {DCEA}
Zitat von: Ralf9 am 08 August 2022, 16:26:43
Hast Du demnach 60 Homematic Wired module?
Ja, in etwa.
ZitatWas für Typen sind die beiden die angelegt wurden?
Das waren Rollläden. also HMW-LC-Bl1-DR.
ZitatWas für Typen sind der Rest?
Alles, Rollläden, Dimmer, Switches.
Zitat
Wenn Du an einem Modul angeschlossenen Taster oder Kontakt betätigst, dann müsste eigentlich im HM_LAN-Stick log was stehen.
z.B.
2022.08.08 15:46:19.776 3: HM485d: Rx: I[1](0,Y,F,B)(9A) 42ABFFEE -> FFFFFFFF [6] 4B(K) 170042 {98FA}
2022.08.08 15:46:19.776 4: HM485d: Tx: FD0F0065FFFFFFFF9A42ABFFEE4B170042
2022.08.08 15:47:35.528 3: HM485d: Rx: I[0](0,Y,F,B)(98) 42ABFFEE -> 00000004 [6] 69(i) 00C800 {ECE8}
2022.08.08 15:47:35.528 4: HM485d: Tx: FD0F0065000000049842ABFFEE6900C800
4B ist der Taster und 69 ist der Kontakt.
Das hab ich mal probiert bei einem Dimmer. Dann hab ich das im Log stehen.
2022.08.08 18:38:31.658 3: HM485d: Rx: I[1](2,Y,F,B)(DA) 00007448 -> FFFFFFFF [6] 4B(K) 0200B6 {FE28}
2022.08.08 18:38:31.659 4: HM485d: Tx: FD0F0065FFFFFFFFDA000074484B0200B6
2022.08.08 18:38:31.675 3: HM485d: Rx: I[2](2,Y,F,B)(DC) 00007448 -> 00009341 [6] 4B(K) 0202B4 {7440}
2022.08.08 18:38:31.675 4: HM485d: Tx: FD0F006500009341DC000074484B0202B4
2022.08.08 18:38:31.690 3: HM485d: Rx: I[0](2,Y,F,B)(D8) 00009341 -> 00007448 [6] 69(i) 028C40 {14E4}
2022.08.08 18:38:31.691 4: HM485d: Tx: FD0F006500007448D80000934169028C40
2022.08.08 18:38:31.706 3: HM485d: Rx: ACK(0,B)(19) 00007448 -> 00009341 [2] {5466}
2022.08.08 18:38:31.724 3: HM485d: Rx: I[3](0,Y,F,B)(9E) 00007448 -> FFFFFFFF [18] 41(A) 021B0003004A455130303830363637 {558C}
2022.08.08 18:38:31.726 4: HM485d: Tx: FD1B0065FFFFFFFF9E0000744841021B0003004A455130303830363637
2022.08.08 18:38:33.625 3: HM485d: Rx: I[1](2,Y,F,B)(DA) 00009341 -> 00000002 [6] 69(i) 028C40 {99DA}
2022.08.08 18:38:33.627 5: SW: fd000093413900000002021aca
2022.08.08 18:38:33.629 3: HM485d: Tx: ACK(1,B)(39) 00000002 -> 00009341 [2] {1ACA}
2022.08.08 18:38:33.629 4: HM485d: Tx: FD0F006500000002DA0000934169028C40
Der Dimmer hat diese Direktverbindung zur CCU und funktioniert daher. In FHEM sieht der so aus und läßt sich auch nicht mehr schalten:
Internals:
DEF 00009341
FUUID 5cd535ef-f33f-a63b-d805-20835c084f744f29
FVERSION 10_HM485.pm
FailedConfigReads 0
IODev HM_LAN
NAME Essen_Dimmer
NR 52
RawDeviceType 20
RawFwVersion 771
STATE ACK
TYPE HM485
channel_01 Essen_Dimmer_01
channel_02 Essen_Dimmer_02
channel_03 Essen_Dimmer_03
eventCount 11
READINGS:
2022-08-08 15 D-deviceKey HMW_LC_DIM1L_DR
2022-08-08 15 D-fwVersion 3.03
2022-08-08 15 D-serialNr JEQ0546088
2022-08-08 15 IODev HM_LAN
2022-08-08 18 configStatus READING
2022-08-08 18 state ACK
cache:
sets Unknown argument ?, choose one of getConfig raw reset
01:
allowedSets press_short press_long
sets Unknown argument ?, choose one of press_long press_short
02:
allowedSets press_short press_long
sets Unknown argument ?, choose one of press_long press_short
03:
allowedSets level on off inhibit install_test
sets Unknown argument ?, choose one of inhibit install_test level off on blink intervals on-till off-till-overnight on-till-overnight off-till off-for-timer on-for-timer
linkParams:
actuator:
address_start 876
address_step 6
channel_param channel
channels 01 02
count 24
peer_param actuator
type link
parameter:
HASH(0x3497df8)
HASH(0x34980f8)
sensor:
address_start 12
address_step 54
channel_param channel
channels 03
count 16
peer_param sensor
type link
parameter:
HASH(0x346e808)
HASH(0x346f3c8)
HASH(0x3471160)
HASH(0x3472060)
HASH(0x3472d28)
HASH(0x3474a48)
HASH(0x34774a8)
HASH(0x3477928)
HASH(0x3477b98)
HASH(0x3477e08)
HASH(0x34369c8)
HASH(0x3436c38)
HASH(0x3437010)
HASH(0x34373e8)
HASH(0x3437838)
HASH(0x3485a48)
HASH(0x3485e20)
HASH(0x3486270)
HASH(0x34864e0)
HASH(0x3486750)
HASH(0x348b4b0)
HASH(0x348b990)
HASH(0x348be58)
HASH(0x348d338)
HASH(0x348d800)
HASH(0x348dcc8)
HASH(0x348e190)
HASH(0x348e468)
HASH(0x348e720)
HASH(0x348e9d8)
HASH(0x348eb88)
HASH(0x348f0e0)
HASH(0x348f358)
HASH(0x348f5c8)
HASH(0x348f838)
HASH(0x348faa8)
HASH(0x348fd18)
HASH(0x34900f0)
HASH(0x34904e8)
HASH(0x3490938)
HASH(0x3490d10)
HASH(0x34910e8)
HASH(0x3492550)
HASH(0x34927c0)
HASH(0x3492a30)
HASH(0x3492ca0)
HASH(0x3493180)
HASH(0x3493668)
HASH(0x3493b30)
HASH(0x3493ff8)
HASH(0x34954d8)
HASH(0x34959a0)
Attributes:
IODev HM_LAN
room Essen
Zitat
Bei einem get config oder get info sollte eigentlich im HM_LAN-Stick log was stehen.
z.B.
2022.08.08 15:59:28.720 3: HM485d: Tx: (205:1) I[0](0,F,B)(18) 00000004 -> 42ABFFEE [3] 68(h) {6604}
2022.08.08 15:59:28.770 3: HM485d: Rx: Response: (205) I[2](0,F,B)(1C) 42ABFFEE -> 00000004 [4] 97(�) 01 {DCEA}
Das hab bei dem obigen auch probiert:
set Essen_Dimmer getConfig Leider ohne Erfolg. In dem Log steht nichts neues.
ZitatDas hab ich mal probiert bei einem Dimmer. Dann hab ich das im Log stehen.
2022.08.08 18:38:31.658 3: HM485d: Rx: I[1](2,Y,F,B)(DA) 00007448 -> FFFFFFFF [6] 4B(K) 0200B6 {FE28}
..
2022.08.08 18:38:33.625 3: HM485d: Rx: I[1](2,Y,F,B)(DA) 00009341 -> 00000002 [6] 69(i) 028C40 {99DA}
2022.08.08 18:38:33.629 3: HM485d: Tx: ACK(1,B)(39) 00000002 -> 00009341 [2] {1ACA}
Die Verbindung zwischen dem HM485d und den Modulen sieht gut aus.
ZitatDas hab bei dem obigen auch probiert: set Essen_Dimmer getConfig Leider ohne Erfolg. In dem Log steht nichts neues.
Es sieht nach einem Problem zwischen dem fhem-Modul und dem HM485d aus.
Bei einem "get config" sollte Im log vom HM485d (HM_LAN-Stick log) ein Tx Eintrag stehen.
Evtl hat Thorsten eine Idee
Da fällt mir ein .... Berechtigungsproblem?
ls -lha /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AH02G0VD-if00-port0
Es kann evtl sein, daß ein discovery nicht bei allen Modul Typen sauber funktioniert.
Hast Du schon mal versucht ein Modul zu löschen und dann bei diesem Modul eine Taste oder Kontakt zu betätigen?
Das Modul müsste dann wieder per Autocreate angelegt werden.
Die Rechte sehen so aus.
ll /dev/serial/by-id/
insgesamt 0
lrwxrwxrwx 1 root root 13 Aug 8 12:19 usb-0658_0200-if00 -> ../../ttyACM1
lrwxrwxrwx 1 root root 13 Aug 8 12:19 usb-1a86_USB2.0-Serial-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Aug 8 12:19 usb-EnOcean_GmbH_EnOcean_USB_300_DB_FTYL8O31-if00-port0 -> ../../ttyUSB2
lrwxrwxrwx 1 root root 13 Aug 8 12:19 usb-FTDI_FT232R_USB_UART_AH02G0VD-if00-port0 -> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 Aug 8 12:19 usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_00506C7D-if00-port0 -> ../../ttyUSB3
lrwxrwxrwx 1 root root 13 Aug 8 12:19 usb-Texas_Instruments_TI_CC2531_USB_CDC___0X00124B001CD4E6D9-if00 -> ../../ttyACM0
Ich denk, das paßt.
Bzgl. autocreate bekomme ich
HM_LAN: Device 00009DE9 not defined yet. We need the type for autocreate
Wenn ich das dann anlege per define, ist es zwar da, aber wieder ohne Initialisierung und das set ... getConfig tut nix.
Wenn man es dann in der CCU schaltet, dann hab ich im Log:
2022.08.09 10:55:07 4: HM_LAN: Event:HASH(0xa25d380)
2022.08.09 10:55:07 3: Kueche_Rollo_links: HM485_ProcessChannelState: hmwId = 00009DE9 No Device Key
Wenn Du das Modul gelöscht hast, und dann am Modul einen angeschlossenen Taster drückst, dann müsste im log vom HM485d (HM_LAN-Stick log) in etwa folgendes stehen:
3: HM485d: Rx: I[1](2,Y,F,B)(DA) 00003E95 -> FFFFFFFF [6] 4B(K) 0B008E {2E94}
3: HM485d: Rx: I[2](2,Y,F,B)(DC) 00003E95 -> FFFFFFFF [18] 41(A) 0B1B00030047455130323534343130 {5750}
3: HM485d: Tx: (2:1) I[0](0,Y,F,B)(98) 00000001 -> 00003E95 [3] 68(h) {6932}
3: HM485d: Rx: Response: (2) I[3](0,F,B)(1E) 00003E95 -> 00000001 [4] 1B(00 {EB34}
3: HM485d: Tx: ACK(3,B)(79) 00000001 -> 00003E95 [2] {680A}
Mit "68(h)" fragt fhem den Modul type for autocreate ab.
Das Modul sendet dann den Typ zurück.
In diesem Fall ist es 1B HMW-IO-12-FM. Beim HMW-LC-BL1-DR ist es 15.
Wenn das Modul nicht per Autocreate angelegt wird, macht es auch keinen Sinn es manuell per define anzulegen.
Evtl wird das "set ... getConfig" nur ausgeführt, wenn das Modul sauber per Autocreate angelegt wurde.
In das Log hab ich vergessen zu schauen. Da steht bei einem gelöschten und dann angeklicktem:
2022.08.09 11:31:32.721 3: HM485d: Rx: I[3](0,F,B)(1E) 00000001 -> 00009DE9 [5] 78(x) 02B4 {A5D0}
2022.08.09 11:31:32.754 3: HM485d: Rx: I[0](3,F,B)(78) 00009DE9 -> 00000001 [6] 69(i) 02C820 {09B6}
2022.08.09 11:31:32.755 4: HM485d: Tx: FD0F0065000000017800009DE96902C820
2022.08.09 11:31:32.769 3: HM485d: Rx: ACK(0,B)(19) 00000001 -> 00009DE9 [2] {E3FC}
Wenn ich das nicht selbst anlegen soll, wie erfährt denn dann das autocreate den Typ? Kann ich den auch irgendwo hinterlegen?
Demnach hat die CCU die hmwId 00000001 und fhem hat die hmwId 00000002
Im log ist nur zu sehen wie Du mit der CCU2 im Modul 00009DE9 was schaltest, damit wird bei fhem kein autocreate ausgelöst.
Wenn bei gelöschtem Modul ein am Modul angeschlossener Taster oder Kontakt betätigt wird, dann holt sich fhem mit 68(h) den Typ.
Das lässt sich auch am fhem log vom IODev (Name HM_LAN) sehen:
z.B.
2022.08.09 11:54:09.798 4: HM_LAN: TX: (7) I[1](0,F,B)(1A) 00000002 -> 00009DE9 [3] 68(h)
Achso, am Gerät. Jetzt hab ich das Gerät in FHEM gelöscht und dann am Gerät Rolladen hoch gedrückt.
Dann kommt im Stick Log:
2022.08.09 12:45:29.253 3: HM485d: Rx: I[3](2,Y,F,B)(DE) 00009DE9 -> FFFFFFFF [6] 69(i) 02B510 {31AC}
2022.08.09 12:45:29.253 4: HM485d: Tx: FD0F0065FFFFFFFFDE00009DE96902B510
Und im fhem.log weiterhin:
2022.08.09 12:45:29 4: HM_LAN: Event:HASH(0xa0f2f40)
2022.08.09 12:45:29 4: HM_LAN: Device 00009DE9 not defined yet. We need the type for autocreate
Leider ist das nicht ganz das, was kommen sollte.
Beim Drücken eines Tasters sollte sowas im log stehen, Du kannst es auch mal mit einem anderen Modultyp versuchen und die Taste auch mal ein paar mal drücken
2022.08.08 18:38:31.658 3: HM485d: Rx: I[1](2,Y,F,B)(DA) 00007448 -> FFFFFFFF [6] 4B(K) 0200B6 {FE28}
2022.08.08 18:38:31.724 3: HM485d: Rx: I[3](0,Y,F,B)(9E) 00007448 -> FFFFFFFF [18] 41(A) 021B0003004A455130303830363637 {558C}
Bei den beiden Modulen die in fhem vollständig geladen wurden, kannst Du da mit fhem im Modul was schalten?
Danke Ralf9 für deinen Versuch zu helfen!
Aber es scheint ja so, als sollt das gar nicht gehen und ich kann bei 60 Geräten nicht ewig rumprobieren. Die Frau will Resultate. Auf einmal errungenen Komfort mag man nur schwerlich verzichten. ;D
Deshalb lösch ich jetzt alle Wired Geräte und füge sie mit HMCUUDEV wieder dazu. (wird hoffentlich nicht ewig dauern)
Danke trotzdem!
Funktionierts mit der CCU2 bei allen Modulen zuverlässig?
Wenn Du an die Module angeschlossene Taster drückst, werden die von der CCU2 immer erkannt?
Ja, absolut.
Ich war am Anfang skeptisch, deswegen ja auch 2 verschiedene Wege, um auf meine Geräte zugreifen zu können. Aber ich hab die CCU2 seit sie rausgekommen ist und die läuft absolut zuverlässig, keinerlei Ausfälle, keinerlei Fehlfunktionen.
Habs bei mir mal auf meinem Testsystem getestet.
Bei den fhem Modulen und der lib verwende ich aber nicht die aktuelle Version von Thorsten. Ich hab eigene Anpassungen und Erweiterungen eingebaut.
Evtl kann mal jemand testen ob es sich mit den aktuellen Modulen und lib von Thorsten genauso verhält.
Wichtig: Das iodev HM485_LAN muß den state opened haben.
Ich hatte zum Testen kein USB to RS485 converter wie z.B. der Digitus angeschlossen. Es sollte demnach egal sein ob der Digitus und HM Wired Module angeschlossen sind.
Ich habe mit define ein Test device angelegt:
define HMW_Test HM485 12345678
Im fhem log steht dann:
2022.08.13 10:13:48.683 2 : hm485: Assigned 12345678 as HMW_Test
2022.08.13 10:13:48.683 3 : HMW_Test: HM485_SetConfigStatus alt = PENDING neu = Get Infos
2022.08.13 10:13:48.683 3 : hm485: Initialisierung von Modul 12345678
2022.08.13 10:13:48.692 4 : hm485: TX: (27) I[3](0,F,B)(1E) 00000004 -> 12345678 [3] 68(h)
2022-08-13 10:13:48.687 Global global DEFINED HMW_Test
2022-08-13 10:13:48.690 HM485 HMW_Test Get Infos
2022.08.13 10:13:49.298 3 : HMW_Test: HM485_SetConfigStatus alt = Get Infos neu = FAILED
2022.08.13 10:13:49.298 3 : hm485: SetStateNack RESPONSE TIMEOUT for 12345678
2022-08-13 10:13:49.303 HM485 HMW_Test RESPONSE TIMEOUT
2022-08-13 10:13:49.303 HM485 HMW_Test FAILED
im log vom HM485d.pl daemon steht (bei einem get config steht dies auch im log):
2022.08.13 10:13:48.690 4: SERIAL: TX: fd123456781e0000000403688682
2022.08.13 10:13:48.691 3: HM485d: Tx: (27:1) I[3](0,F,B)(1E) 00000004 -> 12345678 [3] 68(h) {8682}
2022.08.13 10:13:48.892 4: SERIAL: TX: fd123456781e0000000403688682
2022.08.13 10:13:48.893 3: HM485d: Tx: (27:2) I[3](0,F,B)(1E) 00000004 -> 12345678 [3] 68(h) {8682}
2022.08.13 10:13:49.094 4: SERIAL: TX: fd123456781e0000000403688682
2022.08.13 10:13:49.095 3: HM485d: Tx: (27:3) I[3](0,F,B)(1E) 00000004 -> 12345678 [3] 68(h) {8682}
Beim iodev HM485_LAN steht bei den Internals:
Last_Sent_RAW_CMD 12345678 1E 00000004 68
Hier nochmal Rückmeldung von mir für die, die den Thread über die Suche finden.
Leider kann ich nicht viel beitragen. :-[
Ich hatte angefangen, die nicht funktionierenden Geräte rauszuwerfen und durch HMCCUDEV zu ersetzen. Dann ging aber auch in Homematic also über die CCU nix mehr, was noch nie passiert war. Ein Entfernen der Sicherung für den kompletten Bus hat hier dann aber geholfen und es lief wieder. Und da ich mein HM-LAN Gateway wieder dran hatte, trudelten da nach und nach wieder alle Geräte ein, komplett steuerbar.
Also, alles wieder zurück und es geht wieder alles. :D
Ich hab für mich persönlich mitgenommen, wenn nix mehr geht und man Neustarts macht, dann den Bus nicht vergessen.
Homatrix