Hallo,
leider muss ich zu diesem Thema noch einen Thread eröffnen.
Kann ich das UART Modul ohne das TRX1 Modul und ohne weitere Hardware an den USB TTL Wandler anlöten?
Im WIKI steht unter "Platine 2 -UART-Modul" dass ohne TRX1 Modul Stützkondensatoren benötigt werden.
Unter "Anbindung mit USB-Adapter" steht, dass das UART Modul an den TTL wanlder angelötet werden soll.
Was ich bislang an Bildern gesehen habe war immer mit TRX1 am TTL Wandler angelötet.
Ich würde gerne das ganze in ein Gehäuse packen und habe daher wenig Platz.
Wenn das sicher geht, würde ich das UART Modul wie auf dem Bild anlöten. TX und RX natürlich über kreuz.
Hallo Willi,
Zitat von: willib am 12 Juni 2019, 21:44:30
Kann ich das UART Modul ohne das TRX1 Modul und ohne weitere Hardware an den USB TTL Wandler anlöten?
Im WIKI steht unter "Platine 2 -UART-Modul" dass ohne TRX1 Modul Stützkondensatoren benötigt werden.
ja müsste gehen. Stützkondensator wäre von Vorteil. Einfach probieren und falls erforderlich einen kleinen Elektrolytkondensator (bedrahtet) einlöten.
Gruß Peter
Ich denke die Stützkondensatoren wären nicht schlecht...
...aber ich habe es direkt an einen Billig-China-USB-Adapter (CP2102) gelötet...
...also ohne die Adapterplatine weil es sollte (und tut es auch) in ein "USB-Stick-Gehäuse" passen... :)
AUFPASSEN: nachmessen, ob da wirklich nur 3,3V rauskommen!!
Hatte das Funkmodul mal an einen dran, der zwar auf 3,3V "gejumpert" war...
...aber trotzdem 5V geliefert hat...
(hatte vergessen nachzumessen)
War doof ;)
Läuft bei mir (nachdem ich beim nächsten nachgemessen habe) seit gut 1/2 Jahr plus ohne Probleme an meinem Testsystem...
Ja hängt per USB an einem PI wo sonst nix dran ist ;)
Aber das ist der Ersatz für den Fall, dass mein aktueller HM-CFG-USB mal ausfällt und da wo der dran ist habe ich nur noch USB frei...
Gruß, Joachim
Vielen Dank Euch.
Ich besorge mir mal sicherheitshalber einen 100nF Elko.
Zitat von: willib am 13 Juni 2019, 13:09:48
Vielen Dank Euch.
Ich besorge mir mal sicherheitshalber einen 100nF Elko.
Aber wohl eher 100
μF ;)
Gruß, Joachim
So, habe heute erfolgreich zwei TTL Converter gekillt.
Habe einen 50 micro Farad Elko 50V genommen.
Bevor ich meine Lötkünste angewendet habe hat mein Windowsrechner beim An- und Abstecken ein Geräusch gemacht und der TTL Converter hat jeweils kurz geblinkt.
Nachdem ich wie auf dem Foto verbunden hatte war das vorbei. GND hat Verbindung mit der Schirmung durch einen kleinen Spritzer Lötzinn. Aber das kann es ja wohl nicht sein, oder?
Kann mir jemand sagen was ich Falsch gemacht habe? Ist es der Elko? Kann ich die Converter noch retten? Und noch wichtiger: Ist mein HM Modul jetzt auch hinüber?
Kann es sein, das der "Spritzer" nicht eher einen Schluss zwischen 3,3 Volt und GND produziert? Da der Spannnunsgregler im Chip sitzt wird der dadurch kurzgeschlossen. Ob der das aushält weiß ich nicht.
Also das Funkmodul sollte noch ganz sein. Vermutlich ist der Regler kurzschlussfest und nach "Sauberlöten" könnte es klappen.
Anbei mal ein Foto von meiner Variante ohne "Kabel". Die zwei Spannungspins und einer der Signalpins konnen direkt
verbunden werden, der andere mit spitzzangengebogenem Widerstandsbeinchen. Meine Lötkolbenempfehlung (https://www.ersa-shop.com/ersa-l%C3%B6tkolben-230v-p-2701.html).
Edith:
Der Adapter (https://www.amazon.de/gp/product/B078W5L8W1/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8&psc=1) und ein passendes Gehäuse (https://www.amazon.de/gp/product/B07R69SYST/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1) mit LED- Leuchtgarantie. Mein anderer Stick steckt in einem Gehäuse vom defekten HM-USB-CFG.
Da sieht man die LEDs nur im Dunklen. ;o) Bei den Adaptern sind auch schöne klare Gehäuse dabei, aber damit wäre das Funkmodul nicht
eingehaust und man kann keine Antennenbuchse mit einbauen.
Danke für eure Tipps. Denn Widerstand auf der hm Platine zwischen GND und 3,3 V habe ich gemessen. Da sind 250M Ohm also kein Kurzschluss. Ich verstehe nicht wieso die Adapter aussteigen. Montag kommen die hier https://www.amazon.de/gp/aw/d/B07NNSNBTY?ref=ppx_pt2_mob_b_prod_image (https://www.amazon.de/gp/aw/d/B07NNSNBTY?ref=ppx_pt2_mob_b_prod_image) dann werde ich die zweite HM Platine mit verlöten und auf den zusätzlichen Elko verzichten. Dann kommt das ganze in ein großes Gehäuse und wird per USB Verlängerungskabel angeschlossen. Ich hoffe dann klappt es. Ich weiß bloß immer noch nicht was schief gelaufen ist.
Ich habe das mit dem RPI Modul glaub ich nie gemessen - aber ich weiß es vom ESP Modul. Die USB Adapter haben einen mini 5 Volt zu 3,3 Volt Regler an Board. Die sind in der Regel nicht dazu gedacht etwas wirklich zu "versorgen".
Ob das bei Dir ein Problem sein kann?
Danke Otto, das ist auch eine Möglichkeit. Ich werde mir noch die andere Adapter besorgen. Wobei es im Prinzip ja immer ein CP2102 ist.
Könnte es der Ladestrom meines Elko sein der zu hoch ist?
Zitat von: willib am 30 September 2019, 08:52:03
Könnte es der Ladestrom meines Elko sein der zu hoch ist?
Eher nein, der ist ja irgendwann geladen und dann müsste der Spannungsregler wieder den "normalen" Strom liefern können.
Gruß Peter
Bevor ich nun den nächsten TTL Converter schrotte... Hat noch jemand einen Tipp für mich?
Kann ich den HM-MOD-RPI-PCB durch messen um sicherzugehen? was sind dann korrekte Werte?
Oder muss ich mir andere Converter kaufen weil meine den HM-MOD-RPI-PCB nicht versorgen können? RX und TX zu vertauschen sollte ja wohl nicht zum Ausfall führen.
Nochmal um das klarzustellen. Die beiden zuvor benutzten Converter sind jetzt defekt.
Die von mir benutzen Adapter (Link oben) gehen recht gut. Habe schon die zweite Packung hier. Kann ich guten Gewissens empfehlen.
Ich würde jetzt zuerst das Funkmodul an 3,3 oder auch 3V (Knopfzelle) zur Sicherheit mit einem ca. 100 Ohm- Widerstand in Reihe anschließen und mit einem Multimeter die Stromaufnahme messen. Die sollte im Bereich nicht messbar bis wenige mA sein. Wenn das passt kann anschließend der Adapter nicht beschädigt werden. Jetzt würde ich das Modul mit etwas längeren sehr dünnen Litzen oder Drähten an den Adapter löten und sehen, ob das Modul in FHEM erkannt wird. Zuvor noch mal messen, ob die 3,3 V vom Adapter stehen. Wenn das geht, die FW updaten und die HM- Funktionalität testen.
Wenn alles geht, kann zusammengelötet werden. Ich habe dazu von Modul und Adapter die Stiftleisten abgelötet. Dann von der Stiftleiste des Moduls 2 Stifte abtrennen und für die Verbindung 3,3V und GND verwenden. RX und TX mit dünnen Adern oder Wiederstansbeinchen verbinden - fertig. Übrigens kannst du den Elko auch weglassen und wenn du nicht darauf verzichten willst, ihn erst ganz zum Schluss nach nochmaligem Test auflöten.
Vielen dank für deine ausführliche Anleitung. SO werde ich es machen. Es freut mich besonders dass du erfolgreich dieselben Converter einsetzt.
Ich habe nun vermutlich eine funktionierendes Gerät.
Leider komme ich bei der Einbindung in FHEM nicht weiter. Ich habe den HM Stick gebaut um in Zukunft FHEM auf einem NUC in einem LXC (Container unter Proxmox) zu betreiben.
Hier das List
Internals:
CFGFN
CNT 1
Clients :CUL_HM:
DEF /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0@115200
DevState 0
DevType UART
DeviceName /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0@115200
FUUID 5dcab541-f33f-eed2-85d8-1c11577f0a4602fc
NAME USB_HmUART
NOTIFYDEV global
NR 27
NTFY_ORDER 50-USB_HmUART
PARTIAL
STATE disconnected
TYPE HMUARTLGW
XmitOpen 0
model HM-MOD-UART
Helper:
AckPending:
1:
cmd 03
dst 0
frame FD00030001039E09
time 1573565823.8742
LastSendLen:
3
Log:
IDs:
MatchList:
1:CUL_HM ^A......................
READINGS:
2019-11-12 14:36:35 D-type HM-MOD-UART
2019-11-12 14:36:01 cond disconnected
2019-11-12 14:36:01 loadLvl suspended
2019-11-12 14:37:20 state disconnected
Attributes:
Laut Log habe ich Probleme mit den Permissions
2019.11.12 14:52:14 1: update finished, "shutdown restart" is needed to activate the changes.
2019.11.12 14:52:14 1:
2019.11.12 14:52:14 1: Please consider using the global attribute sendStatistics
2019.11.12 14:52:31 0: Server shutdown
2019.11.12 14:52:32 1: Including fhem.cfg
2019.11.12 14:52:32 3: WEB: port 8083 opened
2019.11.12 14:52:32 2: eventTypes: loaded 6 events from ./log/eventTypes.txt
2019.11.12 14:52:32 1: Including ./log/fhem.save
2019.11.12 14:52:32 3: Opening USB_HmUART device /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
2019.11.12 14:52:32 1: USB_HmUART: Can't open /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0: Operation not permitted
2019.11.12 14:52:32 0: Featurelevel: 5.9
2019.11.12 14:52:32 0: Server started with 7 defined entities (fhem.pl:20460/2019-11-05 perl:5.028001 os:linux user:fhem pid:311)
2019.11.12 14:52:32 3: FHEMWEB WEB CSRF error: csrf_526261520842411 ne csrf_114905981463693 for client WEB_192.168.178.30_64734 / command shutdown restart. For details see the csrfToken FHEMWEB attribute.
2019.11.12 14:52:32 0: Server shutdown
2019.11.12 14:52:32 1: Including fhem.cfg
2019.11.12 14:52:33 3: WEB: port 8083 opened
2019.11.12 14:52:33 2: eventTypes: loaded 6 events from ./log/eventTypes.txt
2019.11.12 14:52:33 1: Including ./log/fhem.save
2019.11.12 14:52:33 3: Opening USB_HmUART device /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
2019.11.12 14:52:33 1: USB_HmUART: Can't open /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0: Operation not permitted
2019.11.12 14:52:33 0: Featurelevel: 5.9
2019.11.12 14:52:33 0: Server started with 7 defined entities (fhem.pl:20460/2019-11-05 perl:5.028001 os:linux user:fhem pid:315)
2019.11.12 14:52:33 3: FHEMWEB WEB CSRF error: csrf_114905981463693 ne csrf_470480593407056 for client WEB_192.168.178.30_64733 / command shutdown restart. For details see the csrfToken FHEMWEB attribute.
Muss ich die udev rule nach dieser Anleitunghttp://ask.xmodulo.com/change-usb-device-permission-linux.html (http://ask.xmodulo.com/change-usb-device-permission-linux.html) unter Proxmox oder im FHEM LXC erstellen?
Oder muss ich etwas ganz Anderes machen?
Vielen Dank Euch!
Ich habe jetzt die rule auf dem Host (Proxmox) erstellt.
Ich erhalte beim Test
root@pve:~# ls -la /dev/ttyUSB*
crw-rw-rw- 1 root dialout 188, 0 Nov 13 09:52 /dev/ttyUSB0 das müsste also passen.
Im Container erhalte ich
root@FHEMLXC:~# ls -la /dev/ttyUSB*
crw-rw-rw- 1 root dialout 188, 0 Nov 13 09:52 /dev/ttyUSB0
---------- 1 root root 0 Nov 13 09:52 /dev/ttyUSB1
---------- 1 root root 0 Nov 13 09:52 /dev/ttyUSB2
---------- 1 root root 0 Nov 13 09:52 /dev/ttyUSB3
In die Container config habe ich folgendes geschrieben:
lxc.cgroup.devices.allow: c 166:* rwm
lxc.cgroup.devices.allow: c 189:* rwm
lxc.mount.entry = /dev/serial/by-id dev/serial/by-id none bind,optional,create=dir
lxc.mount.entry: /dev/ttyACM0 dev/ttyACM0 none bind,optional,create=file
lxc.mount.entry: /dev/ttyACM1 dev/ttyACM1 none bind,optional,create=file
lxc.mount.entry: /dev/ttyUSB3 dev/ttyUSB3 none bind,optional,create=file
lxc.mount.entry: /dev/ttyUSB2 dev/ttyUSB2 none bind,optional,create=file
lxc.mount.entry: /dev/ttyUSB1 dev/ttyUSB1 none bind,optional,create=file
lxc.mount.entry: /dev/ttyUSB0 dev/ttyUSB0 none bind,optional,create=file
Leider erhalte ich weiterhin im FHEM log:
2019.11.13 09:52:29 3: Opening USB_HmUART device /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
2019.11.13 09:52:29 1: USB_HmUART: Can't open /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0: Operation not permitted
Hallo Willi,
müssten die Rechte der Schnittstelle (User/Gruppe) nicht fhem.dialout sein?
Gruß Peter
Fhem ist in der Gruppe dialout und tty
root@FHEMLXC:~# groups fhem
fhem : dialout tty
Ist das nicht korrekt?
Zitat von: willib am 13 November 2019, 13:42:22
Ist das nicht korrekt?
Doch, sorry war mein Fehler. Ich dachte, die Rechte von /dev/ttyUSB* müsste fhem.dialout sein. Ist bei mir aber auch root.dialout. Dann kann ich Dir leider nicht weiterhelfen.
Gruß Peter
Es macht ja auch einen Unterschied ob ich /dev/ttyUSB0 auf rufe oder so wie Du
/dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
Ändere Dein define mal für /dev/ttyUSB0
Ich würde lieber by-ID definieren.
Habe es testweise geändert. Das Ergebnis ist ähnlich.
2019.11.13 14:46:37 3: Opening USB_HmUART device /dev/ttyUSB0
2019.11.13 14:46:37 1: USB_HmUART: Can't open /dev/ttyUSB0: Operation not permitted
Was hast Du denn genau bis jetzt gemacht.
Hast Du eine udev rule erstellt auf dem Hostsystem?
Beispiel
/etc/udev/rules.d/98-SIGNALduino-CUL.rules
SUBSYSTEMS=="usb", KERNEL=="ttyUSB*", ATTRS{idProduct}=="6001", ATTRS{idVendor}=="0403", SYMLINK+="SIGNALduino", MODE="0666", GROUP="dialout"
Wie hast Du die Config des Containers angepasst?
lxc.cgroup.devices.allow: c 188:* rwm
lxc.mount.entry: /dev/SIGNALduino dev/SIGNALduino none bind,optional,create=file
Ist es ein "Unprivileged container"?
Danke für deine Hilfe!
Ich habe auf dem Host in der shell von Proxmox folgende udev rule erstellt
nano 3.2 /etc/udev/rules.d/50-myusb.rules
SUBSYSTEMS=="usb", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", GROUP="dialout", MODE="0666"
Gerade nochmal GROUP auf dialout geändert. Hat leider auch nicht geholfen.
Container config habe ich so angepasst:
lxc.cgroup.devices.allow: c 166:* rwm
lxc.cgroup.devices.allow: c 189:* rwm
lxc.mount.entry = /dev/serial/by-id dev/serial/by-id none bind,optional,create=dir
lxc.mount.entry: /dev/ttyACM0 dev/ttyACM0 none bind,optional,create=file
lxc.mount.entry: /dev/ttyACM1 dev/ttyACM1 none bind,optional,create=file
lxc.mount.entry: /dev/ttyUSB3 dev/ttyUSB3 none bind,optional,create=file
lxc.mount.entry: /dev/ttyUSB2 dev/ttyUSB2 none bind,optional,create=file
lxc.mount.entry: /dev/ttyUSB1 dev/ttyUSB1 none bind,optional,create=file
lxc.mount.entry: /dev/ttyUSB0 dev/ttyUSB0 none bind,optional,create=file
Es ist ein privilegierter Container
Kann es sein das Du das wichtigste in der udev Eule vergessen hast? Wo ist das symlink. Nur dafür machen wir ja die udev rule.
Und dann schaust nach Neustart ob die Devicedatei da ist. Nimmst natürlich einen anderen Namen für den symlink.
Wenn die Devicedatei da ist passt du die Container Konfig an und startest den Container durch. Dann schauen das die Devicedatei im Container vorhanden ist. Und zum Schluss FHEM define an passen.
Die Device Datei ist jetzt im Container vorhanden:
root@FHEMLXC:~# ls -l /dev/USB_HmUART
crw-rw-rw- 1 root dialout 188, 0 Nov 13 21:37 /dev/USB_HmUART
Trotzdem erhalte ich folgendes log
019.11.13 22:14:36 0: Server shutdown
2019.11.13 22:14:36 1: Including fhem.cfg
2019.11.13 22:14:37 3: WEB: port 8083 opened
2019.11.13 22:14:37 2: eventTypes: loaded 6 events from ./log/eventTypes.txt
2019.11.13 22:14:37 1: Including ./log/fhem.save
2019.11.13 22:14:37 3: Opening USB_HmUART device /dev/USB_HmUART
2019.11.13 22:14:37 1: USB_HmUART: Can't open /dev/USB_HmUART: Operation not permitted
2019.11.13 22:14:37 0: Featurelevel: 5.9
2019.11.13 22:14:37 0: Server started with 7 defined entities (fhem.pl:20460/2019-11-05 perl:5.028001 os:linux user:fhem pid:305)
2019.11.13 22:14:37 3: FHEMWEB WEB CSRF error: csrf_115610292588704e15 ne csrf_90614066977364 for client WEB_192.168.178.30_53816 / command shutdown restart. For details see the csrfToken FHEMWEB attribute.
2019.11.13 22:14:37 0: Server shutdown
2019.11.13 22:14:37 1: Including fhem.cfg
2019.11.13 22:14:37 3: WEB: port 8083 opened
2019.11.13 22:14:37 2: eventTypes: loaded 6 events from ./log/eventTypes.txt
2019.11.13 22:14:37 1: Including ./log/fhem.save
2019.11.13 22:14:37 3: Opening USB_HmUART device /dev/USB_HmUART
2019.11.13 22:14:37 1: USB_HmUART: Can't open /dev/USB_HmUART: Operation not permitted
2019.11.13 22:14:37 0: Featurelevel: 5.9
2019.11.13 22:14:37 0: Server started with 7 defined entities (fhem.pl:20460/2019-11-05 perl:5.028001 os:linux user:fhem pid:309)
2019.11.13 22:14:37 3: FHEMWEB WEB CSRF error: csrf_90614066977364 ne csrf_489471703612806 for client WEB_192.168.178.30_53812 / command shutdown restart. For details see the csrfToken FHEMWEB attribute.
Im host sind die Berechtigungen anders:
root@pve:~# ls -l /dev/USB_HmUART
lrwxrwxrwx 1 root root 7 Nov 13 21:37 /dev/USB_HmUART -> ttyUSB0
root@pve:~#
crw-rw-rw- 1 nobody nogroup 188, 0 Nov 13 20:18 /dev/SIGNALduino
Mein Device im Container hat einen anderen Besitzer und eine andere Gruppe. Kannst Du das zu Testzwecken bitte einmal ändern.
Leider weiß ich nicht wie das geht. Ich versuche es heraus zu finden.
chown nobody:nogroup /dev/USB_HmUART
Leider immer noch
2019.11.14 19:54:12 3: Opening USB_HmUART device /dev/USB_HmUART
2019.11.14 19:54:12 1: USB_HmUART: Can't open /dev/USB_HmUART: Operation not permitted
Ich gehe davon aus, dass selbst wenn ich den HM-MOD-RPI-PCB mit meinen vorangegangen Löteskapaden beschädigt habe dieser nicht der Grund sein kann.
Habs!
Habe noch
lxc.cgroup.devices.allow: c 188:* rwm
In meine Container config hinzugefügt. Keine Ahnung wo die 189 her kam.
Nochmal Danke für deine Hilfe.
Kann ich jetzt die folgenden Zeilen aus der config wieder löschen?
lxc.cgroup.devices.allow: c 166:* rwm
lxc.cgroup.devices.allow: c 189:* rwm
lxc.mount.entry = /dev/serial/by-id dev/serial/by-id none bind,optional,create=dir
lxc.mount.entry: /dev/ttyACM0 dev/ttyACM0 none bind,optional,create=file
lxc.mount.entry: /dev/ttyACM1 dev/ttyACM1 none bind,optional,create=file
lxc.mount.entry: /dev/ttyUSB3 dev/ttyUSB3 none bind,optional,create=file
lxc.mount.entry: /dev/ttyUSB2 dev/ttyUSB2 none bind,optional,create=file
lxc.mount.entry: /dev/ttyUSB1 dev/ttyUSB1 none bind,optional,create=file
lxc.mount.entry: /dev/ttyUSB0 dev/ttyUSB0 none bind,optional,create=file
Kannst alles löschen was da zu viel ist.