Rasbian 10 (buster): nanoCUL wird nicht erkannt

[demel42]

Problem:
um Hardware-/OS-basierte Problem ausschliessen zu können (siehe #7) habe ich eine Installation auf einem Raps mit buster durchgeführt.
Obwohl der USB-Stick erkannt wurde, steht er nicht als Auswahl in der Web-GUI zur Verfügung. Auch ein manuelle Eintrag in der userdata.json hilft nicht.

Umgebung:

• Raspberry 2+
• Raspbian 10, ganz aktuell
• Einrichtung gemäß Vorlage
• nanoCUL mit aktuellem AskSinSniffer328P-Sketch
• AskSin Analyzer XS hat Version 1.2.0
• node.js ist v10.15.2 (aktuellste zur Verfügung stehende Version)

[ 6664.664660] usb 1-1.2: new full-speed USB device number 5 using dwc_otg
[ 6664.817103] usb 1-1.2: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 6.00
[ 6664.817120] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 6664.817129] usb 1-1.2: Product: FT232R USB UART
[ 6664.817138] usb 1-1.2: Manufacturer: FTDI
[ 6664.817147] usb 1-1.2: SerialNumber: A911B8S3
[ 6664.822979] ftdi_sio 1-1.2:1.0: FTDI USB Serial Device converter detected
[ 6664.823147] usb 1-1.2: Detected FT232RL

analyzer@HomeMatic-ASA:/etc$ ls -l /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 0 Mär 20 19:01 /dev/ttyUSB0

pi@HomeMatic-ASA:~$ sudo journalctl -u analyzer
-- Logs begin at Fri 2020-03-20 19:03:04 CET, end at Fri 2020-03-20 19:06:29 CET. --
Mär 20 19:03:57 HomeMatic-ASA systemd[1]: Started Analyzer for radio telegrams in a HomeMatic environment.
Mär 20 19:04:12 HomeMatic-ASA asksin-analyzer-xs[626]: Data-Path: /opt/analyzer
Mär 20 19:04:12 HomeMatic-ASA asksin-analyzer-xs[626]: Server started on port 8088
Mär 20 19:04:12 HomeMatic-ASA asksin-analyzer-xs[626]: Serving UI from /usr/local/lib/node_modules/asksin-analyzer-xs/htdocs

root@HomeMatic-ASA:~# asksin-analyzer-xs --list-ports
Detected SerialPort: /dev/ttyAMA0 (unknown manufacturer)
Detected SerialPort: /dev/ttyUSB0 (FTDI)
^CPsiTransfer shutting down
root@HomeMatic-ASA:~#

das Kommando bleibt aber anscheinend hängen, ich habe das nach 2m per ^C abgebrochen.

Ich habe dann mal bei dem User analyzer die /bin/bash als Login-Shell eingetragen

root@HomeMatic-ASA:~# su - analyzer
analyzer@HomeMatic-ASA:/$ id
uid=999(analyzer) gid=100(users) Gruppen=100(users),20(dialout)
analyzer@HomeMatic-ASA:/$ minicom -b 57600 -D /dev/ttyUSB0

Willkommen zu minicom 2.7.1

Optionen: I18n
Übersetzt am Aug 13 2017, 15:25:34.
Port /dev/ttyUSB0, 11:16:31

mincom konnte das tty öffnen und es trudelten auch Telegramme ein.

Ws kann ich noch testen?

Gruß
demel

[psi-4ward]

das Kommando bleibt aber anscheinend hängen, ich habe das nach 2m per ^C abgebrochen.

Bug ;) hab ich behoben.

Ansonsten sieht das für mich eigentlich alles korrekt aus.
asksin-analyzer-xs --list-ports erkennt den FTDI als root nicht aber als User analyzer wobei minicom zugreifen kann, sehr komisch.

In der letzten Develop-Version hab ich nun ein hartes Überschreiben des Ports ermöglicht, auch wenn er nicht erkannt wird.

asksin-analyzer-xs --data /tmp/my-data-dir --serial-port /dev/ttyUSB0

[demel42]

