HMUARTLGW: Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway

[blueberry63]

Hallo,

ich habe den Thread eben mal schnell überflogen, aber trotzdem ist mir folgendes nicht klar bzw. könnte mir jemand die Fragen bestätigen?

1. Das HM-MOD-RPI-PCB besteht doch aus Sende- und Empfangsteil, richtig?
2. Welche Software (Linux ist klar) läuft auf dem Raspi, um die HW anzusprechen und woher kommt sie?
3. Kann ich FHEM auch auf einem anderen Gerät laufen lassen oder muss FHEM zwingend auf den rspi?

Danke und Gruß
Blueberry63

[Ralli]

1. ja
2. fhem mit dem neuen Modul und CUL_HM
3. noch nicht - ja; FHEM2FHEM könnte gehen. Müsste getestet werden.

[PeterS]

Hallo mgernoth
Ist das Modul für den FHEM Repository vorgesehen?

Gruss Peter

[mgernoth]

Hallo,

Ist das Modul für den FHEM Repository vorgesehen?

Ja, wenn Martin den Patch in 10_CUL_HM.pm eingepflegt hat, werde ich das Modul ins SVN einpflegen.

Viele Grüße
  Michael

[Weissbrotgrill]

Hallo,

mit freuden lese ich diesen Artikel. Eigentlich wollte ich mir einen zweiten HM-CFG-USB holen, aber der ist ja leider nirgends mehr zu finden.
Da mein FHEM auf einem Raspberry Pi läuft kommt dieses Modul also im richtigen Moment. Na dann werde ich wohl ein Modul bestellen. Im letzten ELV Newsletter war doch schon wieder ein Bonusgutschein drin, na dann ...

Zu folgender Frage:

...
3. Kann ich FHEM auch auf einem anderen Gerät laufen lassen oder muss FHEM zwingend auf den rspi?
...

Bisher lese ich hier immer nur das das Modul via /dev/ttyAMA0 angesprochen wird. Das ist eine serielle Schnittstelle. Daher frage ich mich welche PINs des Pi das Aufsteckmodul verwendet. Vermutlich GND, +3,3V, RX und TX. Wenn dem so ist müsste es doch möglich sein das Aufsteckmodul mittels USB/Seriel Adapter wie z.B. den weit verbreitetend FTDI FT232... Adaptern oder einem weniger edlen Adapter mit CP2102 Chip an jedem beliebiegen USB Port eines jeden PCs zu nutzen. Also unabhängig vom Raspberry Pi. Es sollte nur vorher der TTL Pegel geklärt werden. Da das Modul für den Raspberry Pi ist werden es wohl 3,3 V sein.

Gruß
Christian

[gloob]

Besteht eigentlich die Möglichkeit das Modul an einen ESP mit Serial Interface zu koppeln so wie es bei manchen CULs bereits gemacht wird?


Gesendet von iPhone mit Tapatalk

[Ralli]

Wenn ich richtig informiert bin, möchte Michael noch den hmland erweitern oder einen eigenen Dämon dafür erstellen.

[gloob]

Die Variante mit dem ESP wäre halt deutlich kleiner und billiger als ein Raspberry Pi. Deswegen bin ich auf die Idee gekommen. Werde mir jetzt aber einfach mal ein Modul bestellen und das ganze testen.


Gesendet von iPhone mit Tapatalk

[Rampler]

Hallo Michael,
nach Restart Raspberry:

Code Auswählen Erweitern

