Migration von Fhem

fireball · 08 Mai 2020, 20:42:08

Hi, ich habe einen RP4 + Z-Wave USB Stick Gen5. Das ist ja der Stick, die hier für Zwave mit empholen wurde.

Laut den Links die ich gepostet habt, scheint es da aber hardware probleme seit dem 4er zu geben, zumindest sind die vorher icht aufgefallen...

Ich habs nur noch nicht ganz verstanden, was mit dem Stick nicht iO ist... eine Workaround ist jedenfalls einen USB-Hub dazwischen zu schalten.

VG
René

Wernieman · 08 Mai 2020, 21:03:12

O.K. ... PI4 ...

Du hattest am Anfang aber irgendetwas mit 2 Geredet.

Der PI4 hält sich nicht gaaans an die USB 3 Spezifkationen. Ist also ein "echter" Bug...

fireball · 08 Mai 2020, 21:06:51

Ich bin vom Pi2 gekommen und wollte auf Pi4 migrieren und das war in einer Zeit, da haben scheinbar noch nicht soviel das Thema ausprobiert in Komination mit dem Stick... jetzt nachdem ich das mal ein bisschen schleifen gelassen hatte, habe ich festgestellt, das viele das gleiche Problem haben :/ Schade, naja, son Hub ist ja eigentlich nur ein optisches Problem...

Wernieman · 09 Mai 2020, 17:15:49

Bei der Neustens PI Revision soll der "Bug" behoben worden sein.

Es ist übrigens nicht nur dieser Stick, sondern verschiedene USB-Geräte haben ein Problem damit.

fireball · 17 Januar 2021, 11:39:16

Hi all, hi Beta-User,

ich habe das Thema lange schleifen gelassen, aber wollte den CO2MINI jetzt wieder zum laufen bekommen. Das Teil macht aber seid dem Umzug nur noch zicken... FHEM Integration nach Anleitung funktioniert, einmalig, dann bricht die Verbindung immer wieder ab... Das Modul greift über einen "Server-Software auf den CO2-Sensor zu oder auch direkt... direkt klappt aber auch nicht, da meckert FHEM gleich "error opening /dev/co2mini

Wollte jetzt nochmal schauen, das ich die UDEV-Rules viell umgehen kann und den Vorschlag von Beta-User nehmen kann, stecke ich aber den CO2-Sensor an den PI kommt das:

Code Auswählen

Jan 17 11:16:55 raspberrypi kernel: [52627.872371] usb 1-1.1.3: new low-speed USB device number 6 using xhci_hcd
Jan 17 11:16:55 raspberrypi kernel: [52628.022259] usb 1-1.1.3: New USB device found, idVendor=04d9, idProduct=a052, bcdDevice= 1.00
Jan 17 11:16:55 raspberrypi kernel: [52628.022279] usb 1-1.1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan 17 11:16:55 raspberrypi kernel: [52628.022296] usb 1-1.1.3: Product: USB-zyTemp
Jan 17 11:16:55 raspberrypi kernel: [52628.022361] usb 1-1.1.3: Manufacturer: Holtek
Jan 17 11:16:55 raspberrypi kernel: [52628.022383] usb 1-1.1.3: SerialNumber: 1.40
Jan 17 11:16:55 raspberrypi kernel: [52628.043855] hid-generic 0003:04D9:A052.0002: hiddev96,hidraw1: USB HID v1.10 Device [Holtek USB-zyTemp] on usb-0000:01:00.0-1.1.3/input0
Jan 17 11:16:55 raspberrypi mtp-probe: checking bus 1, device 6: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.1/1-1.1.3"
Jan 17 11:16:55 raspberrypi mtp-probe: bus: 1, device: 6 was not an MTP device
Jan 17 11:16:55 raspberrypi mtp-probe: checking bus 1, device 6: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.1/1-1.1.3"
Jan 17 11:16:55 raspberrypi mtp-probe: bus: 1, device: 6 was not an MTP device

ich bekomme kein Eintrag in by-id/ und by-path/, unten greift die UDEV rule... /dev/co2mini1

Code Auswählen

