[gelöst] hm-mod-rpi-pcb mit usb zu seriell Adapter betreiben

Begonnen von maddinthebrain, 21 Dezember 2017, 12:18:12

Vorheriges Thema - Nächstes Thema

maddinthebrain

#30
Ich habe mir mal den Schaltplan angesehen http://nicecircuits.com/ch340g-usb-to-rs232-ttl-module-schematic-d-sun-v3-0/ Das Problem der Versorgungsspannung sollte mit erträglichem Aufwand zu lösen sein. Sie liegt schon an dem 3,3V-Pin an. Ich versuche mal mein Glück.
Das mit Reset ist noch mit Fragezeichen, wofür braucht, man den? Den haben andere Wandler doch auch nicht. Auch den Progpin. Ich denke der ist für das Flashen der Firmware nötig. Geht das mit solchen Adaptern überhaupt?
Ich werde berichten.

Grüße Martin
Viele Grüße
Martin

Futro mit Proxmox und Debian: FHEM, Signalduino 433MHz & 868MHz, MAX!, WeeWX, FHEM2FHEM,
Raspi 4 mit ConBee mit deCONZ und Phoscon für ZigBee Aktoren und Sensoren

Gluon

Seltsam, warum schreibt man sich hier die Finger wund? Egal, Du kannst natürlich machen was Du willst.

Damit es bei anderen Lesern zu keinen Verwirrungen.kommt.

Kein Reset, kein Progpin, nur:

3,3V (optimal 100 mA, wie z. B.  CP2102)
GND
RxD
TxD

benötigt.

Bitte beachten, dass bei einer seriellen Schnittstelle RxD und TxD gekreuzt angeschlossen werden.

TxD des USB-Moduls auf RxD des HM-MOD-RPI-PCB
RxD des USB-Moduls auf TxD des HM-MOD-RPI-PCB

Immer Sender TxD auf Empfänger RxD und umgekehrt.

USB-Seriell-Wandler mit CP2102 funktionieren. Beispiel:ELV UM2102N

Das Flashen der Firmware des HM-MOD-RPI-PCB funktioniert damit ebenfalls einwandfrei, auch mittels Fhem.


Beta-User

@Gluon: Willkommen im Club der Finger-Wunschreiber ;) ...

Nur interessehalber: Warum so einen Aufwand um den CH340G rum betreiben?
Da kann man keine Adresse/Kennung einstellen (was mit FTDI und wohl auch dem CP2102 geht bzw. gehen sollte), und die Dinger sind auf allen Billig-Nanos verbaut. Das führt also nur zu (USB-) Verwirrung...

Preislich nimmt sich das kaum was, ich meine, dass man die 2102-er für <2 Euro aus China bekommt.

Wäre nur interessant, ob das mit dem Umbenennen jemand mal in jüngerer Vergangeheit gemacht hat, bei mir steht das auf der Prio-Liste ganz unten, sonst würde ich das mal ausprobieren.

Just my2ct.

Beta-User
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

maddinthebrain

Das ist mal eine klare Antwort! Super Dankeschön!  :) genau das wollte ich ja auch wissen.
Vielen Dank.

Grüße Martin
Viele Grüße
Martin

Futro mit Proxmox und Debian: FHEM, Signalduino 433MHz & 868MHz, MAX!, WeeWX, FHEM2FHEM,
Raspi 4 mit ConBee mit deCONZ und Phoscon für ZigBee Aktoren und Sensoren

Beta-User

Zitat von: Beta-User am 30 Dezember 2017, 13:05:56
Wäre nur interessant, ob das mit dem Umbenennen jemand mal in jüngerer Vergangeheit gemacht hat, bei mir steht das auf der Prio-Liste ganz unten, sonst würde ich das mal ausprobieren.

Hab's ausprobiert und mal 3 CP2102 umbenannt, das geht jedenfalls mit serial-number und product-string. Ergebnis sieht dann so aus:
define myHmUART HMUARTLGW /dev/serial/by-id/usb-Silicon_Labs_myHMUART_0001-if00-port0

oder
Zitatusb-Silicon_Labs_Multi_TTL_RS485_0003-if00-port0