2016.07.11 20:54:41 3: NTFY return:  AZ.iam:-110
2016.07.11 20:54:41 0: Featurelevel: 5.7
2016.07.11 20:54:41 0: Server started with 314 defined entities (fhem.pl:11611/2016-06-04 perl:5.014002 os:linux user:fhem pid:1878)
2016.07.11 20:54:41 1: Perfmon: possible freeze starting at 20:54:15, delay is 26.289
2016.07.11 20:54:41 0: HMUARTLGW HMUART send: 00 00
2016.07.11 20:54:41 1: HMUARTLGW HMUART frame with wrong length received: 23, should: 4: FD00001201E6050001384586702BBFE800000000EA3AF613
2016.07.11 20:54:41 0: HMUARTLGW HMUART recv: 00 0402436F5F4350555F417070, state 1
2016.07.11 20:54:41 3: HMUARTLGW HMUART currently running Co_CPU_App
2016.07.11 20:54:41 1: HMLAN_Parse: HMLAN1 new condition ok
2016.07.11 20:54:41 1: HMLAN_Parse: HMLAN2 new condition ok
2016.07.11 20:54:42 0: HMUARTLGW HMUART send: 01 0029A083
2016.07.11 20:54:42 0: HMUARTLGW HMUART recv: 01 0401, state 4
2016.07.11 20:54:42 0: HMUARTLGW HMUART GetSet Ack: 01, state 4

Restart FHEM,ohne Meldung ...

bis die Tage
   Klaus

[MadMax-FHEM]

Hallo,

ähnliches bei mir:

Code Auswählen Erweitern


2016.07.11 21:48:33 0: Server shutdown
2016.07.11 21:48:37 1: Including fhem.cfg
2016.07.11 21:48:38 3: WEB: port 8083 opened
2016.07.11 21:48:38 2: eventTypes: loaded 214 events from ./log/eventTypes.txt
2016.07.11 21:48:38 3: Opening HM_UART device /dev/ttyAMA0
2016.07.11 21:48:38 3: Setting HM_UART serial parameters to 115200,8,N,1
2016.07.11 21:48:38 3: HM_UART device opened
2016.07.11 21:48:39 1: Including ./log/fhem.save
2016.07.11 21:48:39 2: SecurityCheck:  WEB has no associated allowed device with basicAuth.  Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2016.07.11 21:48:39 0: Featurelevel: 5.7
2016.07.11 21:48:39 0: Server started with 21 defined entities (fhem.pl:11756/2016-07-07 perl:5.020002 os:linux user:fhem pid:572)
2016.07.11 21:48:39 1: HMUARTLGW HM_UART frame with wrong length received: 8, should: 4: FD00000E0001040243
2016.07.11 21:48:39 1: HMUARTLGW HM_UART frame with wrong length received: 16, should: 4: FD00000E00010402436F5F4350555F4170
2016.07.11 21:48:39 1: HMUARTLGW HM_UART frame with wrong length received: 19, should: 4: FD00000E00010402436F5F4350555F417070F014
2016.07.11 21:48:43 3: CUL_HM set HM_4BD2DA_Dis_01 getConfig
2016.07.11 21:48:48 1: HMUARTLGW HM_UART frame with wrong length received: 19, should: 4: FD00000E00010402436F5F4350555F417070F014
2016.07.11 21:48:49 1: HMUARTLGW HM_UART did not respond, reopening
2016.07.11 21:48:49 1: HMUARTLGW HM_UART Reopen
2016.07.11 21:48:49 3: Setting HM_UART serial parameters to 115200,8,N,1
2016.07.11 21:48:49 1: /dev/ttyAMA0 reappeared (HM_UART)
2016.07.11 21:48:58 3: HMUARTLGW HM_UART currently running Co_CPU_App


Habe fhem update gemacht und noch mal neu geholt und gepatched (muss man ja noch!?).

Obiges im Log nach reboot...

Bislang ohne Probleme, sogar mit dem Klingelsensor, der an meinem anderen Testsystem mit nanoCUL Probleme macht: NACK und Timeout_RegisterRead...

Hier problemlos...

Dafür ist es mit dem neuen e-paper Display andersrum
Aber da ist wohl noch was mit dem e-paper Display...

Wobei nach dem reboot wohl ein getConfig läuft und dann alles gut ist...
...bis auf obige Meldungen.

Weil ich grad dabei bin:

ich habe eine vccu wo der HM_UART als IODev eingetragen ist.
Dieser zeigt dort allerdings "disconnected".
Der HM_UART selbst ist opened und funktioniert auch...

Hier list der vccu:

Code Auswählen Erweitern


