Hallo zusammen,
ich habe den HM-MOD-UART auf einen USB-TTL Wandler gelötet. TX-RX sind verdraht verkabelt so wie in der Anleitung beschrieben, 50V 10uF Stützkondensator ist auch aufgelötet.
Den USB-TTL habe ich vorher gemessen, waren 3,3V was rauskamen am 3,3V Pin und bei RX/TX.
Das Modul ist in FHEM eingerichtet, das Firmwareupdate lief fehlerlos (ohne FHEM) durch. Leider springt der Status immer zwischen "opened" und "disconnected" hin und her.
Cond wechselt zwischen "init" und "disconnected", LoadLvl "Suspended".
Hat jemand eine Ahnung woran das liegen kann?
Hi,
da ich das bisher noch nicht getestet hatte, habe ich das jetzt mal gemacht:
FTDI Adapter (ist eigentlich nicht so gut, liefert wenig Strom bei 3,3 Volt)
Das RPI Modul. https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
4 Drähte - nur gesteckt
GNG - GND
3,3 - 3,3
RX - TX
TX - RX
Geschaut welche Schnittstelle ist es?
lsusb
ls -l /dev/serial/by-path/
in Fhem definiert
define HMUART1 HMUARTLGW /dev/ttyUSB0
Funktioniert wunderbar.
Kannst Du ein Bild vom Modul posten?
Gruß Otto
Sobald ich wieder zu Hause bin, gerne. Allerdings ist mir aufgefallen, der HM meldet sich als ttyUSB0, by-id als Siliconlabs irgendwas CP1202 Port 00. Das identisch mit meinem proteco (oder wie das heißt). Das ist ein Ultraschall Füllstand messer fürnÖltanks. Ebenfalls mit CP1202. Wenn die sich identisch anmelden könnte das schon Probleme geben oder?
Wenn die "by-id" definiert sind: Ja.
Im Wiki gibt es einen Artikel zum CP2102 samt link zu einem Tool, mit dem man den Teilen eindeutige Kennungen verpassen kann ;) . (Steht da vermutlich nicht ganz umsonst ;D ::) 8) ).
Naja wenn die identisch sind dann bei by-path nehmen.
Oh, cool da schau ich dann Mal nach
Zitat von: Otto123 am 02 Oktober 2019, 15:14:48
Naja wenn die identisch sind dann bei by-path nehmen.
Das geht selbstredend auch, hat aber den Nachteil, dass es einen "Systemumzug" nicht überlebt (oder ein schlichtes Umstöpseln). Es ist daher m.E. zielführender, das Problem an der Wurzel zu packen und die Dinger umzuprogrammieren, dann hat man damit endgültig Ruhe und muß erst beim "übernächsten" wieder ran ;) .
Das Tool selbst ist etwas gewöhnungsbedüftig, weil nicht ausladend dokumentiert, aber an sich kein großer Akt. Bei den CP2102's, die ich bisher in den Fingern hatte, ist auch nie was schiefgegangen; das waren zwar nur knapp 10 Stück, die aber aus diversen China-Quellen (einschließlich falsch verdrahteter Mini-Platinen).
So gerade zu Hause angekommen. HM-MOD neu angelegt mit /serial/by-path, dabei ist der HM-MOD das einzige angeschlossene USB - USB/Serial Gerät.
Immer noch das gleiche, wenn auch nicht mehr so häufig von "init" zu "disconnected" gewechselt wird.
Hier mal das List vom Gerät:
Internals:
CFGFN
CNT 2
Clients :CUL_HM:
DEF /dev/serial/by-path/platform-3f980000.usb-usb-0:1.1.3:1.0-port0
DEVCNT 1
DevState 1
DevType UART
DeviceName /dev/serial/by-path/platform-3f980000.usb-usb-0:1.1.3:1.0-port0@115200
FD 11
FUUID 5d94b3d9-f33f-47f9-7587-056ca96d2cece487
LastOpen 1570026531.18734
NAME HM_MOD
NOTIFYDEV global
NR 665
NTFY_ORDER 50-HM_MOD
PARTIAL fd5f417070d831
RAWMSG 0402436F5F4350555F417070
STATE opened
TYPE HMUARTLGW
XmitOpen 0
model HM-MOD-UART
Helper:
AckPending:
2:
cmd 03
dst 0
frame FD00030002039409
resend 3
time 1570026532.23149
LastSendLen:
3
3
Log:
IDs:
RoundTrip:
MatchList:
1:CUL_HM ^A......................
Peers:
READINGS:
2019-10-02 16:27:37 D-type HM-MOD-UART
2019-10-02 16:28:52 cond init
2019-10-02 16:27:37 loadLvl suspended
2019-10-02 16:28:51 state opened
Attributes:
Und das Bild vom UART-TTL:
Also mit dem cp210x-programmer hab gerade noch etwas zu kämpfen. Musste Syntax Änderungen (except ValueError, err -> except ValueError as err) beseitigen. Jetzt wird das Modul ConfigParser nicht gefunden obwohl installiert (pip3).
Auf was für einem System (OS)? Hatte das immer mit dem Laptop unter Kubuntu (tendenziell 18.04) gemacht, ist aber schon eine Zeit her...
Was das Teil als "einzigem" USB-Gerät angeht: ist der Dienst aktiv bzw. die Definition, der/die auf den anderen zeigt?
Also
from configparser import ConfigParser
Muss es nun korrekt heißen. Die anderen imports laufen nicht weniger holprig. Ein ganzes Verzeichnis wird importiert, das "Values" wird aber nur in der ersten py datei gesucht....
Derzeit auf meinem PC Manjaro 18.x
Auf dem Raspi ist Stretch... Das Tool ist aber in Python 2 geschrieben, ich bin bei 3.7 und hab bei 3.4 glaub ich mit Python angefangen...
Zitat von: Beta-User am 02 Oktober 2019, 17:21:32
Auf was für einem System (OS)? Hatte das immer mit dem Laptop unter Kubuntu (tendenziell 18.04) gemacht, ist aber schon eine Zeit her...
Was das Teil als "einzigem" USB-Gerät angeht: ist der Dienst aktiv bzw. die Definition, der/die auf den anderen zeigt?
Ja, die Def in FHEM ist weiterhin angelegt, was anders greift darauf nicht zu.
Hmm, bei mir war auch mal python 2.7 bereits installiert, vermutlihc war das deswegen kein Problem. Kurz gesucht, daher ungetestet, aber in C: https://github.com/DiUS/cp210x-cfg
Was die Definitionen angeht: Wenn nur eine angelegt ist, dann ist das Verhalten komisch; könnte allenfalls noch ein Stromproblem sein (Pi und USB-Strom-Versorgung sind zwei Dinge, die nicht gut zusammengehen...)
Naja insgesammt sind es 2 defs. eine by-id die andere by-path. Die CULs haben alle samt keine Probleme mit Strom... mal gucken vielleicht löte ich alles nochmal sauber.
Ich verstehe es nicht. Man kann mit vier Drähten stecken, das Teil erst mal probieren. Stattdessen wird erst mal gelötet und umgeflashed. Völlig falsche Prioritäten :(
Ich bin der Meinung, die Verdrahtung kann nicht stimmen. Aber wirklich gut sehen kann man es nicht. Bitte kontrolliere das nochmal.
Gruß Otto
Die Anleitungen dazu sind ja eindeutig. Die Verkabelung ist 3.3V auf 3.3V GND auf GND TX auf RX und RX auf TX. Ein erster Test, ob die Dinger überhaupt tun würde mit Steckkabeln gemacht. Allerdings ohne Einbindung in fhem. Im Wiki steht man soll die Firmware 1.4 nutzen da die vorinstallierte 1.2 nicht taugt, nur darum habe ich es gemacht! Am der Verkabelung liegt das Problem sicher nicht, am Löten eher unwahrscheinlich, defekter HM-mod ehr nicht, minderwertiger USB -> TTL möglich, hab noch einen den kann ich testen. Ansonsten alles nach Anleitung und es geht halt nicht. Das tolle ist, dass einige Geräte nun nichtmal mehr auf den CUL hören. Wenn ich das wieder Hingebogen habe bleibt das so wie es ist. Hat mit CUL lange funktioniert bis auf die zickigen FKs (für die Hilfe dabei bin ich dankbar).
Naja mich wundert irgendwie, dass der 3,3 Volt Anschluss vom USB Wandler an der gegenüberliegenden Seite wie der VCC Anschluss vom Modul ist. aber wie gesagt ich kann es nicht erkennen. Woher weisst Du denn welche Firmware auf dem Modul ist?
Hast Du denn die UART Schnittstelle auf dem Pi "freigemacht"? Der Pi Zero hat doch sicher Wlan/Bluetooth
Sorry falscher Gedanke ...
Gruß Otto
Das ist ein Knackpunkt, ich bin einfach davon ausgegangen, dass auf dem Modul fw 1.2 drauf ist weil es so im Wiki stand. Ich werde später erstmal den anderen Wandler testen, vielleicht sind auch nicht gut, waren auch sehr billig...
Naja diese Erkenntnis mit der Auslieferung der Firmware ist jetzt ein paar Jahre alt. Aber ich weiß auch nicht ob elv da wirklich was geändert hat oder nach wie vor die alte Firmware ausliefert.
Man muss halt als erstes schauen wie es ist.
Ob die Wandler billig sind oder nicht spielt eigentlich keine Rolle. Die FTDI Adapter liefern wenig Strom, aber ich habe getestet es reicht ja offenbar. Bei den CP Adaptern gibt es welche die sind falsch beschaltet und liefern deshalb keine 3,3 Volt sondern irgendwas um die 4 Volt. Die sind eventuell kritisch.
Leider hat noch niemand einen einfacheren Weg gefunden die Kommunikation mit dem Modul zu testen, als es einfach anzustöpseln und in FHEM zu definieren. Nach dem Löten ist die Fehlerquote hier im Forum deutlich erhöht :)
Ok, ich hatte das Modul erst so dran, und aufgrund der Probleme dann halt die fw geflasht.
Habe jetzt des 2. Wandler getestet, frische Kabel mit Steckern an das HM-mod gelötet und auf den CP gesteckt - Polung identisch, mit Stützkondensator.
Die 3,3V sowie TX und RX Ausgänge habe ich gemessen: 3,35V
Eingesteckt, mit:
attr VCCU IOList CUL_1,HM_MOD
hinzugefügt und keine 2 Minuten später hm-info rssi:
rssi done:
Device receive from last avg min_max count
HM_Badezimmer CUL_1 HM_Badezimmer -78.0 -78.0 -86.0< -66.5 60
HM_Badezimmer HM_Badezimmer CUL_1 -69.0 -70.6 -75.0< -66.0 7
HM_Badezimmer HM_MOD HM_Badezimmer -44.0 -44.0 -44.0< -44.0 1
HM_Esszimmer CUL_1 HM_Esszimmer -70.5 -66.6 -70.5< -61.5 51
HM_Esszimmer HM_Esszimmer CUL_1 -60.0 -60.0 -60.0< -60.0 1
HM_Esszimmer HM_MOD HM_Esszimmer -42.0 -42.0 -42.0< -42.0 1
HM_Flur CUL_1 HM_Flur -54.0 -58.3 -65.0< -54.0 68
HM_Flur HM_Flur CUL_1 -51.0 -51.4 -55.0< -49.0 13
HM_Flur HM_MOD HM_Flur -45.0 -45.0 -45.0< -45.0 1
HM_Kinderzimmer CUL_1 HM_Kinderzimmer -64.0 -67.6 -76.5< -63.0 52
HM_Kinderzimmer HM_Kinderzimmer CUL_1 -62.0 -62.0 -62.0< -62.0 1
HM_Kinderzimmer HM_MOD HM_Kinderzimmer -48.0 -48.0 -48.0< -48.0 1
HM_Kueche CUL_1 HM_Kueche -78.5 -72.6 -81.0< -69.0 50
HM_Kueche HM_Kueche CUL_1 -63.0 -63.0 -63.0< -63.0 1
HM_Kueche HM_MOD HM_Kueche -53.0 -53.0 -53.0< -53.0 1
HM_Schlafzimmer CUL_1 HM_Schlafzimmer -70.0 -67.7 -70.5< -66.0 57
HM_Schlafzimmer HM_MOD HM_Schlafzimmer -70.0 -70.0 -70.0< -70.0 1
HM_Schlafzimmer HM_Schlafzimmer CUL_1 -61.0 -62.0 -63.0< -61.0 3
HM_Wohnzimmer CUL_1 HM_Wohnzimmer -59.0 -56.7 -67.0< -51.5 74
HM_Wohnzimmer HM_MOD HM_Wohnzimmer -33.0 -33.0 -33.0< -33.0 1
HM_Wohnzimmer HM_Wohnzimmer CUL_1 -50.0 -51.4 -60.0< -49.0 11
essz_fensterkontakt CUL_1 essz_fensterkontakt -83.5 -82.8 -83.5< -81.5 3
essz_fensterkontakt HM_MOD essz_fensterkontakt -76.0 -76.0 -76.0< -76.0 1
kueche_fensterkontakt CUL_1 kueche_fensterkontakt -93.0 -87.2 -93.0< -83.0 3
kueche_fensterkontakt HM_MOD kueche_fensterkontakt -68.0 -68.0 -68.0< -68.0 3
kueche_fensterkontakt2 CUL_1 kueche_fensterkontakt2 -85.5 -86.2 -87.0< -85.5 2
schlfz_fensterkontakt CUL_1 schlfz_fensterkontakt -76.5 -77.0 -77.5< -76.5 2
Fazit: der erste USB-TTL Wandler hat ein Problem. Kann man die FW vom Modul irgendwie auslesen?
P.S.: FW wird als Reading angzeigt, wenn man kurz wartet. Ist (ohne flashen) 1.4.1
P.P.S.: Der zickige Fensterkontakt ist nun auch gepairt.
Na das freut mich jetzt!
ZitatFazit: der erste USB-TTL Wandler hat ein Problem.
Saubazi der Wandler. Nach Prfiemlers Motto "geht nich gips nich" oder gips nich gips nich :'(
Schönen Feiertag
Otto
Und mich erst!
ein configChk liefert jetzt endlich:
configCheck done:
Ebenfalls einen schönen Feiertag!
Zitat von: Otto123 am 03 Oktober 2019, 10:26:28
Aber ich weiß auch nicht ob elv da wirklich was geändert hat oder nach wie vor die alte Firmware ausliefert.
Ich hatte vor einem Monat gekauft und habe tatsächlich die alte Version 1.2 bekommen!
Gesendet von iPad mit Tapatalk Pro
Nachdem es heute Nacht wieder Probleme gab:
2019.10.04 04:08:01 1: /dev/serial/by-path/platform-3f980000.usb-usb-0:1.1.2:1.0-port0 disconnected, waiting to reappear (HM_MOD)
2019.10.04 04:08:04 1: HMUARTLGW HM_MOD did not respond for the 1. time, resending
2019.10.04 04:08:07 3: Setting HM_MOD serial parameters to 115200,8,N,1
2019.10.04 04:08:07 1: /dev/serial/by-path/platform-3f980000.usb-usb-0:1.1.2:1.0-port0 reappeared (HM_MOD)
2019.10.04 04:08:08 1: /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 disconnected, waiting to reappear (proteus_Ecometer)
2019.10.04 04:08:09 3: connected to device /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
2019.10.04 04:08:09 1: /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 reappeared (proteus_Ecometer)
Habe ich das Windows Tool heruntergeladen und die beiden CP2102 umbenannt. Mal schauen ob es jetzt besser wird.
Hier scheint mir das die Mischung zwischen "by-path" und "by-id" gewesen zu sein, die auch für Probleme sorgt. Wenn, sollte man alle "gleichnamigen" mit "by-path" einbinden.
Aber das sollte sich ja jetzt erledigt haben.
Wäre nett, wenn du eine Kurzanleitung für das "Windows-Tool" liefern könntest (das was ich verlinkt hatte, war in C geschrieben, sollte daher "prinzipiell" auf allen OSsen laufen), dann packe ich das für Nachahmer gerne in's Wiki.
Ja das wird es gewesen sein die Probleme tauchten erst in der Nacht nach einem FHEM Neustart auf (Dienst wird für SD-Karten Image beendet), da das andere Device dann abgefragt wurde.
Ich habe das Tool direkt vom Hersteller genommen, das Python Tool für Linux habe ich nicht weiter bearbeitet und das in C geschrieben auch gar nicht angesehen.
https://www.silabs.com/products/development-tools/software/direct-access-drivers (https://www.silabs.com/products/development-tools/software/direct-access-drivers)
Da kann man die "Direct Access Driver Software" runterladen und wie gewohnt installieren.
Das Tool hat nur 1 Fenster mit den Grunddaten PID, VID, Serial und ein par andere. Wichtig ist der String mit "Silicon Labs USB to UART Bridge" und die Serial.
Diesen String habe ich abgeändert und die Serial (bei allen von mir getesteten immer 0001) angepasst.
Dann den Button "Program Device" drücken, kurz warten - fertig.
Wenn Du möchtest könnte ich nochmal Win booten und einen Screenshot machen.
P.S.: Screenshot im Anhang
Thx, das Ändern der Serial/Herstellerangaben sollte auch reichen, PID/VID zu ändern ist sowieso eher nicht zielführend ;D ...
Die Links habe ich ins Wiki gepackt; da die Win-Software eher selbsterklärend zu sein scheint, braucht es m.E. keinen Screenshot (sowas veraltet leider auch, wie Pyton-Versionen usw.).
Werde mal bei Gelegenheit versuchen, das C-Programm zu verdebianen, dann kommt das "ungetestet" im Wiki weg ;D .
Eigentlich hast Du da Recht. Der Link mit dem Hinweis was geändert werden muss sollte schon genügen.