Fazit: Damit lassen sich beliebig viele dieser Teile problemlos nebeneinander betreiben und sauber anhand ihrer "by-id"-Angaben auseinanderhalten. Wenn es jetzt noch Nanos mit den Dinger gäbe, wäre alles gut 8) . So muß man halt im Bedarfsfall löten.

Geht unter Linux mit einem Python-Programm namens cp210x-program von hier: http://cp210x-program.sourceforge.net/. Benötigt unter Debian u. Derivaten python-serial. Die Anwendung ist mit Hilfe der enthaltenen Readme kein großes Problem, Ausfälle oder Probleme hatte ich bei den drei Geräten nicht, aber Gewähr für's Gelingen übernehme ich natürlich keine.

Gruß, Beta-User
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

mark79

Nabend, ich wechsel gerade von einem RPi1 auf ein Rock64 Board und ich schaffe es nicht, die hm-mod-rpi-pcb Platine mit einem CP2102 TTL USB Interface anzubinden.

Auf meinem RPi 1 läuft die Anbindung via USB TTL (CP2102) Interface, sowie wie vorher per GPIO.

Auf dem Rock64 Board geht das leider nicht, log siehe unten.

Ich habe schon die Rechte von /dev/ttyUSB1, sowie
/dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
auf 0777 gesetzt...

Hier ein Log:

2018.04.13 22:35:04 1: HMUARTLGW hmUART did not respond after all, reopening
2018.04.13 22:35:04 4: HMUARTLGW hmUART Reopen
2018.04.13 22:35:04 3: hmUART device closed
2018.04.13 22:35:04 3: Setting hmUART serial parameters to 115200,8,N,1
2018.04.13 22:35:04 1: /dev/ttyUSB1 reappeared (hmUART)
2018.04.13 22:35:05 4: HMUARTLGW hmUART StartInit
2018.04.13 22:35:05 5: HMUARTLGW hmUART send: 00 00
2018.04.13 22:35:05 5: HMUARTLGW hmUART send: (8): fd00030001009e03
2018.04.13 22:35:05 5: SW: fd00030001009e03
2018.04.13 22:35:08 1: HMUARTLGW hmUART did not respond for the 1. time, resending
2018.04.13 22:35:08 5: HMUARTLGW hmUART send: (8): fd00030001009e03
2018.04.13 22:35:08 5: SW: fd00030001009e03
2018.04.13 22:35:11 1: HMUARTLGW hmUART did not respond for the 2. time, resending
2018.04.13 22:35:11 5: HMUARTLGW hmUART send: (8): fd00030001009e03
2018.04.13 22:35:11 5: SW: fd00030001009e03
2018.04.13 22:35:12 5: HMUARTLGW hmUART HMUARTLGW_Write: As0B06847033ABCD00000000DB
2018.04.13 22:35:12 1: HMUARTLGW hmUART: Device not initialized (state: 1, init) but asked to send data. Dropping: As0B06847033ABCD00000000DB
2018.04.13 22:35:14 1: HMUARTLGW hmUART did not respond for the 3. time, resending
2018.04.13 22:35:14 5: HMUARTLGW hmUART send: (8): fd00030001009e03
2018.04.13 22:35:14 5: SW: fd00030001009e03
2018.04.13 22:35:17 1: HMUARTLGW hmUART did not respond after all, reopening
2018.04.13 22:35:17 4: HMUARTLGW hmUART Reopen
2018.04.13 22:35:17 3: hmUART device closed
2018.04.13 22:35:17 3: Setting hmUART serial parameters to 115200,8,N,1
2018.04.13 22:35:17 1: /dev/ttyUSB1 reappeared (hmUART)
2018.04.13 22:35:18 4: HMUARTLGW hmUART StartInit
2018.04.13 22:35:18 5: HMUARTLGW hmUART send: 00 00
2018.04.13 22:35:18 5: HMUARTLGW hmUART send: (8): fd00030001009e03


MfG.
Mark
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten

Otto123

Hallo Mark,

sieht aus einer Sicht aus, als ob da kein Modul am USB1 ist. Sicher mit USB1?

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

mark79

#37
Hallo Otto,

daran liegt es leider nicht.. ich habe es mehrfach über /dev/ttyUSB* probiert und über /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 und neugestartet...