Internals:
   DEF        AFFE22
   HM_UART_MSGCNT 82
   HM_UART_RAWMSG 05000036A1865A32185B000000A50E3A
   HM_UART_RSSI -54
   HM_UART_TIME 2016-07-11 21:57:39
   IODev      HM_UART
   LASTInputDev HM_UART
   MSGCNT     82
   NAME       vccu
   NR         18
   NTFY_ORDER 50-vccu
   STATE      HM_UART:disconnected,
   TYPE       CUL_HM
   assignedIOs HM_UART
   Readings:
     2016-07-11 21:57:39   unknown_32185B  received
     2016-07-11 21:57:34   unknown_3227F4  received
   Helper:
     HM_CMDNR   1
     mId        FFF0
     rxType     1
     Expert:
       def        1
       det        1
       raw        0
       tpl        0
     Io:
       vccu       vccu
       ioList:
         HM_UART
     Mrssi:
       mNo
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
       vrt        1
     Tmpl:
Attributes:
   IODev      HM_UART
   IOList     HM_UART
   IOgrp      vccu
   expert     1_allReg
   model      CCU-FHEM
   subType    virtual
   webCmd     virtual:update


und ein list des HM_UART:

Code Auswählen Erweitern


Internals:
   AssignedPeerCnt 2
   CHANGED
   CNT        62
   DEF        /dev/ttyAMA0
   DEVCNT     62
   DevState   99
   DevType    UART
   DeviceName /dev/ttyAMA0@115200
   FD         8
   NAME       HM_UART
   NR         17
   PARTIAL
   RAWMSG     04026F
   RSSI       -63
   STATE      opened
   TYPE       HMUARTLGW
   XmitOpen   1
   msgLoadCurrent 56
   msgLoadCurrentRaw 111
   msgLoadHistory 1/-/-/-/-/-/-/-/-/-/-/-
   msgLoadHistoryAbs 56/55/-/-/-/-/-/-/-/-/-/-/-
   owner      AFFE22
   owner_CCU  vccu
   Helper:
     CreditTimer 39
     FW         66561
     Initialized 1
     SendCnt    2
     Ackpending:
     Assignedpeers:
       398B7D     FFFFFFFFFFFFFFFF (flags: 0)
       4BD2DA     FFFFFFFFFFFFFFFF (flags: 0)
     LastSendLen:
       3
       3
     PeerQueue:
     PendingCMD:
     Loadlvl:
       lastHistory 1468266839.32718
     log:
   Peers:
     398B7D     assigned
     4BD2DA     assigned
   Readings:
     2016-07-11 21:48:59   D-HMIdAssigned  AFFE22
     2016-07-11 21:48:59   D-HMIdOriginal  4708A9
     2016-07-11 21:48:59   D-firmware      1.4.1
     2016-07-11 21:48:59   D-serialNr      NEQ0229905
     2016-07-11 21:48:38   D-type          HM-MOD-UART
     2016-07-11 21:48:59   cond            ok
     2016-07-11 21:49:00   load            56
     2016-07-11 21:48:59   loadLvl         batchLevel
     2016-07-11 21:48:49   state           opened
   Helper:
Attributes:
   hmId       AFFE22
   qLen       60


Danke schon mal, Joachim

[gompf]

Wenn dem so ist müsste es doch möglich sein das Aufsteckmodul mittels USB/Seriel Adapter wie z.B. den weit verbreitetend FTDI FT232... Adaptern oder einem weniger edlen Adapter mit CP2102 Chip an jedem beliebiegen USB Port eines jeden PCs zu nutzen. Also unabhängig vom Raspberry Pi. Es sollte nur vorher der TTL Pegel geklärt werden. Da das Modul für den Raspberry Pi ist werden es wohl 3,3 V sein.

Moin,

Ja. Sollte kein Thema sein. Pegel sind 3,3V. Ebenso sollte Anbindung über ESP als serial bridge klappen, falls FHEM schon woanders läuft. Die I2C-Pins sind frei, hatte RTC ergänzt.

BTW. Danke, läuft beir mir stabiler als CUL mir FW1.66. HM-MOD-RE8 war sonst Problemkinder, jetzt alles stabil.

