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

[blueberry63]

Hallo,

ich komme nochmal auf mein Thema zurück: Was müsste denn auf einem Raspi ohne FHEM gemacht werden, um das UART-Modul per Ethernet nutzen zu können?

Die Geräte-Definition würde dann wohl so aussehen:

Code Auswählen Erweitern


define myHmUART HMUARTLGW <IP-Adresse>:<Port>



Gruß
Blueberry63

[Ralf9]

lässt sich das HM-MOD-RPI-PCB mit einem USB zu TTL Serien Converter auch über usb am cubietruck oder banana-pi verwenden?

Gibt es was, das dagegen spricht, daß das HM-MOD-RPI-PCB auch mit einem USB zu TTL Serien Converter z.B. am Cubietruck funktionieren kann?
Timing oder Laufzeiten?
Kann der FTDI -Chip 115200 Baud?
Ist ein Teil vom Code nur beim Raspi verfügbar bzw lauffähig?

Gruß Ralf

[Otto123]

Hallo Michael,
Ich habe noch folgende Erfahrung Ergänzung:
Ich muss zusätzlich noch

Code Auswählen Erweitern

sudo systemctl mask serial-getty@ttyAMA0.service


Ich antworte mir mal selbst, vielleicht stimmt es auch nicht, oder es braucht auch keiner, aber das ist meine Erkenntnis:

Die Sache mit den Rechten auf /dev/ttyAMA0
Der Start des Dienstes serial-getty@ttyAMA0.service setzt die Rechte auf.

Code Auswählen Erweitern

crw--w---- 1 root tty 204, 64 Jul 15 20:36 /dev/ttyAMA0
Ein Beenden des Dienstes ändert daran nichts. Wird der Dienst nicht gestartet stehend die Rechte auf

Code Auswählen Erweitern

crw-rw---- 1 root dialout 204, 64 Jul 18 09:51 /dev/ttyAMA0

Die Sache mit dem Dienst serial-getty@ttyAMA0.service
Der Befehl

Code Auswählen Erweitern

systemctl disable serial-getty@ttyAMA0.service verhindert zwar den automatischen Start aber nicht den manuellen Start bzw. den Start durch andere Prozesse.
Der Eintrag console=serial0,115200 in der /boot/cmdline.txt ist offenbar dafür verantwortlich, dass der Dienst trotz disable gestartet wird. Löscht man diesen Eintrag, wird der Dienst auch nicht gestartet.
Unterm Strich kann man den Start des Dienstes auf zwei Arten verhindern:

Code Auswählen Erweitern

sed s/'\bconsole=serial0,115200 //' /boot/cmdline.txt
oder
systemctl mask serial-getty@ttyAMA0.service
Ich würde das Maskieren bevorzugen um den Dienst generell auszuschließen. Oder beides tun...

Gruß Otto

[Otto123]

Gibt es was, das dagegen spricht, daß das HM-MOD-RPI-PCB auch mit einem USB zu TTL Serien Converter z.B. am Cubietruck funktionieren kann?
Timing oder Laufzeiten?
Kann der FTDI -Chip 115200 Baud?
Ist ein Teil vom Code nur beim Raspi verfügbar bzw lauffähig?

Gruß Ralf

Versuch macht klug 
Der FTDI Chip kann sogar mehr glaube ich, sollte kein Problem sein.
Ansonsten wird mit einer seriellen Schnittstelle gesprochen, was sollte da Pi spezifisch sein?
Ansonsten nimm das LAN Gateway? Ok das ist teuerer ...

Gruß Otto

[gloob]

Kann man das Modul eigentlich generell auf seine Funktion testen?
Aktuell bekomme ich nur folgende Rückmeldungen

Code Auswählen Erweitern

2016.07.19 20:16:36 1: HMUARTLGW myHmUART did not respond, reopening
2016.07.19 20:16:36 1: HMUARTLGW myHmUART Reopen
2016.07.19 20:16:36 3: Setting myHmUART serial parameters to 115200,8,N,1
2016.07.19 20:16:36 1: /dev/ttyAMA0 reappeared (myHmUART)
2016.07.19 20:16:47 1: HMUARTLGW myHmUART did not respond, reopening
2016.07.19 20:16:47 1: HMUARTLGW myHmUART Reopen
2016.07.19 20:16:47 3: Setting myHmUART serial parameters to 115200,8,N,1
2016.07.19 20:16:47 1: /dev/ttyAMA0 reappeared (myHmUART)
2016.07.19 20:16:58 1: HMUARTLGW myHmUART did not respond, reopening
2016.07.19 20:16:58 1: HMUARTLGW myHmUART Reopen
2016.07.19 20:16:58 3: Setting myHmUART serial parameters to 115200,8,N,1
2016.07.19 20:16:58 1: /dev/ttyAMA0 reappeared (myHmUART)
2016.07.19 20:17:09 1: HMUARTLGW myHmUART did not respond, reopening
2016.07.19 20:17:09 1: HMUARTLGW myHmUART Reopen
2016.07.19 20:17:09 3: Setting myHmUART serial parameters to 115200,8,N,1
2016.07.19 20:17:09 1: /dev/ttyAMA0 reappeared (myHmUART)
2016.07.19 20:17:20 1: HMUARTLGW myHmUART did not respond, reopening
2016.07.19 20:17:20 1: HMUARTLGW myHmUART Reopen
2016.07.19 20:17:20 3: Setting myHmUART serial parameters to 115200,8,N,1
2016.07.19 20:17:20 1: /dev/ttyAMA0 reappeared (myHmUART)
2016.07.19 20:17:31 1: HMUARTLGW myHmUART did not respond, reopening
2016.07.19 20:17:31 1: HMUARTLGW myHmUART Reopen
2016.07.19 20:17:31 3: Setting myHmUART serial parameters to 115200,8,N,1
2016.07.19 20:17:31 1: /dev/ttyAMA0 reappeared (myHmUART)


Edit: Nachdem ich jetzt den kompletten Pi vom Strom getrennt habe und neu gestartet habe, funktioniert es ohne Probleme. Ein reiner Neustart per

Code Auswählen Erweitern

sudo reboot now
hat nicht gereicht.

Jetzt sieht es so aus:

Code Auswählen Erweitern

Internals:
   AssignedPeerCnt 0
   CNT        18
   DEF        /dev/ttyAMA0
   DEVCNT     9
   DevState   99
   DevType    UART
   DeviceName /dev/ttyAMA0@115200
   FD         12
   NAME       myHmUART
   NR         85
   PARTIAL
   RAWMSG     0500003E0FA0021C981124B05C04E0380000380E02
   RSSI       -62
   STATE      opened
   TYPE       HMUARTLGW
   XmitOpen   1
   msgLoadCurrent 0
   msgLoadCurrentRaw 0
   msgLoadHistory -/-/-/-/-/-/-/-/-/-/-/-
   msgLoadHistoryAbs 0/-/-/-/-/-/-/-/-/-/-/-/-
   owner      424242
   Helper:
     CreditTimer 2
     FW         66561
     Initialized 1
     Ackpending:
     Assignedpeers:
     LastSendLen:
       3
       3
     Roundtrip:
       Delay      0.00415420532226562
     Loadlvl:
       lastHistory 1468960225.22782
     log:
   Peers:
   Readings:
     2016-07-19 20:30:25   D-HMIdAssigned  424242
     2016-07-19 20:30:25   D-HMIdOriginal  45FA72
     2016-07-19 20:30:25   D-firmware      1.4.1
     2016-07-19 20:30:25   D-serialNr      MEQ1889490
     2016-07-19 20:30:22   D-type          HM-MOD-UART
     2016-07-19 20:30:25   cond            ok
     2016-07-19 20:30:25   load            0
     2016-07-19 20:30:25   loadLvl         low
     2016-07-19 20:30:22   state           opened
Attributes:
   hmId       424242
   room       Homematic
   verbose    5

[mgernoth]

Hallo,

ich komme nochmal auf mein Thema zurück: Was müsste denn auf einem Raspi ohne FHEM gemacht werden, um das UART-Modul per Ethernet nutzen zu können?

Es gibt im Homematic-Forum ein Programm, welches mit dem Modul ein LGW emuliert: http://homematic-forum.de/forum/viewtopic.php?f=18&t=27705
Damit könnte es funktionieren, habe ich nicht getestet.

Ich wollte sowas auch nochmal bauen, dazu bin ich aber noch nicht gekommen.

Edit: Nachdem ich jetzt den kompletten Pi vom Strom getrennt habe und neu gestartet habe, funktioniert es ohne Probleme. Ein reiner Neustart per

Code Auswählen Erweitern

sudo reboot now
hat nicht gereicht.

Hmm, wahrscheinlich ist das Modul durch die seriellen Ausgaben der Standardinstallation komplett abgestürzt und musste hart neugestartet werden. Es hat auf keine Befehle von Fhem reagiert.
Wahrscheinlich hätte auch ein manueller Reset über die GPIOs gereicht:

Code Auswählen Erweitern


echo 18 | sudo tee /sys/class/gpio/export
echo out | sudo tee /sys/class/gpio/gpio18/direction
echo 0 | sudo tee /sys/class/gpio/gpio18/value
sleep 0.2
echo 1 | sudo tee /sys/class/gpio/gpio18/value


Viele Grüße
  Michael

[Otto123]

Hallo,

vorneweg mein Dankeschön an Michael für seine Arbeit!

Ich habe mal angefangen im Wiki die Installation zu ergänzen. Da fehlt sicher noch einiges ...
Auf meinem Blog habe ich das Thema noch etwas umfassender aufgeschrieben, bzw schreibe noch.
Ich bitte um Hinweise und Kritik 

Gruß Otto

[MadMax-FHEM]

Hi,

so jetzt hab ich endlich mal etwas Zeit...

Habe mittlerweile auf den neuesten Stand geupdated, also nix mehr manuell patchen...
...vielen Dank dafür an alle!

So jetzt wieder zurück zu meinem Problemkind: E-Paper-Display.

Also ich habe einen HM-Klingelsensor, der mit meinem Testsystem mit einem nanoCUL Probleme macht: NACK. Und Pair_Cetral bleibt bei set_XXXXX stehen.

Dort habe ich mit dem mittlerweile alle möglichen Dinge probiert, also spezielle perl Module und FWs für den nanoCUL bzgl. Timing etc.
Nix geholfen...

Dann mal probehalber mit meinem neuen Testsystem (PI3 mit HM-UART) gepairt: kein Problem, kein NACK, nix, alles super...

So dann das E-Paper-Display mit meinem nanoCUL Testsystem gepairt (dieses mittlerweile wieder auf Original-FW und perl Module).
Alles gut, keine Probleme.

Dann mal versucht mit meinem Testsystem mit HM-UART gepairt (ja vorher reset etc.).
Und jetzt kriege ich damit immer: RESPONSE TIMEOUT:RegisterRead

Habe es schon (mit verschiedenen Ständen) mehrfach versucht.
Gelöscht/Reset und gepaired...
...immer das selbe.

Setzen von Text etc. geht. Aber trotzdem bei getConfig wieder: RESPONSE TIMEOUT:RegisterRead

Dann wird immer wieder ein getConfig vom System (fhem) angestoßen...
...und immer wieder: RESPONSE TIMEOUT:RegisterRead

Hier mal ein list des E-Paper-Displays:

Code Auswählen Erweitern