Kann es evtl. am noch laufenden agetty liegen? Ich habe den zwar gekillt, weil ich nicht genau weiß, wie ich den deaktivieren kann.
Aber trotzdem geht es nicht. Aber ich meine, einmal kurz hat es funktioniert, aber auch erst nach einigen reconnects...

Hier noch mal ein paar Daten:

root@rock64:~# ls -l /dev/serial/by-id/
insgesamt 0
lrwxrwxrwx 1 root root 13 Apr 13 22:59 usb-1a86_USB2.0-Serial-if00-port0 -> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 Apr 13 22:59 usb-FTDI_FT232R_USB_UART_A9SZV11H-if00-port0 -> ../../ttyUSB2
lrwxrwxrwx 1 root root 13 Apr 13 22:59 usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 -> ../../ttyUSB0


root@rock64:~# dmesg | grep CP2102
[    3.252368] usb 2-1.2: Product: CP2102 USB to UART Bridge Controller


root@rock64:~# lsusb
Bus 005 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 006: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
Bus 002 Device 005: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Bus 002 Device 004: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light
Bus 002 Device 003: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Bus 002 Device 002: ID 0bda:5411 Realtek Semiconductor Corp.
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


Internals:
   CNT        1
   Clients    :CUL_HM:
   DEF        /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
   DevState   1
   DevType    UART
   DeviceName /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0@115200
   FD         19
   LastOpen   1523654035.67437
   NAME       hmUART
   NR         240
   PARTIAL    ffffff
   STATE      opened
   TYPE       HMUARTLGW
   XmitOpen   0
   model      HM-MOD-UART
   Helper:
     AckPending:
       1:
         cmd        00
         dst        0
         frame      FD00030001009E03
         resend     2
         time       1523654036.68264
     LastSendLen:
       3
     Log:
       IDs:
   MatchList:
     1:CUL_HM   ^A......................
   Peers:
     5ACA0A     pending
     627184     pending
     627188     pending
   READINGS:
     2018-04-07 22:02:46   D-HMIdAssigned  332211
     2018-04-07 22:02:46   D-HMIdOriginal  59D8F9
     2018-04-07 22:02:46   D-firmware      1.4.1
     2018-04-07 22:02:47   D-serialNr      OEQ0607195
     2018-04-13 23:12:55   D-type          HM-MOD-UART
     2018-04-13 23:13:56   cond            init
     2018-04-08 14:15:45   load            8
     2018-04-13 23:12:55   loadLvl         suspended
     2018-04-13 23:13:55   state           opened
   helper:
Attributes:
   event-on-change-reading .*
   hmId       332211
   verbose    5



MfG.
Mark
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten

Otto123

Hallo Mark,
Naja zum einen
lrwxrwxrwx 1 root root 13 Apr 13 22:59 usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 -> ../../ttyUSB0

Und jetzt geht er doch oder?


Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

mark79

#39
EDIT: ich habe ein neuen Thread aufgemacht, weil dieser hier als gelöst markiert ist.
https://forum.fhem.de/index.php/topic,86980.0.html


Hey Otto,

