Hallo zusammen,
in https://forum.fhem.de/index.php/topic,64468.msg557024.html#msg557024 (https://forum.fhem.de/index.php/topic,64468.msg557024.html#msg557024) wurde geschrieben, dass man den HM-MOD-RPI-PCB auch über usb-to-serial Adapter betreiben kann.
Das käme für mich so in Frage, weil ich auf die Energiesparfunktionen des Raspi nicht verzichten möchte (dyn. Taktrate) und andere Gründe. So nun meine Frage: Hat das jemand schon mal so gemacht? Passt dazu der Wiki-Eintrag, abgesehen von dem Festlegen der Taktrate? Wird für eine USB-Anbindung auch eine feste Taktrate benötigt? Dann wäre das mit dem USB obsolet. Aber es wird im oben erwähnten Posting auch geschrieben, dass man den ESP8266 verwenden kann. Da wäre das Ganze doch völlig von der CPU abgekoppelt...
Für Infos wäre ich dankbar.
Schöne Grüße
Martin
Habe das Modul seit einigen Monaten an einem CP2102 hängen.
Das ist das define:
define myHmUART HMUARTLGW /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
Jedenfalls an einer armbian-TV-Box hat das mit der Taktänderung gut funktioniert (einen Pi habe ich keinen mehr im Einsatz). Link zum forumsbeitrag mit pdf, wie zu verkabeln ist findet sich im Wiki - Thinclient als Server, wenn ich das richtig im Kopf habe.
Einziges Problem, das ich bisher hatte: mein hp war vorübergehend der Meinung, das wäre ein Braile-Gerät - hing wohl mit der USB-Kennung zusammen.
Gibt auch eine Platine von amunra, auf die man das mit einem FTDI verlöten kann.
Gruß, Beta-User
Ich habe schon sehr viel im Wiki und im Forum gelesen. Extrem viele Informationen hier, aber leider auch teilweise sehr breit verteilt oder in Monsterthreads versteckt.
Ich habe hier noch einen Odroid XU4 "übrig" und würde den gerne für HM nutzen, ggf. mit YAHM/HMCCU/FHEM oder auch pur FHEM.
Bei ELV gibt es auch den USB-/Serial-Adapter UM2102N. Wäre dieser auch perfekt einsetzbar? Dann könnte man gleich alles auf einmal bestellen.
Aus China geht es zwar wesentlich günstiger, aber dauert auch mehrere Wochen und ich würde gerne loslegen.
Genügen die 100mA die der CP2102 bei 3.3V liefern kann definitiv für den einwandfreien Betrieb des HM-MOD-RPI-PCB mit voller Sendeleistung?
Oder wäre es noch besser evtl. einen 5V/3.3V Spannungswandler mit 250mA dazwischen zu schalten? Oder ist das absolut unnötig?
Wenn ich schon das Basteln anfange, würde ich es gerne gleich richtig machen, damit HW-seitig Ruhe ist.
Hat ein FTDI irgendwelche Vorteile (Treiber, Kerneleinbindung, Funktion) gegenüber einem CP2102?
Bringen die externen 868MHz-Antennen mit PigTail eine wesentliche Verbesserung der Sende-/Empfangsleistung gegenüber der einfachen Drahtantenne?
Viele Grüße
Gluon
Der ELV klingt sehr nach einem CP2102, müßte man testen.
Bei mir, wie bereits ausgeführt: keine Probleme (außer dem Braille-Thema)... Ich habe aber das ganze Modul dran hängen incl. der Platine mit einem darauf bereits verbauten Kondensator.
Ja, der ELV UM2102N hat einen aktuellen CP2102 verbaut, mit 100mA bei 3.3V.
So wie Du würde ich es auch gerne machen, um das Modul ggf. später wieder auf einen RPi montieren zu können, falls notwendig oder zum Testen.
Irgendwelche positiven/"gewinnbringenden" Erfahrungen mit SMA-Antennen?
Ich kenne im Moment nur den MAX Cube mit a-culfw und die Reichweite ist bei mir sehr gut. Wäre das HM-MOD-RPI-PCB vergleichbar "gut"?
Zitat von: Gluon am 21 Dezember 2017, 20:20:00
Wäre das HM-MOD-RPI-PCB vergleichbar "gut"?
Den Vergleich mit einem Cube habe ich nicht, nur CUL mit externer Antenne (+8dB, soweit ich das in Erinnerung habe): Die Modulreichweite ist viel besser, auch andere berichten von sehr guten Reichweiten.
Ergo: Antennenmodifikation würde ich eher nach hinten schieben, lieber ggf. noch ein zweites IO, wenn es wirklich benötigt wird (Ansteuerung als CUL_HM-Devices unter VCCU als Voraussetzung). Threads zu Antennenmods gibt es ja, da kannst du dich orientieren.
Zitat von: Beta-User am 21 Dezember 2017, 12:39:22
Gibt auch eine Platine von amunra, auf die man das mit einem FTDI verlöten kann.
Was das elektrische Layout angeht, kannst du dich auch an der orientieren - der FTDI liefert nur 40mA (?). Ich habe damals "auf die Schnelle" das Ding für den Einsatz im Pi zusammengelötet, dabei aber nur die PINS verlötet, die notwendig waren, daher nutze ich halt das ELV-Board. Wenn es aber um eine "neue, saubere" Lösung geht, würde ich das nicht mehr unbedingt so machen (wobei es andererseits auch nicht wirklich stört), weil man das Ding ja auch am Pi an USB betreiben kann (hatte ich nach dem Versterben der TV-Box übergangsweise so).
Vielen lieben Dank für Deine schnelle Antwort. Das hilft mir sehr und macht mir Mut.
Dann kann ich das Antennenthema, wie sinnvoll vorgeschlagen, nach hinten schieben, sehr schön.
Zweiter IO:
Meiner Meinung, der MAX Cube ist für den aufgerufenen Preis (39 Euro), geflasht mit Culfw, ein super CUL/CUN, günstig, nettes Gehäuse und flexibel einsetzbar. Im Moment hätte ich noch einen solchen culfwCube hier (und damit schon einige Erfahrungen mit FHEM/MAX sammeln können). Diesen Cube würde ich aber wieder ggf. an einen Freund abgeben, wenn ich ihn nicht wirklich brauche.
Macht ein separater Cube-CUL/CUN Sinn, wenn ich im Moment nur Homematic verwende (ggf. als Analyse-Tool, andere Gründe)?
Oder meinst Du, ein "zweiter IO" für andere Protokolle/Geräte?
Sorry, beí Deiner zweiten Antwort hinsichtlich "elektrisches Layout" habe ich nicht so recht verstanden, was Du mir damit sagen willst.
Ich habe nun in den techn. Daten gesehen, dass das HM-MOD-RPI-PCB maximal 50mA benötigt (wer lesen kann...), klar nix für FTDI aber für den CP2102 perfekt (wie bereits von Dir getestet und bestätigt).
Ich würde somit den ELV UM2102N USB-Seriell-Wandler mit dem HM-MOD-RPI-PCB testen (und berichten), das ganze in ein kleines Kunststoffgehäuse und die Antenne durch ein Löchlein nach außen führen.
Spräche etwas gegen diese Vorgehensweise?
Um dem Themenersteller wieder nahe zu kommen und eine wichtige Frage:
Wenn ich den USB-Seriell-Wandler mit dem HM-MOD-RPI-PCB einsetze, muss man die CoreFreqenz des RaspberryPI oder anderer Boards (Odroid XU4) NICHT fixieren?
Das war irgendwie noch nicht so klar beantwortet, wie ich glaube. Das wäre bei einem Odroid XU4 schon sehr unangenehm, da der im Idle (ondemand) nur 2,9W benötigt, mit fixierter CoreFreq (performance) 15W.
Welchen Grund hat diese Fixierung der CoreFreq beim Raspberry PI3? Liegt das an der "crapy" Hardware des Raspberry und dessen UART-Anbindung?
@Gluon
Sorry, aber zum Thema Taktung habe ich meine Kenntnisse bereits dargetan, auch der hp regelt den Takt übrigens runter... Die ebenfalls runtertaktende TV-Box nutzt - soweit mir bekannt - in etwa denselben Prozessor wie der Odroid - deswegen hatte ich das ja so getestet ;) . (40 Euro für 2 GB RAM+8GB eMMC-ROM sah lukrativ aus - siehe Thread in Server-Hardware). Aber nochmal ausdrücklich und in aller Klarheit: Ich habe das Runtertakten NICHT ausgeschaltet.
Ein 2. IO war für HM gemeint, aber ich hatte über 2 Jahre "nur" einen CUL. Also: Cool bleiben, testen, dann ggf. was anderes zusätzlich nehmen (z.B. den Cube, das PI-Modul an ser2net oder einem ESP oder einem MapleCUN oder...). Das eilt eher auch nicht! Was du mit dem Cube machst, bleibt deine Entscheidung...
Du hattest gefragt, ob die 100mA ausreichen. Das war mit elektr. Layout gemeint.
Ansonsten solltes du - nach meinem ganz persönlichen Geschmack - mal anfangen, das eine oder andere "auf Risiko" einfach mal zu machen. Letztendliche Sicherheit (bzw. mehr als ein abgesichertes gutes Gefühl) wird es in den seltensten Fällen geben, aber viel Schiefgehen dürfte auch nicht...
Schöne Weihnachten,
Beta-User
Nochmals lieben Dank für die erneute Klarstellung, jetzt habe ich es verstanden.
Meine Erfahrungen mit dem ELV CM2102N USB-Seriell-Wandler werde ich hier berichten, wenn hoffentlich alles klappt.
Schöne Weihnachten
Gluon
Der FTDI liefert nur 50mA dies ist für den HM-MOD-RPI-PCB grenzwertig. Wenn der HM-MOD-RPI-PCB mit einem 3,3V Spannungsregler versorgt wird, kann auch der FTDI verwendet werden
https://forum.fhem.de/index.php/topic,56606.msg601617.html#msg601617
Ich habe hier mal die Schaltungsvarianten aufgezeichnet:
https://forum.fhem.de/index.php/topic,69042.msg605241.html#msg605241
Gruß Ralf
Das mit den 50mA FTDI und den 100mA beim CP2102 von Beta-User hatte ich schon in dem Monsterthread (irgendwo) gelesen (das hattest Du schon dort geschrieben, glaube ich).
Ich hatte nur die Leistungsangabe in den technischen Daten des HM-MOD-RPI-PCB übersehen und war unsicher. Testen ist schon ok, aber ich will hier eben nicht HW bestellen, die sich dann als sinnlos herausstellt, weil es eine bessere Lösung gäbe, das wäre rausgeworfenes Geld.
Genial die Zusammenstellung. Vielen Dank.
@Beta-User
Ich muss hier wirklich die Antworten mehrfach und ganz genau lesen - aber so soll es sein (oder ich bin eben nicht der Schnellste, kann natürlich auch sein).
Der Hinweis auf ser2net ist super. Ich werde ohnehin zwei USB-HM-MOD-RPI-Module aufbauen.
Ich habe noch einen etwas betagten Raspberry PI 1 B hier, der könnte doch mit ser2net + HM-MOD-RPI-PCB (USB) sozusagen als HM-LAN-Adapter dienen?
Verstehe ich das richtig?
Dann würde der gute alte (ein bisschen langsame) RasPI1 doch noch irgendwann eine sinnvolle Anwendung finden.
Ist doch immer schade, wenn die HW ungenutzt bleibt.
Problem? Der Raspi teilt sich Ethernet und USB auf einem Port. Das könnte zu Problemen führen (Timing).
Dann in diesem Fall möglicherweise doch den Raspi-UART verwenden.
Zitat von: Gluon am 22 Dezember 2017, 11:01:24
@Beta-User
Ich muss hier wirklich die Antworten mehrfach und ganz genau lesen - aber so soll es sein (oder ich bin eben nicht der Schnellste, kann natürlich auch sein).
Der Hinweis auf ser2net ist super. Ich werde ohnehin zwei USB-HM-MOD-RPI-Module aufbauen.
Ich habe noch einen etwas betagten Raspberry PI 1 B hier, der könnte doch mit ser2net + HM-MOD-RPI-PCB (USB) sozusagen als HM-LAN-Adapter dienen?
Das mit dem mehrfachen Lesen geht mir hin und wieder auch so...
ser2net habe ich selbst nicht getestet. Dem Vernehmen nach müßte das aber auch mit jedem Pi gehen, und so viele Daten sind es ja nicht, die über USB gehen. Wäre nicht meine Lösung, weil ich die Zahl der Geräte, die man warten muß (SW-updates) gerne klein halte. Persönlich würde ich daher eher zu einer Maple+Ethernet-Lösung greifen.
Alternative: manche Router können auch ser2net (ich habe das an einem DD-WRT-Gerät versucht, dann aber nicht weiter vertieft, weil das eine HMUART-Modul so gut performt hat).
Vor einem Pi würde ich vermutlich sogar zu einer ESP-Lösung greifen, obwohl ich die Teile eigentlich auch lieber meide.
Aber auch zu diesen Themen ist an anderer Stelle sehr viel zu finden. Testen wäre angesagt ;) . Oder das Nachhaken bei den betreffenden Threads.
Zitat von: Gluon am 22 Dezember 2017, 09:52:38
Welchen Grund hat diese Fixierung der CoreFreq beim Raspberry PI3? Liegt das an der "crapy" Hardware des Raspberry und dessen UART-Anbindung?
Hi,
soweit ich weiß, ist die Hardware des Pi3 zu den Vorgängern so verändert, dass die UART Taktrate direkt von der Corefrequenz abgeleitet wird. Deswegen muss man sie festlegen.
Das hat was mit der Anbindung des Wlan/Bt Chips zu tun.
https://www.raspberrypi.org/documentation/configuration/uart.md
Das mit dem Pi als "HMLAN" geht auf alle Fälle, aber da kannst Du ja das Modul auch auf die GPIO stecken.
Es geht auch "Wlan-HMLAN" mit einem ESP Baustein und ESP-Link drauf.
Gruß Otto
@Otto:
Interessanter Hinweis auf dei Hintergründe zu dem Taktungsthema, Danke.
[OT]
Demnach wäre auch an einem Pi3 eigentlich die Adaption via USB die "bessere" Variante, wenn man der CPU eine dynamische Taktung erlauben will, oder?
(Ich habe nie in einen Pi3 investiert, das mit den vielen unnötigen Schnittstellen war mir - neben dem unsäglichen SD-Karten-Geschreddere, das man hier bei allen Pi-Varianten leider immer wieder beobachten kann - immer suspekt)
[/OT]
Sehr gute Info, Otto. Lieben Dank. Das mit dem ESP-WLAN-Modul (und LAN-Serial-Modul) habe ich auch schon gelesen und auch Deine Fotos dazu gesehen, schick und sehr interessant.
Natürlich kann ich das Modul direkt auf den GPIO meines guten alten RasPI 1 stecken.
Der kleine Vorteil des ELV UM2102N ist, dass er eine MiniUSB-Buchse hat. Somit kann ich das Modul vom Steuerrechner ein wenig absetzen (2 bis 3 Meter, je nach USB-Kabel). Das ist aber vielleicht nur für mich interessant, aufgrund meines Aufbaus/Örtlichkeiten.
Na, dann habe ich ja einiges vor mir.
Schöne Weihnachten und herzliche Grüße
Gluon
Hi,
OT:
ich habe den Pi in allen Varianten, B B+ B2 B3 ZERO-Wlan und noch keine defekte SD Karte - toi toi toi ;D
Es ist grundsätzlich immer gut das HM Funkmodul von anderer Elektronik zu entfernen. Empfang ist das Eine, Störung das Andere was die resultierende Qualität beeinflusst. Wobei ich allgemein finde, das HM-MOD-RPI-PCB Modul ist unkritisch im Einsatz und hat gute Empfangs und Sendeleistung.
Wenn man das Modul am USB betreibt, hat dies auch den Vorteil das man sich nicht mit dem Umswitchen des BT Moduls usw. befassen muss. Das Thema ist aus meiner Sicht zwar ganz einfach, aber bei vielen läuft dies total daneben. :-[
Wenn man es am Wlan betreibt muss man gut testen wie "gut" das eigene Wlan ist. Ich bin dabei auf das echt schlechte Wlan der fritzbox aufmerksam geworden.
Schöne Weihnachten
Otto
Zitat von: Otto123 am 22 Dezember 2017, 11:31:24
Hi,
soweit ich weiß, ist die Hardware des Pi3 zu den Vorgängern so verändert, dass die UART Taktrate direkt von der Corefrequenz abgeleitet wird. Deswegen muss man sie festlegen.
Das hat was mit der Anbindung des Wlan/Bt Chips zu tun.
https://www.raspberrypi.org/documentation/configuration/uart.md
Das gilt aber doch nur, wenn man den Raspi eigenen UART benutzt. Wenn man das Modul über WIFI (z.B. dem ESP) oder über USB (z.B. CP2101) anbindet, dann gilt das nicht, oder?
Ansonsten gilt das was im Wiki Artikel steht, richtig?
Was die SD-Karte angeht, ich hatte schon eine kaputte. Nun habe ich FHEM über eine SAMBA Freigabe eingebunden. Die Daten liegen auf meinem NAS. Nachteil: mir ist es noch nicht gelungen, dass FHEM automatisch beim Booten vom Raspi startet, weil die Freigabe nicht schnell genug eingebunden ist. https://forum.fhem.de/index.php/topic,81444.msg735406.html#msg735406 (https://forum.fhem.de/index.php/topic,81444.msg735406.html#msg735406)
Vielen Dank!
GRüße Martin
Hallo Martin,
das Zitat von mir bezieht sich nur auf die ursprüngliche Verwendung des Modul am GPIO Stecker des Pi3 und sicher auch den Zero Wlan!
Es bezieht sich auch nicht auf die ursprüngliche Verwendung am Pi B B+ oder B2.
In allen anderen Fällen wird der Takt der UART ja von dem Baustein bestimmt der die UART bereitstellt und hat nichts mit dem FHEM Server zu tun.
Gruß Otto
Super, Danke, so habe ich es auch verstanden! Das steht halt nicht in dem Wiki Beitrag. Das werde ich so nun in Angiff nehmen.
Schöne Weihnachten.
Unglaublich, Freitag bestellt, Samstag geliefert. Ich hatte nicht damit gerechnet.
Beide Module funktionieren am RasPI. ELV UM2102N USB-seriell-Wandler verbaue ich heute.
Frage zur Firmware:
Das Flashen der 1.4.1 mittels FHEM hat sehr gut funktioniert, tolle Sache.
Im Wiki und überall sonst steht immer nur die 1.4.1.
Im Wiki wird die "aktuelle" Firmware angesprochen, aber keine Empfehlung gegeben.
Die aktuelle Firmware zum HM-MOD-RPI-PCB ist 2.2.xx.
Soll man nun die 1.4.1 einsetzen oder besser die aktuelle Firmware.
Ich habe irgendwo gelesen, dass die 2er Firmware nur für den CCU-Virtualisierer (Raspimatic) geeignet ist, da dieser diese Firmware automatisch installiert. Selbst für YAHM soll man die 1.4.1 installieren. Ich bin mir aber nicht sicher, ob diese Informationen veraltet sind.
Ich habe die letzten zwei Wochen mit MAX+FHEM "gespielt", und einiges gelernt, obwohl ich natürlich noch Anfänger bin. Homematic ist noch wesentlich komplexer, aber ich würde derzeit gerne auf pures FHEM mit VCCU (habe ich durchgelesen, geniale Sache) setzen. Eine CCU-Lösung (z. B. YAHM) würde ich nur einsetzen wollen, wenn ich auf Dauer mit Homematic+FHEM nicht klar kommen sollte.
Welche Firmware für das HM-MOD-RPI-PCB ist für welchen Einsatz optimal?
Das wäre evtl. auch gut für das Wiki, wenn es hier wichtige Empfehlungen gibt.
Frohe Weihnachten
Gluon
Die versprochene Rückmeldung:
ELV USB-Seriell-Adapter ELV UM2102N (ELV USB-Modul UM2102N, Komplettbausatz) funktioniert.
Beide meine damit ausgerüsteten HM-MOD-RPI-PCB melden sich, auch mit unterschiedlicher D-HMIdOriginal, STATE: opened, cond: ok.
Eine Aufklärung hinsichtlich der zu verwendenden Firmware, je nach Einsatzfall (1.4.1 oder aktuell, siehe mein letzter Post) wäre noch erhellend.
Danke und schöne Weihnachten
Gluon
Wenn's tut: lass es wie es ist....
Die 1.4.1 ist jedenfalls nicht als buggy bekannt ;)
Also ich habe noch nix von neuer Firmware gelesen und würde es mit der 1.4.1 belassen solange wie Michael in seinem Thread (https://forum.fhem.de/index.php/topic,54511.0.html) was anderes meldet.
Schöne Weihnachten
Otto
Vielen Dank Ihr beiden. Das hilft, somit kann ich das auch abhaken.
Schöne Weihnachten
Gluon
Hallo zusammen,
Kann man diesen USB seriell Wandler nehmen?
https://m.ebay.de/itm/USB-2-0-CH340G-TTL-Konverter-Adapter-CP2102-PL2303-UART-FTDI-Arduino-5V-3-3V/252713824136 (https://m.ebay.de/itm/USB-2-0-CH340G-TTL-Konverter-Adapter-CP2102-PL2303-UART-FTDI-Arduino-5V-3-3V/252713824136)
Da fehlt mir der Reset pin. Oder ist der nicht nötig?
Grüße Martin
Für das HM-MOD-RPI-PCB wird 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.
Hallo Martin,
es ist auch eine Frage des Stromes am 3,3 Volt Pin. Da weiß ich gerade nicht wieviel der CH340 liefert.
Edit: Gerade im Datenblatt gesehen, der liefert gar nix. Dann muss der Adapter das extra machen, keine Ahnung wie. Nimm lieber einen mit CP2102 Chip
FTDI wie einen Beitrag später empfohlen liefert zu wenig Strom!
Gruß Otto
Zitat von: maddinthebrain am 30 Dezember 2017, 10:41:59
Kann man diesen USB seriell Wandler nehmen?
https://m.ebay.de/itm/USB-2-0-CH340G-TTL-Konverter-Adapter-CP2102-PL2303-UART-FTDI-Arduino-5V-3-3V/252713824136 (https://m.ebay.de/itm/USB-2-0-CH340G-TTL-Konverter-Adapter-CP2102-PL2303-UART-FTDI-Arduino-5V-3-3V/252713824136)
Da fehlt mir der Reset pin. Oder ist der nicht nötig?
Der Reset-Pin ist für Deinen Einsatzzweck glaube ich eh nicht notwendig. Mit diesem Adapter kannst Du Meines Wissens den HM-MOD-RPI-PCB nicht direkt mit Spannung versorgen. Andere Adapter, z.B. dieser (https://www.ebay.de/itm/USB-TTL-Konverter-Adapter-Modul-PL2303-UART-RS232-Arduino-PL2303HX/252852933050), bieten direkt 3.3/5V zum abgreifen. Allerdings weiß ich nicht, wie gut der PL2303 Chipsatz von Linux/FHEM unterstützt wird.
Dieser hier (http://www.ebay.de/itm/FT232RL-FTDI-USB-auf-TTL-Serien-Converter-Adapter-Modul-3-3V-5V/182897202460) sollte auf jeden Fall funktionieren, ist aber nur Mini-USB und daher nur mit Kabel am USB-Port zu betreiben.Edit: dass der FTDI zu wenig Strom liefert war mir nicht bekannt. Dann bleibt wohl nur der von Gluon empfohlene Adapter, gibt es wohl auch mit USB-Stecker: https://www.ebay.de/itm/CP2102-6-Pin-USB-2-0-nach-TTL-UART-serial-serieller-Konverter-Kabel-Arduino/112277718377 (https://www.ebay.de/itm/CP2102-6-Pin-USB-2-0-nach-TTL-UART-serial-serieller-Konverter-Kabel-Arduino/112277718377)
Wie auch Otto schon geschrieben hat, FTDI funktioniert nur mit externer, zusätzlicher Stromversorgung (3.3V Spannungsregler).
Du musst bei den Angeboten aufpassen. Dort werden oft nur die Suchbegriffe genannt, damit sie gefunden werden. Das heißt nicht, dass das Modul auch tatsächlich den entsprechenden Chipsatz hat.
Auch wenn es ein paar Euro mehr kostet, verwende ein Modul, das definitiv einen CP2102 verwendet, dann sollte es problemlos funktionieren.
Das ELV-Modul UM2102N (knapp 6€) funktioniert bei mir perfekt. Es hat aber auch "nur" einen Mini-USB-Anschnluss, Du benötigst ein zusätzliches USB-Kabel (2,95€ bei ELV). Ich empfinde das als Vorteil, da man das Modul vom Steuerrechner absetzen kann. Bei mir bringt das ca. bis 5 dB (RSSI) gegenüber einer direkten Montage auf dem RasPI.
Edit: Das ELV-Modul UM2102N wird komplett montiert geliefert (fertig). Man müsste nur eine Stiftleiste (nicht enthalten) bestücken, die man aber für den Anschluss des HM-MOD-RPI-PCB ohnehin nicht benötigt.
Zitat von: Otto123 am 30 Dezember 2017, 10:59:19
Edit: Gerade im Datenblatt gesehen, der liefert gar nix. Dann muss der Adapter das extra machen, keine Ahnung wie.
Der CH340G-TTL-Konverter-Adapter liefert keine 3,3V. Der 3,3V Pin ist für den Jumper gedacht um zwischen 5V und 3,3V Pegel zu wechseln.
Gruß Ralf
Ich habe mir mal den Schaltplan angesehen http://nicecircuits.com/ch340g-usb-to-rs232-ttl-module-schematic-d-sun-v3-0/ (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
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.
@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
Das ist mal eine klare Antwort! Super Dankeschön! :) genau das wollte ich ja auch wissen.
Vielen Dank.
Grüße Martin
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
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
Hallo Mark,
sieht aus einer Sicht aus, als ob da kein Modul am USB1 ist. Sicher mit USB1?
Gruß Otto
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
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
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
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
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@115200Viele 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.