Migration von Fhem

fireball · 08 März 2020, 20:11:07

Moinsen,

ich habe ein kleines Problem mit meiner Migration.
Habe ein neues FHEM auf ne neuen PI aufgesetzt und das Fhem-Backup eingespielt.

Jetzt habe ich meinen ZWAVE Stick von der alten Installation (läuft parall noch mit) abgezogen und dan den neuen PI gesteckt und rebootet und wollt sehen, ob alles läuft.
Am neuen PI wurde der wahrscheinlich jetzt unter /dev/ttyAMA0 gefunden.

In FHEM steht er noch als Device:

Code Auswählen

DEF 	/dev/ttyAMA0@115200
DeviceName   /dev/ttyACM0@115200

Schalten der Geräte hat nicht funktioniert

Dann lese ich im Netz usw. das es ein Backup/Restore für die Zwave-Sticks gibt... aber das ist ja nur zur Sicherung, falls der Stick mal kaputt geht... oder?!
Das hat ja nichts mit ner Migration zu tun?!

Könnt ihr mir sagen, wie ich den Sticker sauber für meine neue Installation benutzen kann bzw. an beiden bis alles geht!?
Muss ich den Stick nochmal aus FHEM löschen und wieder neu anlegen?!

Muss ich alle Geräte neu anlernen oder kenn der Stick sein ZWAVE Netzwerk?

VG+Danke
René

Jetzt habe ich den Stick zurück an den alten Pi-2 gemacht und jetzt habe ich da zwei Geräte und nix geht mehr..

Code Auswählen

pi@raspberrypi:~ $ ll /dev/ttyACM0
crw-rw---- 1 root dialout 166, 0 Mär  8 19:53 /dev/ttyACM0
pi@raspberrypi:~ $ ll /dev/ttyAMA0
crw--w---- 1 root tty 204, 64 Mär  5 19:17 /dev/ttyAMA0

Im Log sehe ich auch

Code Auswählen

2020.03.08 19:55:14 3: Opening ZWDongle_0 device /dev/ttyAMA0
2020.03.08 19:55:14 1: ZWDongle_0: Can't open /dev/ttyAMA0: Keine Berechtigung

rudolfkoenig · 08 März 2020, 20:47:06

Folgendes Umzugsverfahren sollte funktionieren:
- den alten FHEM stoppen
- auf dem neuen Rechner FHEM installieren, und fhem.cfg und log/fhem.save aus dem Backup restaurieren
- den gleichen(!) USB-ZWave-Stick in den neuen Rechner einstecken
- FHEM auf dem neuen Rechner starten.
- pruefen, ob Linux den Stick mit dem gleichen Pfad anbietet (siehe dmesg oder ls /dev), falls nicht, modify durchfuehren

Bemerkungen zu deiner Beschreibung:
- ttyAMA0 ist (auf bestimmten PIs) die on-board serielle Schnittstelle, fuer ZWDongle bedeutet das den ZWave-Aufsteck-Modul (Razberry)
- ttyACM0 ist der USB-Stick
- "Permission denied": FHEM sucht beim Startup alle moeglichen Schnittstellen ab, darf wohl auf die Serielle nicht zugreifen
- ZWave-Stick backup/restore braucht man, wenn der Stick ersetzt werden soll, ei restore funktioniert aber nur mit "kompatiblen" Sticks.

Ich gehe davon aus, dass beim Einstecken/Umstecken des Sticks Linux einen neuen Device-Pfad ausgesucht hat, was FHEM nicht gefunden hat.

Beta-User · 08 März 2020, 23:07:27

1. Was liefert "groups fhem" auf der Linux-Konsole?

2. Solche Umzüge Linux zu Linux sind stressfreier, wenn man die USB-IO's "by-id" definiert hat, was auf den meisten Systemen klappt, die - wie Raspbian - udev nutzen.
Eine Anleitung, wie man das umstellt, gibt es u.a. im Wiki unter "mehrere USB-Geräte nutzen" (oder so ähnlich jedenfalls). Wäre also so oder so eine gute Gelegenheit, das umzustellen...

fireball · 09 März 2020, 08:53:26

Hi Rudolf,

genauso habe ich es gemacht... ok, vorweg habe ich noch ein paar Bibliotheken installiert.

Zitat von: rudolfkoenig am 08 März 2020, 20:47:06
Folgendes Umzugsverfahren sollte funktionieren:
- den alten FHEM stoppen
- auf dem neuen Rechner FHEM installieren, und fhem.cfg und log/fhem.save aus dem Backup restaurieren
- den gleichen(!) USB-ZWave-Stick in den neuen Rechner einstecken
- FHEM auf dem neuen Rechner starten.

Mit

Zitat- pruefen, ob Linux den Stick mit dem gleichen Pfad anbietet (siehe dmesg oder ls /dev), falls nicht, modify durchfuehren

meinst du sicher, den Modify Button in den Internals für DEF, oder?!

Mit den Devices muss ich nochmal schauen... der alte PI2 hat diese zwei Geräte, aber da war nie ein Addon-Board für zwave drauf, immer nur der Stick.
In FHM ist er ja auch mit ttyACM0@11xxxx in der Definition.