leider nicht. :(

root@rock64:/opt# tail -f /opt/fhem/log/fhem-2018-04.log  | grep HMUARTLGW
2018.04.13 23:38:24 1: HMUARTLGW hmTTL did not respond after all, reopening
2018.04.13 23:38:28 1: HMUARTLGW hmTTL did not respond for the 1. time, resending
2018.04.13 23:38:33 1: HMUARTLGW hmTTL did not respond for the 2. time, resending
2018.04.13 23:38:39 1: HMUARTLGW hmTTL did not respond for the 3. time, resending
2018.04.13 23:38:42 1: HMUARTLGW hmTTL did not respond after all, reopening
2018.04.13 23:38:46 1: HMUARTLGW hmTTL did not respond for the 1. time, resending
2018.04.13 23:38:49 1: HMUARTLGW hmTTL did not respond for the 2. time, resending
2018.04.13 23:38:52 1: HMUARTLGW hmTTL did not respond for the 3. time, resending
2018.04.13 23:38:55 1: HMUARTLGW hmTTL did not respond after all, reopening
2018.04.13 23:38:59 1: HMUARTLGW hmTTL did not respond for the 1. time, resending
2018.04.13 23:39:02 1: HMUARTLGW hmTTL did not respond for the 2. time, resending
2018.04.13 23:39:05 1: HMUARTLGW hmTTL did not respond for the 3. time, resending
2018.04.13 23:39:08 1: HMUARTLGW hmTTL did not respond after all, reopening
2018.04.13 23:39:12 1: HMUARTLGW hmTTL did not respond for the 1. time, resending
2018.04.13 23:39:15 1: HMUARTLGW hmTTL did not respond for the 2. time, resending
2018.04.13 23:39:18 1: HMUARTLGW hmTTL did not respond for the 3. time, resending
2018.04.13 23:39:21 1: HMUARTLGW hmTTL did not respond after all, reopening
2018.04.13 23:39:25 1: HMUARTLGW hmTTL did not respond for the 1. time, resending


Weißt du ob enable_uart=1, dtoverlay und a/getty... bei einer hm-mod-rpi-pcb Platine via CP2102 TTL USB Interface auch eingerichtet sein muss?

Der nanoCUL hingegen läuft, der am selben USB Hub (mit externer Stromversorgung) hängt.

MfG
Mark
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten

maddinthebrain

Hallo Mark,

Schau mal was bei dir steht wenn du List deinhmdevice machst.

Bei mir sieht es so aus:
Internals:
   AssignedPeerCnt 1
   CNT        210
   Clients    :CUL_HM:
   DEF        /dev/serial/by-path/platform-3f980000.usb-usb-0:1.4:1.0-port0
   DEVCNT     210
   DevState   99
   DevType    UART
   DeviceName /dev/serial/by-path/platform-3f980000.usb-usb-0:1.4:1.0-port0@115200
   FD         28
   LastOpen   1527702851.3404
   NAME       myHmUART
   NR         95
   PARTIAL   
   RAWMSG     040204
   RSSI       -87
   STATE      opened
   TYPE       HMUARTLGW
   XmitOpen   1
   model      HM-MOD-UART
   msgLoadCurrent 2
   msgLoadHistory 0/0/0/1/0/0/0/0/1/0/0/0
   msgLoadHistoryAbs 2/2/2/2/1/1/1/1/1/0/0/0/0
   owner      801401
   Helper:
     CreditTimer 17327
     FW         66561
     Initialized 1
     SendCnt    13
     AckPending:
     LastSendLen:
       3
       3
     Log:
       IDs:
     PeerQueue:
     PendingCMD:
     RoundTrip:
       Delay      0.0050661563873291
     loadLvl:
       lastHistory 1527962976.95145
   MatchList:
     1:CUL_HM   ^A......................
   Peers:
     56E9A0     +56E9A0,00,00,00
   READINGS:
     2018-05-30 19:54:36   D-HMIdAssigned  801401
     2018-05-30 19:54:36   D-HMIdOriginal  59D566
     2018-05-30 19:54:36   D-firmware      1.4.1
     2018-05-30 19:54:36   D-serialNr      OEQ0606284
     2018-05-30 19:54:11   D-type          HM-MOD-UART
     2018-05-30 19:54:36   cond            ok
     2018-06-02 19:50:16   load            2
     2018-05-30 19:54:36   loadLvl         low
     2018-05-30 19:54:11   state           opened
   helper:
Attributes:
   DbLogExclude .*
   hmId       801401
   icon       cul_usb
   room       Funk
   verbose    0


Grüße Martin
Viele Grüße
Martin

Futro mit Proxmox und Debian: FHEM, Signalduino 433MHz & 868MHz, MAX!, WeeWX, FHEM2FHEM,
Raspi 4 mit ConBee mit deCONZ und Phoscon für ZigBee Aktoren und Sensoren

mark79

#41
Hallo Martin,

das läuft jetzt und mittlerweile habe ich die HM-MOD Platine auf ein MapleCUN gepackt.
Ich vermute vorher war der TTL USB Wandler daran schuld. Der hatte wohl eine Macke.

   DEF        /dev/serial/by-id/usb-STM32_MapleCUL_def25096-if04
   DEVCNT     156
   DevState   99
   DevType    UART
   DeviceName /dev/serial/by-id/usb-STM32_MapleCUL_def25096-if04@115200


Viele Grüße
Mark


Zitat von: maddinthebrain am 02 Juni 2018, 20:14:21
Hallo Mark,

Schau mal was bei dir steht wenn du List deinhmdevice machst.
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten