[gelöst] HM-MOD-UART-RPI mit USR-TCP232-T2 und CP2102 MICRO USB

Begonnen von tndx, 27 Januar 2018, 20:28:16

Vorheriges Thema - Nächstes Thema

tndx

Guten Abend,

ich versuche seit gestern erfolglos HM-MOD-UART-RPI mit USR-TCP232-T2 und CP2102 MICRO USB auf amunras Platine Version 1.2 ans Laufen zu kriegen. Amunra hatte in seiner Dokumentation USR-TCP232-T2 als grundsätzlich geeignet aber ungetestet erwähnt, aber ich habe eine Bestätigung von einem User aus dem Forum, dass bei ihm HM-MOD-UART-RPI mit USR-TCP232-T2 funktioniert.

Zu meinem Problem:
Ich kann das Ding per USB anschließen, die Coprozessor-Firmware über FHEM oder mit flash-hmmoduart aktualisieren. Das Ding wird auch in FHEM erkannt und als "opened" angezeigt, es kommt keine Kommunikation mit einem Aktor zustande (es kommt erst "set_on" und dann "IOerr"). Nach jedem FHEM-Neustart steht im Logfile
2018.01.27 19:04:31.981 1: HMUARTLGW myHmUARTUSB unexpected info about Co_CPU_BL received (module crashed?), reopening
2018.01.27 19:04:31.999 1: /dev/ttyUSB0 reappeared (myHmUARTUSB)


Ich sehe im Logfile, dass das Ding sowohl den Aktor als auch die Kommunikation meines Haupt-FHEMs mitkriegt.

Hier ein list
Internals:
   AssignedPeerCnt 0
   CNT        18
   Clients    :CUL_HM:
   DEF        /dev/ttyUSB0
   DEVCNT     4
   DevState   99
   DevType    UART
   DeviceName /dev/ttyUSB0@115200
   FD         9
   LastOpen   1517078527.0291
   NAME       myHmUARTUSB
   NR         23
   PARTIAL   
   RAWMSG     0500001A03A410294FB8AEDD0106010000
   RSSI       -26
   STATE      opened
   TYPE       HMUARTLGW
   XmitOpen   1
   model      HM-MOD-UART
   msgLoadCurrent 0
   msgLoadHistory -/-/-/-/-/-/-/-/-/-/-/-
   msgLoadHistoryAbs 0/-/-/-/-/-/-/-/-/-/-/-/-
   owner      AEDD01
   owner_CCU  VCCU
   Helper:
     CreditTimer 3
     FW         66561
     Initialized 1
     AckPending:
     LastSendLen:
       3
       3
     Log:
       IDs:
     RoundTrip:
       Delay      0.00501012802124023
     loadLvl:
       lastHistory 1517078529.5259
   MatchList:
     1:CUL_HM   ^A......................
   Peers:
   READINGS:
     2018-01-27 19:42:09   D-HMIdAssigned  AEDD01
     2018-01-27 19:42:09   D-HMIdOriginal  65102C
     2018-01-27 19:42:09   D-firmware      1.4.1
     2018-01-27 19:42:09   D-serialNr      OEQ2298126
     2018-01-27 19:21:08   D-type          HM-MOD-UART
     2018-01-27 19:42:09   cond            ok
     2018-01-27 19:42:09   load            0
     2018-01-27 19:42:09   loadLvl         low
     2018-01-27 19:42:07   state           opened
Attributes:
   hmId       AEDD01
   room       VCCU


294FB8 ist die HMId des erwähnten Test-Aktors.

Dass das Ding grundsätzlich senden kann, weiß ich auch, denn ich habe zufällig gesehen, dass mein Haupt-FHEM eine Nachricht aufgeschnappt hat, die nur von ihm stammen kann:
2018-01-27 19:47:07 HMLAN HMLAN UNKNOWNCODE A0FCA943FAEDD01000000020221FF85AB::-41:HMLAN
Komischerweise zu einem Zeitpunkt, an dem keine Übertragung anstand. Wenn ich aber den Aktor ein oder ausschalten will, registriert auch mein Haupt-FHEM keine Nachrichten.

