[Frage] Fritzbox 7390 – „unbekanntes“ Usb-Gerät — /dev/???

[Herbie_2005]

Hallo.

Ich habe ein Gerät zur Messung der Füllhöhe in einer Zisterne (Proteus Ecometer S). Offenbar lassen sich die ermittelten Werte nicht nur auf den mitgelieferten Bildschirm anzeigen, sondern auch auslesen, wenn man das Gerät nicht einfach an das Original-Netzteil, sondern an einer Rechner anschließt.

Ein vorhandener Linux-Rechner, der immer läuft, ist bei mir die Fritzbox 7390.

Das Auslesen der Werte gelingt in Linux (wohl), wenn man die entsprechende Pseudodatei im Ordner /dev ansteuert.

Bei Bedarf weitere Infos:
> https://www.photovoltaikforum.com/t...?postID=1728688&highlight=proteus#post1728688
> https://forum.iobroker.net/topic/41362/script-umwandeln-für-iobroker

Und hier ist das Problem:

Für die Fritzbox 7390 ist der Füllstandsmesser natürlich ein unbekantes Gerät, es liegt kein Treiber dafür vor.

Frage:

Weiß jemand von Euch, welches in diesem Fall die Pseudodatei /dev/??? ist, die die Fritzbox 7390 für das „unbekannte“ Gerät verwendet?

Ich habe schon gesucht und einiges ausprobiert, aber das richtige scheint nicht dabeigewesen zu sein.

Mit /dev/usb1 und /dev/usb2 jedenfalls hat es nicht geklappt.

 

[PeterPawn]

Der "Name" der Datei ist irrelevant - entscheidend ist, daß diese Gerätedatei mit dem richtigen Treiber "verbunden" wird, was über die "major device ID" erfolgt.

Entweder das Gerät funktioniert tatsächlich mit einem generischen Treiber (um das festzustellen, sollte man zunächst mal PID/VID des Geräts ermitteln, das kann unter einem "richtigen" Linux oder auch unter Windows (im Gerätemanager) erfolgen - die Utilities im FRITZ!OS taugen dafür nur bedingt) oder man muß sich irgendwo einen (für das Gerät passenden/geschriebenen) Treiber suchen. Da geht es dann aber um die richtige Datei (am ehesten ein passender Quelltext für den Treiber, der dann auch wieder passend zum verwendeten Kernel übersetzt werden muß) und nicht um irgendeinen (Geräte-)Namen.

Wenn der richtige Treiber dann geladen wurde (mittels insmod oder modprobe), findet man dessen Major-ID in der Ausgabe von cat /proc/devices und mit dieser ID kann/muß man sich dann eine passende Gerätedatei anlegen (sofern das der udevd nicht automatisch macht), über die man auf das Gerät zugreifen kann. Das oben in #1 Geschriebene versucht also, das Pferd genau von der falschen Seite aufzuzäumen.

 

[Herbie_2005]

Vielen Dank für Deine Antwort, PeterPawn. Mein Problem ist, daß ich keinen Treiber habe und erst recht keinen Quelltext dazu.

Aber so, wie ich die Quellen, auf die ich oben verwiesen habe, verstehe, sollte das Auslesen eines Datenstroms auch so funktionieren, oder nicht?

 

[PeterPawn]

Das hast Du falsch verstanden (zumindest nach meiner Ansicht) ... einen Weg, wie man wenigstens ermitteln könnte, ob es einen generischen Treiber gibt oder nicht, habe ich oben skizziert.

Es wäre zwar denkbar, daß da irgendein "serielles Protokoll" vom Gerät implementiert wird ... aber auch dafür muß man erst mal wissen, ob das tatsächlich der Fall ist und wenn ja, wie das Format aussieht.

Es gibt zwar ein paar Quellen zu den "Proteus Ecometer"-Geräten und deren Datenkommunikation (am besten paßt wohl das hier: https://sarnau.info/communication-protocol-of-the-proteus-ecometer-tek603/), aber ob das für Dein Gerät tatsächlich ebenso ist (es also auch eine USB-Serial-Bridge enthält und diese dann auch mit dem CP210x-Treiber ansprechbar ist: https://github.com/torvalds/linux/blob/master/drivers/usb/serial/cp210x.c), mußt Du schon selbst ausprobieren.

Nur solltest Du das dann eben nicht in der (beschränkten) Umgebung eines "embedded device" wie der 7390 machen (da wird eben üblicherweise nur das an Funktionen/Treibern aktiviert, was auch benötigt wird), sondern erst mal mit einem "erwachsenen" Linux ausprobieren, was da tatsächlich benötigt wird bei der Kommunikation mit dem Monitor-Teil.

Also ja, das Auslesen eines "Datenstroms" KANN funktionieren (wenn E-Sensorix für alle Modelle dasselbe Design nutzen sollte, hilft ja vielleicht schon die von mir verlinkte Seite), aber nicht in der Form, wie Du es oben versuchst ... solange der passende Treiber nicht vorhanden ist oder dieser sich für das Gerät nicht verantwortlich fühlt (vielleicht liest Du mal etwas zu PID und VID beim USB - man kann i.d.R. einen USB-Treiber auch informieren, auf welche (ihm ansonsten unbekannte) PID/VID-Kombination er zusätzlich achten soll), brauchst Du auch keine Gerätedatei, um mit dem Gerät zu kommunizieren.

Beschaffe also erst einmal die PID/VID des Gerätes (wie gesagt, auf einem "normalen" System) und dann kann man sich auf die Suche nach einem Treiber machen, der diese Kombination (von sich aus) unterstützt. Ansonsten bleibt (im "Vertrauen" darauf, daß da auch ein CP2102 "verbaut" ist) noch der Generic-Driver aus dem Kernel (wenn der CP2102 nicht ohnehin eine PID/VID verwendet, die der Treiber bereits enthält) - alles das steht jedenfalls noch zwischen Dir und einem ersten erfolgreichen Auslesen von Daten - sofern Dein "Empfänger" auch tatsächlich über seine USB-Buchse nicht nur die Stromversorgung realisiert, sondern auch noch ein serielles Protokoll bereitstellt, über das man mit dem "Empfänger" kommunizieren kann.

Denn alles andere (u.a. auch die Funkkommunikation mit dem Sensor) wickelt ja diese "Basisstation" (oder auch der "Monitor") für das Gesamtpaket ab ... von einer (offiziellen) Unterstützung anderer Logger ist auch auf der Herstellerseite nichts zu lesen.

 

[Herbie_2005]

Danke für die ausführliche Antwort!

Habe herausgefunden: VID = 10C4; PID = EA60; es handelt sich um einen „CP2102 USB to UART Bridge Controller“.

Mittels

/sbin/modprobe -v usbserial debug=1 vendor=0x10C4 product=0xEA60

habe ich nun erreicht, daß die Pseudodatei /dev/ttyUSB0 angelegt wird. Weiter bin ich noch nicht.

 

[PeterPawn]

Na dann kannst Du ja jetzt versuchen, Daten aus diesem Gerät zu lesen und am besten erst mal irgendwo zu speichern, damit man danach mit einem passenden Programm (z.B. hexdump bzw. od, wenn man's POSIX-kompatibel mag) diese Daten analysieren kann.

 

[Herbie_2005]

Ja, ich probiere gerade mal, mit

tail -f /dev/ttyUSB0

den Datenstrom abzufragen. Ich will mal an der Konsole sehen, ob überhaupt was kommt. Der Ecometer S sendet ja normalerweise nur einmal in der Stunde ein Meßergebnis, wenn ich richtig informiert bin.

 

[PeterPawn]

Ich lasse mich zwar auch überraschen, wenn mit dem tail etwas Sinnvolles zu sehen ist (das müßte ja dann aber schon ASCII-Text sein und das halte ich für unwahrscheinlich), aber ich würde so einen Test eher mit anderen Kommandos, wie z.B. diesem hier:

cat /dev/ttyUSB0 | tee <filename_to_save_data> | hexdump -C

machen und dabei (nach dem Lesen der Schnittstellen-Beschreibung aus dem Link weiter oben) zuvor auch noch per:

stty -F /dev/ttyUSB0 ispeed 115200

dafür sorgen, daß die Schnittstelle auch wirklich auf 115200 Baud eingestellt ist, denn der Standard (läßt sich auch per stty -F /dev/ttyUSB0 -a ermitteln) dürften noch "ganz klassisch" 9600 Baud sein.

 

[Herbie_2005]

Ja, Du hast recht. Den Befehl „stty“ habe ich vorgeschaltet, allerdings läßt die Geschwindigkeit nicht auf 115200 einstellen.

$ stty -F /dev/ttyUSB0 ispeed 115200
stty: /dev/ttyUSB0: cannot perform all requested operations

Und in der Tat sind die Daten, die man „tail“ bekommt, noch kodiert, also erst mal nicht wirklich gut lesbar. Das steht auch in dem Skript, den man im ersten meiner beide Verweise (oben) findet.

EDIT:

Bisher wurden keine Daten ausgegeben. Angeblich soll es ja möglich sein.???