Ich habe die aktuelle Dev-version installiert, nun funktionierte die Erkennung des USB-Port.

Ich habe leider auch hier einen Abbruch des Empfangs von Telegramme nach einiger Zeit (wie in #7).
Da das zwei unterschiedliche HW (NUC vs. Raspi 2B+) und OS (Ubuntu 18.04.3
vs. Rasbian 10).
Soweit ich gesehen habe gibt es unter Raspbian kein Powermanagment des USB-Ports.

Das lenkt natürlich den Verdacht von Rechner-HW / OS in Richtung USB-Stick, wobei mich schon wundert, das der der Empfang nach Speichern der (unveränderten) Konfiguration wieder aufgenommen wird. Was passiert in einem solchen Fall im Serverprozess?

Ich habe nun erstmal das USB-Kabel ersetzt und dabei auch die Länge minimiert (30cm).

Einen 2. Stick habe ich natürlich nicht zur Hand, müsste ich mir erst besorgen.

Macht es Sinn, den Output des Stick einfach per minicom oder cu abzugreifen um zu schauen, ob da nach einigen Stunden nix mehr kommt? Müsste ja einfach nix mehr kommen...

[psi-4ward]

wobei mich schon wundert, das der der Empfang nach Speichern der (unveränderten) Konfiguration wieder aufgenommen wird. Was passiert in einem solchen Fall im Serverprozess?

Hier wird im Grund das UART-Device (usb0) neu verbunden da es sich potentiell geändert haben könnte.

Macht es Sinn, den Output des Stick einfach per minicom oder cu abzugreifen um zu schauen, ob da nach einigen Stunden nix mehr kommt? Müsste ja einfach nix mehr kommen...

Ja das wäre mein Vorschlag, Damit du das etwas differenzieren kannst brauchst du iwie noch ne Art Date-Ausgabe, vllt über Bash so

( minicom ..args.. & while true ; do date ; sleep 180 ; done ) | cat

[demel42]

su, ich nahe nun mit minicom protokolliert (Anmerkung: mit CTRL-A N kann man Timestams einschalten und man kann ja alles in ein Logfile protokollieren)

Ich bekommen 1-2x pro Sekunde einen 1-Byte-Wert, Bsp.

:4F;

ab und an gibt es dann längere Zeilen

[2020-03-22 18:08:07] :5F;
[2020-03-22 18:08:08] :431E10008EA4F857BED9C8000099159856FCC5C601325144A43D45591695953F;
[2020-03-22 18:08:08] :2A1714008EBED9C8A4F8570D2C4F42D7EB27F2744CBE30DEFB;
[2020-03-22 18:08:08] :432110088EA4F85797C50C00009916DCC971432B85AC2A66394B4CA5385D1E7107D13D;
[2020-03-22 18:08:08] :291410008EBED9C8A4F8570D2C4F43B0C9F791D7E4C0;
[2020-03-22 18:08:08] :60;
[2020-03-22 18:08:09] :61;

das interpretiere ich als Telegramme.

Aber ... nach einiger Zeit kommen nur noch die kurzen Meldungen, auch wenn definitiv Action los ist.

Es ist also nicht so, das es keine Kommunikation mehr gibt, aber keine Telegramme.

Wenn ich minicom beende, geht's sofort wieder los.

Wenn noch Daten kommen ist der USB-Stick ja nicht funktionslos sein.

Die Software auf dem Stick ist der master-Tree von https://github.com/jp112sdl/AskSinAnalyzer/tree/master/AskSinSniffer328P und gemäß User der-pw den GPIO angepasst. Da wird doch auch kein solcher Fehler drin sein, das wäre doch aufgefallen ...
Aber ein HW-Defekt des Stick ... warum funktioniert er manchmal und manchmal nicht?

Ich habe im Augenblick keine Ahnung ... hast du noch einen Tip für mich?

[demel42]

Der Stick wurde ja nach deiner letzten Änderung erkannt, also ist der Vorgang damit meiner Meinung nach erledigt.
Das Problem mit dem Dauerbetrieb war ein defekter Stick (siehe #7)

danke