Internals:
   CFGFN
   DEF        4BD2DA
   HM_UART_MSGCNT 108
   HM_UART_RAWMSG 050100292AA0104BD2DAAFFE220100000000
   HM_UART_RSSI -41
   HM_UART_TIME 2016-07-20 22:10:52
   IODev      HM_UART
   LASTInputDev HM_UART
   MSGCNT     108
   NAME       HM_4BD2DA
   NR         32
   STATE      RESPONSE TIMEOUT:RegisterRead
   TYPE       CUL_HM
   channel_01 HM_4BD2DA_Dis_01
   channel_02 HM_4BD2DA_Dis_02
   channel_03 HM_4BD2DA_Key_01
   channel_04 HM_4BD2DA_Key_02
   channel_05 HM_4BD2DA_Key_03
   channel_06 HM_4BD2DA_Key_04
   channel_07 HM_4BD2DA_Key_05
   channel_08 HM_4BD2DA_Key_06
   channel_09 HM_4BD2DA_Key_07
   lastMsg    No:2A - t:10 s:4BD2DA d:AFFE22 0100000000
   protCmdDel 92
   protLastRcv 2016-07-20 22:10:52
   protResnd  6 last_at:2016-07-20 22:11:00
   protResndFail 6 last_at:2016-07-20 22:11:05
   protSnd    146 last_at:2016-07-20 22:10:55
   protState  CMDs_done_Errors:1
   rssi_at_HM_UART avg:-41.51 max:-41 lst:-41 cnt:108 min:-51
   Readings:
     2016-07-20 22:06:10   CommandAccepted yes
     2016-07-20 22:06:09   D-firmware      1.0
     2016-07-20 22:06:09   D-serialNr      NEQ0711293
     2016-07-20 22:06:14   PairedTo        0xAFFE22
     2016-07-20 22:06:14   R-pairCentral   0xAFFE22
     2016-07-20 22:06:14   R-powerSupply   bat
     2016-07-20 22:06:14   RegL_00.          02:01 05:00 08:01 0A:AF 0B:FE 0C:22 14:03 21:03  00:00
     2016-07-20 22:11:05   state           RESPONSE TIMEOUT:RegisterRead
   Helper:
     HM_CMDNR   43
     cSnd       01AFFE224BD2DA0803,01AFFE224BD2DA09040000000001
     mId        00FB
     rxType     6
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +4BD2DA,00,00,00
       nextSend   1469045170.91038
       prefIO
       rxt        0
       vccu
       p:
         4BD2DA
         00
         00
         00
     Mrssi:
       mNo        2A
       Io:
         HM_UART    -39
     Prt:
       bErr       0
       sProc      0
     Q:
       qReqConf
       qReqStat
     Role:
       dev        1
     Rpt:
       IO         HM_UART
       flg        A
       ts         1469045452.83523
       ack:
         HASH(0x28cad00)
         2A8002AFFE224BD2DA00
     Rssi:
       At_hm_uart:
         avg        -41.5185185185185
         cnt        108
         lst        -41
         max        -41
         min        -51
     Shadowreg:
     Tmpl:
Attributes:
   IODev      HM_UART
   IOgrp      vccu:HM_UART
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   model      HM-Dis-EP-WM55
   msgRepeat  1
   room       CUL_HM
   serialNr   NEQ0711293
   subType    pushButton
   webCmd     getConfig:clear msgEvents


und ein list des HM-UART:

Code Auswählen Erweitern


Internals:
   AssignedPeerCnt 1
   CHANGED
   CNT        141
   DEF        /dev/ttyAMA0
   DEVCNT     44
   DevState   99
   DevType    UART
   DeviceName /dev/ttyAMA0@115200
   FD         7
   NAME       HM_UART
   NR         18
   PARTIAL
   RAWMSG     0500004B19847031D958000000010738
   RSSI       -75
   STATE      opened
   TYPE       HMUARTLGW
   XmitOpen   1
   msgLoadCurrent 38
   msgLoadCurrentRaw 75
   msgLoadHistory 1/-/-/-/-/-/-/-/-/-/-/-
   msgLoadHistoryAbs 47/46/-/-/-/-/-/-/-/-/-/-/-
   owner      AFFE22
   owner_CCU  vccu
   Helper:
     CreditTimer 32
     FW         66561
     Initialized 1
     SendCnt    48
     Ackpending:
     Assignedpeers:
       4BD2DA     FFFFFFFFFFFFFFFF (flags: 0)
     LastSendLen:
       3
       3
     PeerQueue:
     PendingCMD:
     Roundtrip:
       Delay      0.00328278541564941
     Loadlvl:
       lastHistory 1469045325.31342
     log:
   Peers:
     4BD2DA     assigned
   Readings:
     2016-07-20 22:03:45   D-HMIdAssigned  AFFE22
     2016-07-20 22:03:45   D-HMIdOriginal  4708A9
     2016-07-20 22:03:45   D-firmware      1.4.1
     2016-07-20 22:03:45   D-serialNr      NEQ0229905
     2016-07-20 22:03:43   D-type          HM-MOD-UART
     2016-07-20 22:03:45   cond            ok
     2016-07-20 22:11:08   load            38
     2016-07-20 22:10:06   loadLvl         low
     2016-07-20 22:03:43   state           opened
   Helper:
Attributes:
   hmId       AFFE22
   qLen       60
   verbose    5