Gruß,
Michael

[Jorge3711]

Probleme mit 3 Rollladenaktoren HM-LC-Bl1PBU-FM, hier ein exemplarischer List eines der Aktoren:

Code Auswählen Erweitern


Internals:
   DEF        30D102
   IODev      HMLAN1
   LASTInputDev myHmUART
   MSGCNT     12
   NAME       kueche_rollladen_links
   NR         58
   NTFY_ORDER 50-kueche_rollladen_links
   STATE      MISSING ACK
   TYPE       CUL_HM
   myHmUART_MSGCNT 12
   myHmUART_RAWMSG 0500003B02A011F1000030D1020201C80000
   myHmUART_RSSI -59
   myHmUART_TIME 2016-07-12 13:54:35
   peerList   kueche_remote_6fach_Btn_05,
   protCmdDel 1
   protErrIoId_F10000 12 last_at:2016-07-12 13:54:35
   protResnd  3 last_at:2016-07-12 13:54:34
   protResndFail 1 last_at:2016-07-12 13:54:39
   protSnd    1 last_at:2016-07-12 13:54:22
   protState  CMDs_done_Errors:1
   Readings:
     2016-07-12 13:50:54   CommandAccepted yes
     2016-04-27 19:42:46   D-firmware      2.8
     2016-04-27 19:42:46   D-serialNr      LEQ1028241
     2016-07-12 13:28:43   PairedTo        0x54D789
     2016-04-30 09:30:53   R-driveDown     16 s
     2016-04-30 09:30:53   R-driveTurn     0.5 s
     2016-04-30 09:30:53   R-driveUp       17 s
     2016-04-30 09:30:55   R-kueche_remote_6fach_Btn_05-lgActionType jmpToTarget
     2016-04-30 09:30:55   R-kueche_remote_6fach_Btn_05-lgOnLevel 100 %
     2016-04-30 09:30:55   R-kueche_remote_6fach_Btn_05-shActionType jmpToTarget
     2016-04-30 09:30:55   R-kueche_remote_6fach_Btn_05-shOnLevel 100 %
     2016-04-30 09:30:52   R-pairCentral   0x54D789
     2016-04-30 09:30:53   R-sign          off
     2016-07-12 13:52:17   RegL_00.
     2016-07-12 13:50:54   deviceMsg       on (to vccu)
     2016-07-12 13:50:54   level           100
     2016-07-12 13:50:54   motor           stop:on
     2016-07-12 13:50:54   pct             100
     2016-07-12 13:53:26   peerList        kueche_remote_6fach_Btn_05,
     2016-07-12 13:50:54   recentStateType ack
     2016-07-12 13:50:54   rssi_HMLAN1     -72
     2016-07-12 13:50:54   rssi_at_HMLAN1  -68
     2016-07-12 13:50:54   rssi_at_myHmUART -54
     2016-06-20 08:04:06   rssi_kueche_remote_6fach -68
     2016-07-12 13:32:52   rssi_myHmUART   -63
     2016-07-12 13:54:35   sabotageAttackId_ErrIoId_F10000  cnt:12
     2016-07-12 13:54:39   state           MISSING ACK
     2016-07-12 13:50:54   timedOn         off
     2016-06-20 08:04:06   trigLast        kueche_remote_6fach_Btn_05:long
     2016-06-20 08:04:06   trig_kueche_remote_6fach_Btn_05 long
   Helper:
     HM_CMDNR   2
     cSnd       ,11F1000030D1020201C80000
     dlvl       C8
     dlvlCmd    ++A011F1000030D1020201C80000
     mId        006A
     rxType     1
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +30D102,00,00,00
       rxt        0
       vccu       vccu
       p:
         30D102
         00
         00
         00
     Mrssi:
       mNo
       Io:
     Prt:
       bErr       0
       sProc      0
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
       prs        1
     Tmpl:
Attributes:
   IODev      vccu
   IOgrp      vccu
   alias      Küchenfenster links
   autoReadReg 0_off
   devStateIcon on:fts_shutter_10 9[0-9].?5?:fts_shutter_10 8[0-9].?5?:fts_shutter_20 7[0-9].?5?:fts_shutter_30 6[0-9].?5?:fts_shutter_40 5[0-9].?5?:fts_shutter_50 4[0-9].?5?:fts_shutter_60 3[0-9].?5?:fts_shutter_70 2[0-9].?5?:fts_shutter_80 1[0-9].?5]?:fts_shutter_90 [1-9].?5?:fts_shutter_100 off:fts_shutter_100 undefined:fts_shutter_60
   expert     2_full
   firmware   2.8
   group      Rollladen
   model      HM-LC-Bl1PBU-FM
   peerIDs    00000000,3667BF05,
   room       Küche
   rssiLog    1
   serialNr   LEQ1028241
   subType    blindActuator
   userattr   room_map structexclude
   webCmd     on:off
   widgetOverride widgetOverride pct:select,off,0,10,20,30,40,50,60,70,80,90,100,on


Direkt nach einem fhem Neustart bekomme ich von den 3 Aktoren bei einem beliebigen Befehl einen MISSING ACK gemeldet. Nach einer gewissen Wartezeit ohne weiteres zutun sind die Aktoren aber ansprechbar und ein Fahrbefehl wird umgesetzt. Im Anhang ein log mit komplett gesnifften FHEM Startvorgang mit anschließendem Schaltversuch (später ist da auch der erfolgreiche Schaltvorgang zu sehen).

Fhem vorhin aktualisiert, Deine 00_HMUART inkl. 10_CUL_HM Patch.

Aufgefallen ist es mir, weil nach einem Neustart die Rolläden nicht mit den anderen am Abend heruntergefahren sind (DOIF).

[mgernoth]

Hallo,

nach Restart Raspberry:

Code Auswählen Erweitern


2016.07.11 20:54:41 1: HMUARTLGW HMUART frame with wrong length received: 23, should: 4: FD00001201E6050001384586702BBFE800000000EA3AF613


ähnliches bei mir:

Code Auswählen Erweitern


2016.07.11 21:48:39 1: HMUARTLGW HM_UART frame with wrong length received: 8, should: 4: FD00000E0001040243


Ja, das ist ein Firmwarebug des HMUART, der nach einem Neustart die Längenbytes bei den ersten Nachrichten auf 0 lässt. Da kann ich nichts machen, da müsste eQ-3 die Firmware fixen. Nach einem Restart des Moduls ist diese Nachricht also "normal", im laufenden Betrieb darf sie aber nicht mehr auftreten.

ich habe eine vccu wo der HM_UART als IODev eingetragen ist.
Dieser zeigt dort allerdings "disconnected".
Der HM_UART selbst ist opened und funktioniert auch...

Das habe ich behoben, danke.

Probleme mit 3 Rollladenaktoren HM-LC-Bl1PBU-FM, hier ein exemplarischer List eines der Aktoren:

...

Direkt nach einem fhem Neustart bekomme ich von den 3 Aktoren bei einem beliebigen Befehl einen MISSING ACK gemeldet. Nach einer gewissen Wartezeit ohne weiteres zutun sind die Aktoren aber ansprechbar und ein Fahrbefehl wird umgesetzt.

Ja, laut Log kommen die Befehle am Anfang gar nicht beim HMUARTLGW an. Poste bitte auch mal ein List Deiner VCCU und probiere evtl. ein preferred-IO in der IOGrp der Rolladenaktoren zu setzen (wobei ich das hier auch mit nicht-gesetztem preferred IO nicht nachvollziehen kann).
Es sieht irgendwie so aus, als würde die VCCU die Kommandos an ein anderes IO senden wollen?!

Viele Grüße
  Michael

[Jorge3711]

Ja, laut Log kommen die Befehle am Anfang gar nicht beim HMUARTLGW an. Poste bitte auch mal ein List Deiner VCCU und probiere evtl. ein preferred-IO in der IOGrp der Rolladenaktoren zu setzen (wobei ich das hier auch mit nicht-gesetztem preferred IO nicht nachvollziehen kann).
Es sieht irgendwie so aus, als würde die VCCU die Kommandos an ein anderes IO senden wollen?!