Wenn ich das Ding übers Netzwerk verbinde, und USR-TCP232-T2 angelehnt an amunras Dokumentation konfiguriere, dann wird das Ding zwar auch von FHEM erkannt, wechselt aber ständig von "init" auf "disconnected":

2018.01.27 19:41:01.064 1: 192.168.178.83:23 reappeared (myHmUARTLGW)
2018.01.27 19:41:05.069 1: HMUARTLGW myHmUARTLGW did not respond for the 1. time, resending
2018.01.27 19:41:08.075 1: HMUARTLGW myHmUARTLGW did not respond for the 2. time, resending
2018.01.27 19:41:11.080 1: HMUARTLGW myHmUARTLGW did not respond for the 3. time, resending
2018.01.27 19:41:14.085 1: HMUARTLGW myHmUARTLGW did not respond after all, reopening
2018.01.27 19:41:14.091 1: 192.168.178.83:23 reappeared (myHmUARTLGW)
2018.01.27 19:41:18.097 1: HMUARTLGW myHmUARTLGW did not respond for the 1. time, resending
2018.01.27 19:41:21.102 1: HMUARTLGW myHmUARTLGW did not respond for the 2. time, resending
2018.01.27 19:41:24.106 1: HMUARTLGW myHmUARTLGW did not respond for the 3. time, resending
2018.01.27 19:41:27.111 1: HMUARTLGW myHmUARTLGW did not respond after all, reopening
2018.01.27 19:41:27.125 1: 192.168.178.83:23 reappeared (myHmUARTLGW)
2018.01.27 19:41:31.131 1: HMUARTLGW myHmUARTLGW did not respond for the 1. time, resending
2018.01.27 19:41:34.137 1: HMUARTLGW myHmUARTLGW did not respond for the 2. time, resending
2018.01.27 19:41:37.142 1: HMUARTLGW myHmUARTLGW did not respond for the 3. time, resending
2018.01.27 19:41:40.147 1: HMUARTLGW myHmUARTLGW did not respond after all, reopening


Und das geht so endlos weiter.

Hier ein List:
Internals:
   CNT        1
   Clients    :CUL_HM:
   DEF        uart://192.168.178.83:23
   DevState   1
   DevType    UART
   DeviceName 192.168.178.83:23
   FD         9
   LastOpen   1517077522.93927
   NAME       myHmUARTLGW
   NR         21
   PARTIAL   
   STATE      opened
   TYPE       HMUARTLGW
   XmitOpen   0
   model      HM-MOD-UART
   owner_CCU  VCCU
   Helper:
     AckPending:
       1:
         cmd        00
         dst        0
         frame      FD00030001009E03
         resend     3
         time       1517077523.94164
     LastSendLen:
       3
     Log:
       IDs:
         all
          sys
   MatchList:
     1:CUL_HM   ^A......................
   Peers:
     294FB8     pending
   READINGS:
     2018-01-27 19:21:08   D-type          HM-MOD-UART
     2018-01-27 19:25:23   cond            init
     2018-01-27 19:21:08   loadLvl         suspended
     2018-01-27 19:25:22   state           opened
   helper:
Attributes:
   hmId       AEDD01
   logIDs     all, sys
   room       VCCU


Kann jemand was mit den Informationen anfangen und weiß, wo es hackt?

Ich war mir nicht sicher, ob das Thema hier oder im Homematic-Forum besser aufgehoben ist, kann es natürlich verschieben, wenn Ihr es anders sehen solltet.


tndx

Hier noch ein Mitschnitt der Kommunikation mit dem Aktor, die Sequenz war
- Aktor an mit Knopf
- In der FHEM-Oberfläche auf "off" geklickt
- Anschließend wieder mit dem Knopf ausgeschaltet