@Beta-User

mit udev meinst du diese festen "mounten" von geräten unter einem festen namen, richtig!? Das wäre mein zweites Problem, viell. kann ich da zwei fliegen mit einer klappe schlagen.
ich ahbe noch den co2mini dran, den will ich auch wieder anschließen, der zählt dummerweise die nummer immer mal wieder hoch und daher erkennt fhem das gerät nicht immer.

Bei co2mini gibts diese udev-rule:

Code Auswählen

ACTION=="remove", GOTO="co2mini_end"
SUBSYSTEMS=="usb", KERNEL=="hidraw*", ATTRS{idVendor}=="04d9", ATTRS{idProduct}=="a052", GROUP="plugdev", MODE="0666", SYMLINK+="co2mini%n", GOTO="co2mini_end"
LABEL="co2mini_end"

Wenn ich bei SYMLINK einen festen Namen ohne %n eintrage, dann sollte ich immer einen festes Gerät unter /dev/co2mini bekommen richtig?!

Und dann würde ich das gleiche nur mit anderen ATTRS für Vendor und Product für den ZWAVE Stick machen

Code Auswählen

ACTION=="remove", GOTO="co2mini_end"
SUBSYSTEMS=="usb", KERNEL=="hidraw*", ATTRS{idVendor}=="XXXX", ATTRS{idProduct}=="XXXXX", GROUP="plugdev", MODE="0666", SYMLINK+="zwave-usb", GOTO="co2mini_end"
LABEL="co2mini_end"

Dann kann ich in der DEF in FHEM beim Stick auch /dev/zwave-usb überall eintragen, richtig?!

VG+Danke
René

Beta-User · 09 März 2020, 09:13:55

Jein. Du kannst auch udev-rules erstellen, aber die müßtest du dann mit umziehen.

Im Regelfall reicht es aus, das zu nutzen, was udev _automatisch_ macht, ganz so wie es im Wiki aaO. beschrieben ist. Als spezieller Service der direkte Link:
https://wiki.fhem.de/wiki/Mehrere_USB-Ger%C3%A4te_einbinden#Nutzen_der_Serial_ID

Hier ein paar Beispiele, wie das in meinem Echtsystem dann aussieht (da sind ein paar der Umbenennungsmethoden verwendet worden, die auch im Wiki genannt sind, diese Daten sind aber direkt auf/in der jeweiligen Hardware gespeichert...!):

Code Auswählen

define zwaveme ZWDongle /dev/serial/by-id/usb-0658_0200-if00@115200
define MySensorsRS485GW MYSENSORS /dev/serial/by-id/usb-Arduino_LLC_Arduino_Leonardo-if00@115200
define myHmUART HMUARTLGW /dev/serial/by-id/usb-Silicon_Labs_myHMUART_0001-if00-port0
define CUL_0 CUL /dev/serial/by-id/usb-busware.de_CUL868-if00@9600 0000
define SignalDuino SIGNALduino /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0@57600
define MySensorsnRF24GW MYSENSORS /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@115200
define MyRFM69_GW MYSENSORS /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9M9DV3R-if00-port0@115200

fireball · 09 März 2020, 21:04:35

Das ist ja sehr komisch... ich habe das neue raspberian 10.3...

hier gibts kein
pi@raspberrypi:~ $ ls -l /dev/serial/by-id
ls: Zugriff auf '/dev/serial/by-id' nicht möglich: Datei oder Verzeichnis nicht gefunden

Wenn ich den Stick dranstecke, dann passiert auch nix in dmesg, /var/log/messages, ....

unter dev habe ich aber ein
lrwxrwxrwx 1 root root 7 Mär 8 20:31 serial1 -> ttyAMA0
gefunden...

udev-rules konnte ich jetzt auch nicht definieren, weil ich ja das USB-Gerät gar nicht auslesen kann...

Stecke ich den Stick zurück an den alten PI:

Code Auswählen

Mar  9 21:05:48 raspberrypi kernel: [267037.410227] usb 1-1.3: new full-speed USB device number 10 using dwc_otg
Mar  9 21:05:48 raspberrypi kernel: [267037.543533] usb 1-1.3: New USB device found, idVendor=0658, idProduct=0200
Mar  9 21:05:48 raspberrypi kernel: [267037.543553] usb 1-1.3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
Mar  9 21:05:48 raspberrypi kernel: [267037.547101] cdc_acm 1-1.3:1.0: ttyACM1: USB ACM device

mahowi · 09 März 2020, 21:06:51

Was sagt denn lsusb?

fireball · 09 März 2020, 21:09:05

pi@raspberrypi:~ $ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Ich habe jetzt mal zum Testen ne Maus dran gesteckt:
pi@raspberrypi:~ $ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 046d:c05b Logitech, Inc. M-U0004 810-001317 [B110 Optical USB Mouse]
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Also der USB Hub schein aktiv zu sein...

UPDATE:
Hab jetzt alle 4 Ports mal durch... an einem der beiden USB3.0 wurde kurz der Stick erkannt...

