Guten Abend,
ich versuche seit gestern erfolglos HM-MOD-UART-RPI mit USR-TCP232-T2 und CP2102 MICRO USB auf amunras Platine (https://forum.fhem.de/index.php/topic,62651.0.html) 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.
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?
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.
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?
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
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 (https://drive.google.com/file/d/0B6eiMICeQsa8WGtfLWd4VmtIUEE/view?usp=sharing) S.40-41 sieht es genau so aus, abgesehen davon, dass er USR-TCP232-T benutzt hat, und bei ihm soll es funktioniert haben
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.
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.)
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.