018.01.27 20:30:23.815 0: HMUARTLGW myHmUARTUSB recv: 01 05 00 00 1A msg: 08 A4 10 294FB8 AEDD01 0601C800
2018.01.27 20:30:28.164 0: HMUARTLGW myHmUARTUSB recv: 01 05 00 00 19 msg: 08 A4 10 294FB8 AEDD01 0601C800
2018.01.27 20:30:32.881 0: HMUARTLGW myHmUARTUSB recv: 01 05 00 00 19 msg: 08 A4 10 294FB8 AEDD01 0601C800
2018.01.27 20:30:38.343 0: HMUARTLGW myHmUARTUSB recv: 01 05 00 00 19 msg: 08 A4 10 294FB8 AEDD01 0601C800
2018.01.27 20:30:45.791 0: HMUARTLGW myHmUARTUSB recv: 01 05 00 00 19 msg: 08 A4 10 294FB8 AEDD01 0601C800
2018.01.27 20:30:57.212 0: HMUARTLGW myHmUARTUSB recv: 01 05 00 00 1A msg: 08 A4 10 294FB8 AEDD01 0601C800
2018.01.27 20:31:24.081 0: HMUARTLGW myHmUARTUSB recv: 01 05 00 00 1B msg: 0A A4 10 294FB8 AEDD01 06010000


Wie man sieht versucht das Ding erst gar nicht zu senden, oder?

PeMue

#2
Hallo tndx,

ich kenne die Platine nicht im Detail, aber hast Du den USB2seriell Konverter und den USR-TCP232-T2 parallel angeschlossen? Bei einer seriellen Schnittstelle sollte entweder der eine oder der Andere angeschlossen sein. Sind die beiden steckbar?
Im list habe ich gesehen, dass die HMID gesetzt ist, d.h. er sollte Meldungen dekodieren können.
Ansonsten wäre es gut, wenn Du ein Bild der Platine posten könntest. Schaltplan (kaum leserlich, aber ok) habe ich. Prinzipiell sollte es funktionieren, denn ich hatte den HM-MOD-UART-RPI mit meiner Platine und einem USR-TCP232-T2 probeweise im Einsatz und da hat er Messages dekodiert. Wenn er das kann, sollte er auch Aktoren schalten können  ;)

Gruß Peter

Edit:
Wo holt sich die Schaltung eigentlich die Versorgungsspannung her? Ist da der USB2seriell Wandler notwendig? Spannungsregler ist ja keiner drauf. Ggf. kann man beim USR-TCP232-T2 5 V über USB einspeisen und für den Rest die 3,3 V des internen Regler des USR-TCP232-T2 verwenden. Aber ich weiß nicht, ob das auf der Platine so vorgesehen ist.
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

tndx

Hi PeMue,

also der Seriell-Konverter und USR-TCP232-T2 sind parallel angeschlossen, ich habe bei meinen Versuchen es entweder über USB (1.) oder übers Netzwerk(2.) versucht. Bei 1. war das Netzwerkkabel nicht angeschlossen, aber trotzdem stand USR-TCP232-T2 unter Strom, da die Versorgungsspannung vom Seriell-Konverter kommt. Bei 2. hing das Ding am Netzwerkkabel, an der USB-Buchse des Seriell-Konverters war ein USB-Netzteil angeschlossen, die Datenleitungen also nicht belegt.

Ich habe irgendwo gelesen, dass dieser Parallelbetrieb ausdrücklich möglich sein soll beim USR-TCP232-T2, finde aber die Stelle nicht wieder. Aber amunra schrieb irgendwo in seinem Thread, dass es so beabsichtigt sei, damit man zur Not HM-MOD-UART-RPI auch über USB betreiben kann. Mit dem USR-TCP232-T scheint es bei ihm auch geklappt zu haben.

Anbei sind die Bilder der Platine, oder wolltest Du meinen Aufbau sehen?

PeMue