Hier das List der VCCU:

Code Auswählen Erweitern


Internals:
   DEF        54D789
   HMLAN1_MSGCNT 18
   HMLAN1_RAWMSG E54D789,0000,2FE37D43,FF,FFBD,05800254D78930D13500
   HMLAN1_RSSI -67
   HMLAN1_TIME 2016-07-12 18:03:59
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     60
   NAME       vccu
   NR         45
   NTFY_ORDER 50-vccu
   STATE      HMLAN1:ok,myHmUART:ok,
   TYPE       CUL_HM
   assignedIOs HMLAN1,myHmUART
   lastMsg    No:05 - t:02 s:54D789 d:30D135 00
   myHmUART_MSGCNT 42
   myHmUART_RAWMSG 0500003F03800254D78930D13500
   myHmUART_RSSI -63
   myHmUART_TIME 2016-07-12 17:08:08
   protLastRcv 2016-07-12 18:03:59
   rssi_at_HMLAN1 avg:-65 min:-69 max:-64 lst:-67 cnt:8
   rssi_at_myHmUART avg:-60.2 min:-63 max:-60 lst:-63 cnt:30
   Readings:
     2016-07-12 18:03:59   CommandAccepted yes
     2016-07-12 10:12:01   recentStateType ack
     2016-07-12 14:58:11   state           HMLAN1:ok,myHmUART:ok,
     2016-06-14 23:31:06   unknown_3DFBFE  received
     2016-06-28 22:19:09   unknown_424242  received
     2016-06-14 17:32:09   unknown_4A3486  received
     2016-06-14 19:15:09   unknown_4C1211  received
     2016-07-12 14:03:32   unknown_F10000  received
   Helper:
     HM_CMDNR   5
     mId        FFF0
     rxType     1
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       nextSend   1468339440.05894
       vccu       vccu
       ioList:
         HMLAN1
         myHmUART
     Mrssi:
       mNo        05
       Io:
         HMLAN1     -65
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
       vrt        1
     Rssi:
       At_hmlan1:
         avg        -65
         cnt        8
         lst        -67
         max        -64
         min        -69
       At_myhmuart:
         avg        -60.2
         cnt        30
         lst        -63
         max        -60
         min        -63
     Tmpl:
Attributes:
   IODev      HMLAN1
   IOList     HMLAN1,myHmUART
   IOgrp      vccu
   expert     2_full
   group      IODevs
   model      CCU-FHEM
   room       Zentrale
   subType    virtual
   webCmd     virtual:update


[mgernoth]

Hi,

irgendwas ist bei Dir ganz merkwürdig

Hier das List der VCCU:

Code Auswählen Erweitern


Internals:
   DEF        54D789
...
   STATE      HMLAN1:ok,myHmUART:ok,


Die VCCU sieht gut aus, mit vernünftiger hmId und zwei zugewiesenen IOs.

Aus Deinem alten Log:

Code Auswählen Erweitern


2016.07.12 13:57:05.978 0: HMUARTLGW myHmUART send: 01 0054D789
...
2016.07.12 13:57:35.069 3: CUL_HM set kueche_rollladen_links on
2016.07.12 13:57:35.110 0: HMUARTLGW myHmUART recv: 01 05 00 00 3C msg: 02 A0 11 F10000 30D102 0201C80000
2016.07.12 13:57:35.307 0: HMUARTLGW myHmUART recv: 01 05 00 00 3C msg: 02 A0 11 F10000 30D102 0201C80000


Die hmId wird im HMUART auf 54D789 gesetzt.
Später sendet CUL_HM den Befehl über ein anderes IO mit der hmId F10000 aus, worauf der Rolladenaktor natürlich nicht reagiert, da er diesen Absender nicht erkennt. Der HMUART empfängt hier nur.

Gibt es in dem System evtl. noch einen CUL, der nicht in der VCCU ist um im HomeMatic-Modus läuft? IIRC bekommen CULs ohne gesetzte hmId F1xxxx zugewiesen.

Viele Grüße
  Michael