pi@raspberrypi:~ $ ll /dev/serial/by-id/
insgesamt 0
drwxr-xr-x 2 root root 60 Jan 16 20:39 .
drwxr-xr-x 4 root root 80 Jan 16 20:39 ..
lrwxrwxrwx 1 root root 13 Jan 16 20:39 usb-0658_0200-if00 -> ../../ttyACM0
pi@raspberrypi:~ $ ll /dev/serial/by-
by-id/   by-path/
pi@raspberrypi:~ $ ll /dev/serial/by-path/
insgesamt 0
drwxr-xr-x 2 root root 60 Jan 16 20:39 .
drwxr-xr-x 4 root root 80 Jan 16 20:39 ..
lrwxrwxrwx 1 root root 13 Jan 16 20:39 platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.1.4:1.0 -> ../../ttyACM0
pi@raspberrypi:~ $ ll /dev/co
co2dev1   co2mini1  console
pi@raspberrypi:~ $ ll /dev/co2mini1
lrwxrwxrwx 1 root root 7 Jan 17 11:16 /dev/co2mini1 -> hidraw1
pi@raspberrypi:~ $ ll /dev/co2dev1
lrwxrwxrwx 1 root root 7 Jan 17 11:16 /dev/co2dev1 -> hidraw1
pi@raspberrypi:~ $

Eine Frage, ich glaube /dev/co2dev1 ist von irgendeinem Versuch aus dem letzten Jahr... ich finde nur nicht mehr raus, wo ich das mal eingetragen haben könnte... jemand ne idee wie ich da dran komme?

ich hatte immer ein /dev/comini0, wenn ich direkt am PI4 war... jetzt wurde /dev/co2mini1 erzeugt, nachdem ich den Sensor über einen passiven hub angeschlossen habe.

Wieso zählt er einen hoch, die IDs des CO2 Sensors haben sich nicht geändert und es ist auch kein zweiter dazu gekommen?

VG
REné

Wernieman · 17 Januar 2021, 11:57:50

Wenn der "alte" nicht richtig gelöscht wurde, weil z.B. noch etwas Zugriff hat, dann ist er beim neu Einstecken belegt und Unix verwendet den nächste. Ist übrigens bei allen geräten so.

Wenn Du eine Spezielle udev-Regel suchst, warum grepst du nicht im Konfig-verzeichnis von UDEV?
z.B. ungetestet

Code Auswählen

grep -r "/dev/co" /etc/udev

Das Suchmuster "/dev/co" kannst Du individuell anpassen ...

fireball · 17 Januar 2021, 12:01:02

Ja, danke... ich war selber schon schneller...

Code Auswählen

sudo find / -name "*" | grep co2dev

ich habe noch eine alte UDEV Regel gefunden, aber unter

Code Auswählen

pi@raspberrypi:/lib/udev/rules.d $ more 99-co2dev.rules
ACTION!="add", GOTO="co2dev_end"

    SUBSYSTEMS=="usb", \
    KERNEL=="hidraw*", \
    ATTRS{idVendor}=="04d9", \
    ATTRS{idProduct}=="a052", \
    GROUP="plugdev", \
    MODE="0660", \
    SYMLINK+="co2dev%n", \
    TAG+="systemd", \
    RUN+="/bin/sh -c '/bin/echo /usr/bin/co2monitor-invoker | /usr/bin/at now'", \
    GOTO="co2dev_end"

LABEL="co2dev_end"

Die erzeugt das Device...

Kann es sein, dass wenn zwei Geräte erzeugt sind, das Gerät nicht mehr sauber angesprochen werden kann? Viell. ist ja das das Problem, warum der co2 monitor nicht mehr sauber auf die PI4 läuft...

Wernieman · 17 Januar 2021, 12:40:53

Kann ich Dir nicht sagen, kommt darauf an, was die Software,. also co2monitor-invoker so macht.

Da der Software aber NICHT die Parameter der erzeugten Schnittstelle übergeben wird, würde ich darauf Tippen. Wenn Du experimentierfreudig bist, kannst Du diese Software doch mal "abschießen" (kill). Und dann gucken, ob in "dev" aufgeräumt wurde und Stick raus/reinstecken. Eventuell die "üblichen verdächtigen Logfile", also syslog und kern.log mit prüfen.

Habe die Hardware nicht, kann also nicht für Dich testen. Bin "nur" Linux-Spezialist ...

Btw, mit Deiner "find-Zeile" hast Du nach einem Dateinamen co2dev gesucht. Ich dagegen hatte nach dem Inhalt gesucht, hätte Deine Dati aber nicht gefunden. Was mir noch Auffällt: Warum machst Du aber ein find|grep, wenn find doch selber suchen kann? Auch ist / das gesamte Dateisystem, die Konfig für udev aber in etc zu finden.

Code Auswählen

sudo find /etc/udev -name "*co2dev*"
das | hat den Nachteil, das ALLES über den Speicher ein/ausgelesen wird ....

Edit:
Nach etwas nachdenken finde ich folgende Zeile irgendwie ... "durchs Knie ins Herz geschossen".

Code Auswählen

RUN+="/bin/sh -c '/bin/echo /usr/bin/co2monitor-invoker | /usr/bin/at now'", \
Es wird per echo dem at co2monitor-invoker als parameter übergeben, damit at es sofort startet ....
Läuft eigentlich der co2monitor-invokereinmalig oder als Deamon?