Zitat von: tndx am 27 Januar 2018, 21:15:44
Anbei sind die Bilder der Platine, oder wolltest Du meinen Aufbau sehen?
Bilder Deines Aufbaus wären schön. Aber ich denke, es sind sowieso nur drei Bauteile drauf:
- USB2seriell Konverter
- HM-MOD-UART-RPI
- USR-TCP232-T2

Zitat von: tndx am 27 Januar 2018, 21:15:44
Ich habe irgendwo gelesen, dass dieser Parallelbetrieb ausdrücklich möglich sein soll beim USR-TCP232-T2, finde aber die Stelle nicht wieder.
Da bin ich mir ehrlich gesagt nicht wirklich sicher. An amura's Stelle hätte ich da (zugängliche) Lötjumper eingebaut, dann wäre das Thema erledigt.
Du hast ja bei RX (HM-MOD-UART-RPI) zweimal Tx (USB2seriell bzw. USR-TCP232-T2). Wenn der USR-TCP232-T2 arbeiten darf, muss er ja den USB2seriell "überschreiben". Dieser ist auf jeden Fall nicht stromlos ...

Zitat von: tndx am 27 Januar 2018, 21:15:44
Bei 2. hing das Ding am Netzwerkkabel, an der USB-Buchse des Seriell-Konverters war ein USB-Netzteil angeschlossen, die Datenleitungen also nicht belegt.
Ich meine, manche Ladekabel haben interne Widerstände an den Datenleitungen, um den Powerlademodus zu aktivieren. Was dann mit dem USB2seriell Wandler passiert, kann ich nicht sagen.

Vermutlich sind die Bauteile alle verlötet (und nicht gesockelt). Sonst hättest Du den USR-TCP232-T2 runternehmen können und einfach mal per USB testen können.

Gruß PeMue
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

tndx

#5
Zitat von: PeMue am 27 Januar 2018, 21:59:29
Bilder Deines Aufbaus wären schön. Aber ich denke, es sind sowieso nur drei Bauteile drauf:
- USB2seriell Konverter
- HM-MOD-UART-RPI
- USR-TCP232-T2
Genau so sieht es aus, s.u. Ich kann natürlich die ensprechenden Pins beim USR-TCP232-T2 durchknipsen und so natürlich wenigstens den USB-Pfad testen, beim Seriell-Konverter kriege ich es nicht so einfach hin.

Auf amunras Fotos in seiner Doku S.40-41 sieht es genau so aus, abgesehen davon, dass er USR-TCP232-T benutzt hat, und bei ihm soll es funktioniert haben

tndx

#6
Kurzes Update:

Zitat von: PeMue am 27 Januar 2018, 21:59:29
Ich meine, manche Ladekabel haben interne Widerstände an den Datenleitungen, um den Powerlademodus zu aktivieren. Was dann mit dem USB2seriell Wandler passiert, kann ich nicht sagen.

Ich habe jetzt ein Netzteil angeschlossen, bei dem garantiert die Datenleitungen nicht belegt sind, trotzdem weigert sich der GW mit den gleichen Symptomen zu funktionieren.

Beta-User

Habe eben diesen Thread hier gefunden wg. des Wiki-Artikels dazu. Die Bilder (oder eines) würde ich verwenden wollen, ich gehe davon aus, dass das ok ist.

Kann es sein, dass auch hier das Problem mit dem CP2102-Micro-Modul vorliegt und daher mehr anliegen als die 3.3V? (Darauf reagiert mind. das PI-Modul leider mit disconnects usw.)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

tndx

Die Bilder können verwendet werden, klar!

Die 4,2V lagen hier zu dem Zeitpunkt auch an, jedoch war das Problem tatsächlich, dass auch die Datenleitungen des CP2102-Moduls mit der Platine verbunden waren, was offenbar USR-TCP232-T2 verwirrt hat. Das CP2102-Modul wird hier nämlich nur als Stromversorger und Spannungswandler benutzt. Sind die Datenleitungen nicht verbunden, läuft der GW wie beabsichtigt.