Angehängt auch das Log mit verbose 5 beim HM_UART, weil zu lang für hier...

Wäre schön, wenn sich das lösen ließe, da ich ja (demnächst) auf das HM-UART System umsteigen will...
...aber halt erst, wenn es ohne Probleme arbeitet...

Vielen Dank schon mal!!

Viele Grüße, Joachim

[Ralf9]

Versuch macht klug 
Der FTDI Chip kann sogar mehr glaube ich, sollte kein Problem sein.
Ansonsten wird mit einer seriellen Schnittstelle gesprochen, was sollte da Pi spezifisch sein?

Ok, dann gibt es nichts das dagegenspricht, daß das HM-MOD-RPI-PCB auch über USB funktioniert.
Mich wundert, daß es bis jetzt noch niemand versucht hat.

Beim Montagevideo ist mir aufgefallen, daß die Zuleitung der Versorgungsspannung viermal durch den Ferritring geführt werden muß.
Weiß zufällig jemand welchen Grund dies hat?
Wenn ich das HM-MOD-RPI-PCB über USB betreiben möchte, muss ich dann das USB Kabel viermal durch den Ferritring führen?

Gruß Ralf

[Otto123]

Da der raspberry PI beim Anschluss von externen Komponenten dazu neigt , Störstrahlung über die Zuleitung auszusenden, muss ...

Aus der Aufbauanleitung.

Die meisten sind froh, dass das Modul jetzt unter FHEM läuft. Remote Anbindung und andere Experimente starten jetzt sicher schon überall 

Gruß Otto

[betateilchen]

Ok, dann gibt es nichts das dagegenspricht, daß das HM-MOD-RPI-PCB auch über USB funktioniert.
Mich wundert, daß es bis jetzt noch niemand versucht hat.

Das Modul benötigt auch noch eine Spannungsversorgung, nicht nur eine serielle Schnittstelle...

[Ralf9]

Das Modul benötigt auch noch eine Spannungsversorgung, nicht nur eine serielle Schnittstelle...

Sind die 5V und 3,3V vom FTDI USB zu TTL seriell Converter nicht ausreichend?

http://www.ebay.de/itm/FT232RL-FTDI-USB-zu-TTL-Serien-Converter-Adapter-Modul-5V-3-3V-Fur-Arduino-TE203-/281909029942?hash=item41a3166c36:g:QOoAAOSwepJXVRoG

Gruß Ralf

[MadMax-FHEM]

Hallo,

HM-Bezeichnung:   HM-MOD-RPI-PCB
Versorgungsspannung:   1,8–3,6 V DC
Stromaufnahme:   50 mA max.
Funkfrequenz:   868,3 MHz/869,525 MHz
Empfängerkategorie:   SRD Category 2
Funkreichweite:   Bis zu 100 m (Freifeld)
Duty Cycle:   < 1 % pro h/< 10 % pro h
Umgebungstemperaturbereich:   -10 bis +55 °C
Abmessungen (B x H x T):   19 x 41 x 14 mm
Gewicht:   6 g

Bei Anschluss an 3,3V sollte es passen.
Die 50mA sollte USB ja locker schaffen.

Selbst einen ESP kann man mal dran tun und der braucht deutlich mehr...

Gruß, Joachim

[Ralf9]

Bei Anschluss an 3,3V sollte es passen.
Die 50mA sollte USB ja locker schaffen.

Dies gilt aber nur für die 5V.
Ich habe mal im Datenblatt des FT232RL geschaut. Bei 3,3V gehen 50mA gerade noch.

3.3V output from integrated L.D.O. regulator. This pin should be decoupled to ground using a 100nF capacitor.
The prime purpose of this pin is to provide the internal 3.3V supply to the USB transceiver cell and the internal
1.5kΩ pull up resistor on USBDP. Up to 50mA can be drawn from this pin to power external logic if required.
This pin can also be used to supply the FT232R's VCCIO pin

Gruß Ralf

[MadMax-FHEM]

Hi Ralf,

dann hatte ich Glück mit meinen FTDI USB

Wobei es nat. schon wegen dem USB-Anschluss an sich nicht ratsam ist einen ESP zu betreiben...
...aber für einen schnellen Test

Gruß, Joachim