fireball · 17 Januar 2021, 13:26:05

Hi,

danke für dein Feedback.
Kurz zum Befehl... wenn ich nicht weiß wo irgendwie irgendwo etwas steht, dann nutze ich den Befehl um zu suchen.
Mir war bewußt, das er im / alle Dateien durchsucht und nach co2dev grept.

Aber wenn man nicht mehr weiß, was man mal gemacht hat, finde ich das schon sinnig, es ist ja nichts, was auf dauer ewig läuft.
Klar kann man alles optimieren. So habe ich aber schnell gefunden, warum ich da ein 2. device habe.

Kannst du mir den Unterschied zwischen
/lib/udev/rules.d
und /etc/udev/rules.d
erklären?

für das co2mini steht, mann soll seine regel in /etc/udev/rules.d ablegen.
In /lib/udev/rules.d finde ich aber 100te Regeln. Dieser Ort war aus einer anderen Anleitung...

Vergiss RUN+="/bin/sh -c '/bin/echo /usr/bin/co2monitor-invoker | /usr/bin/at now'", \ .
Das war eine andere Anleitung, wo ich nur testen wollte ob das Gerät noch Daten liefert..

Mein Problem ist..
der CO2mini ist wird per UDEV im System bekannt gemacht.
Es gibt ein Script co2mini_server.pl welches einen "CO2Server erzeugt, der die Daten von diesem Device ließt.
Es gibt ein co2mini Service, der diesen Server startet, stopt, restartet
und
es gibt in FHEM ein co2mini Modul, welches entweder direkt auf /dev/co2mini0 geht oder remote auf den Server auf IP:Port

in co2mini_server.pl wird quasi auch auf /dev/co2mini0 verwiesen und man gibt einen Port mit, quasi den, der den Server öffnen soll.

Wenn man das alles einmalig und frisch macht, dann klappt auch der Zugriff direkt oder per Server von FHEM aus.
Ruf macht man ein zwei mal den "reconnect-Button" im FHEM Modul, dann crasht die Server Komponente mit div. Fehlern...

Jetzt ist die Frage warum und ich finde es nicht raus... auf dem PI2 vorher mit dem alten Jessie lief das stabil...

VG
René

Wernieman · 17 Januar 2021, 13:48:10

Warum es crashed ... das solltest Du bei der Software fragen. haben die ein Forum?

Wenn Du es ein 2. oder 3. mal verwenden willst, müsstest Du den ?co2-Server? abschießen. also z.B. durch

Code Auswählen

ps aux | grep co2
die Pid rausfinden und "killen". Übrigens .. alles was eine udev-rule machst, könntest Du auch manuell machen, allerdings als root ...

Btw:
Mische niemals verschiedene Anleitungen, es sei denn, Du weißt was Du tust, hast sie also verstanden (oder befindest Dich auf einem Test-System)

fireball · 17 Januar 2021, 14:02:10

Hi,

ja ist alles hier aus dem Forum, aber da meldet sich keiner mehr. Daher muss ich schauen, was ich verstehe und weiter machen... gibt schon wieder ein zwei Threads dazu, wo andere auch Probleme haben.

Aktuell sieht es jetzt besser aus... die UDEV Rule die ich jetzt habe weicht in einem von dem der Ersteller ab:
ACTION=="add" bei Ersteller war da ein ACTION!="add" und er hat mit Labels gearbeitet...

Ich habe jetzt ein bisl gelesen und folgende UDEV Rule erzeugt und unter /lib/udev/rules.d abgelegt:

Code Auswählen

# co2mini
ACTION=="add", SUBSYSTEMS=="usb", KERNEL=="hidraw*", ATTRS{idVendor}=="04d9", ATTRS{idProduct}=="a052", GROUP="plugdev", MODE="0666", SYMLINK+="co2mini%n", TAG+="systemd"
ACTION=="remove", ENV{ID_SERIAL_SHORT}=="1.40", ENV{ID_VENDOR_ID}=="04d9", ENV{ID_MODEL_ID}=="a052"

Jetzt habe ich das Modul co2mini in FHEM genutzt und ohne IP:Port aufgerufen, dann erwartet es ein Device direkt unter /dev/co2mini0

Das läuft jetzt aktuell stabil, sogar ein Reboot hat geklappt... ich beobachte das weiter... somit ist die Serverkomponente erstmal raus und der Service dafür ist auch gelöscht.
Ich brauch es ja nicht... ich hab den Sensor eh lokal dran...

Ich beobachte mal und berichte ob das stabil bleibt...

VG
René