Code Auswählen

pi@raspberrypi:~ $ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 0658:0200 Sigma Designs, Inc. Aeotec Z-Stick Gen5 (ZW090) - UZB
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Aber jetzt an keinem mehr....

UPDATE 2:

Kann das ein Stromversorgungsproblem sein? Aber hey... der PI läuft aktuell nur mit dem Stick, nix weiter dran... Stromversorgung über ein 5V 2A Samsung NT.

Beta-User · 09 März 2020, 21:31:50

Netzteil? (kommt @Pi häufiger vor).
USB3-Problem? (ist eigentlich eher ein NUC-Thema).

Kannst du mal einen aktiven USB2-Hub dazwischenklemmen?

fireball · 09 März 2020, 21:45:21

Mist... sowas habe ich nicht... ich hatte noch nie solche Probleme... und wenn ich im netz so google, dann sind es meist leute die externe Platten dranhängen wollen...
der stick selber leuchtet ja auch und wechselt seine farben...

eddi79 · 23 April 2020, 21:10:25

Mein ZWAVE-Stick machte anfangs auch Probleme (wurde mal erkannt, hat aber nicht funktioniert, dann nicht erkannt - mal so mal so). Der PI lief aber normal.
Das Problem war das Netzteil (hatte aber auch nur ein 5V 500mA dran - bei 2 A dürfte eigentlich nichts passieren...)
Würde das aber mal Testen (Unterspannung löst schon die merkwürdigsten Probleme aus).
Hab das meiner Alexa genommen (die V2 hatten ja noch 5V und glaub über 2,4A), damit gings.

Schönen Abend
Markus

fireball · 08 Mai 2020, 18:17:27

So, ich habe ja lange nichts mehr hören lassen... ich hatte ein wenig Pause gemacht, war aber jetzt gezwungen auf das neue System zu gehen... ich habe immernoch massive Probleme mit der USB Erkennung...

Vorweg... orginal Pi4 USB Netzeil ist dran.. keine Besserung! Mal wird was erkannt, mal nicht...

Aber folgende Beobachtung...
Bootet der PI4 ist meist keine Erkennung von ZWAVE Stick und meinem CO2MINI.

CO2Mini wird ab und zu nach dem Reboot erkannt...

Zieh ich den CO2MINI ab und stecke ihn wieder dran, dann ist auf einmal der ZWAVE STICK auch wieder da... und er funktioniert sofort in FHEM...

Code Auswählen

pi@raspberrypi:~ $ lsusb      
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 04d9:a052 Holtek Semiconductor, Inc. USB-zyTemp
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
pi@raspberrypi:~ $
pi@raspberrypi:~ $
pi@raspberrypi:~ $
pi@raspberrypi:~ $
pi@raspberrypi:~ $
pi@raspberrypi:~ $
pi@raspberrypi:~ $
pi@raspberrypi:~ $
pi@raspberrypi:~ $
pi@raspberrypi:~ $
pi@raspberrypi:~ $
pi@raspberrypi:~ $ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 04d9:a052 Holtek Semiconductor, Inc. USB-zyTemp
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
pi@raspberrypi:~ $ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
pi@raspberrypi:~ $
pi@raspberrypi:~ $ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
pi@raspberrypi:~ $ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 0658:0200 Sigma Designs, Inc. Aeotec Z-Stick Gen5 (ZW090) - UZB
Bus 001 Device 004: ID 04d9:a052 Holtek Semiconductor, Inc. USB-zyTemp
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
pi@raspberrypi:~ $ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 0658:0200 Sigma Designs, Inc. Aeotec Z-Stick Gen5 (ZW090) - UZB
Bus 001 Device 004: ID 04d9:a052 Holtek Semiconductor, Inc. USB-zyTemp
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Kann mir das einer erklären? Gibts im Bootmenü vom PI irgendwas, was die USB initialisierung verhindert?

Beim letzten Mal hat das ja auch nicht geholfen, da wars das anstecken abziehen nicht hilfreich...

Ich bin da grad voll blockiert...

fireball · 08 Mai 2020, 18:56:36

OK, ich habs was gefunden... hier im Forum...
https://forum.fhem.de/index.php/topic,110339.0.html
und dann hier
https://www.raspberrypi.org/forums/viewtopic.php?t=245031
und hier
https://github.com/raspberrypi/linux/issues/3027

Allerdings konnte ich jetzt nicht verstehen, ist es ein USB Stick Problem oder ein RP4 Problem...

Christoph Morrison · 08 Mai 2020, 20:06:34

Das Netzteil alleine sagt übrigens gar nichts, man muss immer Netzteil + Kabel betrachten. Es gibt sehr viele echt schrottige USB-Kabel auf dem Markt. Würde mir an deiner Stelle ein USB-Messgerät zum dazwischen stecken besorgen und dann noch mal schauen, was über die Leitung geht.

Mein erster Verdacht bei Problemen mit dem Pi sind übrigens auch immer Energieversorgung, dann Speichermedium.

Wernieman · 08 Mai 2020, 20:24:24

Hast Du jetzt ein PI4 oder älter?

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é