Denkovi Busmaster ohne Funktion. Tips?

Begonnen von tho-mas, 18 Dezember 2022, 19:02:48

Vorheriges Thema - Nächstes Thema

rob

Ja, OWX wurde ich auch sagen. Hat imho weniger Fehlerquellen.
Es gäbe noch OWserver via Docker, das manches vereinfacht. Aber auch damit noch zu viele/ andere Stolpersteine.

rob

Beim Busmaster hab ich noch diese Attribute aktiv:

attr <OWX> asynchronous 1
attr <OWX> dokick 1


Btw.: Was hältst Du von diesem Vorgehen, nachdem der OWserver deinstalliert ist?:
- notieren welchen Sensoren Du in Fhem bisher wo eingebunden hast (hattest ja von 10 - 20 Sensoren geschrieben), um später leichter zuzuordnen/ wieder einzubauen
- Backup machen
- alles zu 1-Wire außer OWX in Fhem entfernen
- nur einen Sensor direkt am Denkovi dran
- nur den Denkovi allein am USB dran
- ggf. verbose im OWX auf 4 setzen (muss nicht unbedingt aufschlussreicher sein, aber sonst rätselt man ob doch - so wärs gleich dabei)
- den Sensor erkennen lassen mit get devices und ggf. ein Log dafür anlegen
- 24h so laufen lassen und beobachten, ob das zuverlässig/ stabil erscheint
→ Was sagt dann das Log bzgl. Connection d. Busmasters?
→ Wird der eine Sensor richtig erkannt/ angelegt und alle 300s sauber aktualisiert und im Log mit schöner Zeitreihe geführt?

Wenn das stabil erscheint, dann mit dem ganzen Bus weiter machen und abermals beobachten. Wenn auch OK, dann mit weiteren USB-Geräten wieder dran usw.
Ansonsten in der o.gen. Konstellation bleiben und weiter prüfen (anderen USB-Port, anderes Kabel, etc.).

rob

Zitat von: tho-mas am 21 Dezember 2022, 22:01:50
Internals:
...
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003oi-if00-port0
   DEVS       
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003oi-if00-port0
   FUUID      63a360bc-f33f-1cdf-7018-fb2cf02af852a335
   INITDONE   0
...
   STATE      disconnected
...
     2022-12-21 20:55:31   state           disconnected

... weil ich es grad sehe: das kann m.E. nicht passen. Hast Du aus Versehen Helmis define hergenommen?

Laut den Ergebnissen aus Deinen "ls ..." sollte es so lauten (siehe #10 von TomLee):
defmod OWX OWX /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003DN-if00-port0

Danach bitte zur Sicherheit nochmal das list dazu :)

tho-mas

Moin!


Also, die OWX-Def war wohl falsch, aber auch mit deiner (rob) Vorlage habe ich nur "disconnected" als Status.

Ich werde die 1wire Sache neu installieren. Aber erst ab Sonntag. Dazu noch eine Frage: Der owserver läuft ja auf dem Pi, da ist ja eine "stop" -Vorlage weiter oben. Aber ist der dann "für immer" gestopt oder nur bis zum nächsten reboot?

Als Bild habe ich die Sensor-Zuordnung schon gespeichert.

Nur den Busmaster allein an USB geht nur für wenige Stunden am Tag, denn da steuere ich meine Heizkörper mit sowie die Beleuchtung (Z-Wave). 24 h ohne wird meiner Liebsten zu kalt und zu dunkel... :-)) Der Rest der Vorschläge werde ich soweit möglich genau so ausprobieren.

Viele Dank für Eure Unterstützung.


Thomas


rob

#34
Zitat von: tho-mas am 22 Dezember 2022, 19:14:59
...auch mit deiner (rob) Vorlage habe ich nur "disconnected" als Status...
Dann muss dafür die Ursache wohl noch gefunden werden.

Zitat von: tho-mas am 22 Dezember 2022, 19:14:59
...ist der dann "für immer" gestopt oder nur bis zum nächsten reboot? ...
Nein, stop wirkt nur vorüberhend. Siehe #29 von Enno, das wirkt nachhaltig ;)

Zitat von: tho-mas am 22 Dezember 2022, 19:14:59
...Nur den Busmaster allein an USB geht nur für wenige Stunden am Tag, denn da steuere ich meine Heizkörper mit sowie die Beleuchtung (Z-Wave). 24 h ohne wird meiner Liebsten zu kalt und zu dunkel... :-)) Der Rest der Vorschläge werde ich soweit möglich genau so ausprobieren.
Ja, genau richtig. Blind folgen wird schnell kontraproduktiv. Sind ja nur Vorschläge. Du kannst allein sagen, was wie bei Dir eingebunden ist usw.
Solange der Denkovi nicht stabil connected, macht es m.E. Sinn zunächst dafür die Ursache zu finden, bevor es weiter ginge.

Nur eines raff ich nicht: wenn der Denkovi disconnected ist, wie kann Deine Steuerung noch funktionieren?

Viele Grüße
rob

tho-mas

#35
Zitat von: rob am 22 Dezember 2022, 21:19:49

Nur eines raff ich nicht: wenn der Denkovi disconnected ist, wie kann Deine Steuerung noch funktionieren?


Moin und frohe Weihnachten!

Ganz einfach: Z-Wave & WLAN... nicht alles läuft über 1wire. ;-))

So, jetzt beginnt die "Arbeit" um den Busmaster. ---- Alle OWServer-Einträge gelöscht. owserver auf RaspPi-Ebene entfernt. Config gesichert. Strom abgezogen und neu gestartet mit nur einem Sensor. OWX bekommet weiterhin nur die Anzeige "disconnected" heraus... Verständnisfrage: Wenn auf dem Pi der owserver nicht vorhanden ist, wie/wo bekommt FHEM mit dem Modul OWX denn überhaupt die Daten vom 1wire Filesystem her? Ist das im OWX-Modul implementiert?

Update:
"In OWX verbose auf 4" - ich habe kein Auswahlmenü gefunden wo ich das einstellen kann.

Log:
2022.12.25 13:37:33 3: Opening OWX_Sensoren device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003DN-if00-port0
2022.12.25 13:37:33 1: OWX_Sensoren: Can't open /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003DN-if00-port0: No such file or directory
2022.12.25 13:37:33 1: OWX_SER: Can't open serial device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003DN-if00-port0: No such file or directory
2022.12.25 13:37:49 3: OWX_Set OWX_Sensoren reopen => 0
2022.12.25 13:39:34 3: OWX_Set OWX_Sensoren reopen => 0
insgesamt 0


drwxr-xr-x 2 root root 80 25. Dez 13:30 .
drwxr-xr-x 4 root root 80 25. Dez 13:30 ..
lrwxrwxrwx 1 root root 13 25. Dez 13:30 usb-0658_0200-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 25. Dez 13:30 usb-ESERA-Automation_eBus_Coupler_12001_AL54PGN1-if00-port0 -> ../../ttyUSB0


Wie ich weiter oben schon vermutet habe? Das 1wire Dateisystem auf dem Pi wird wohl nicht gefunden. Oder? Und warum ist der Busmaster nicht mehr in der Liste der USB-Geräte?


Update zum Update:

Ich habe inzwischen den zweiten, baugleichen, zur selben Zeit gekauften Busmaster wiedergefunden und angebaut. Auch diese ist verbunden - nicht verbunden - verbunden - nicht ver.... :-((

Immerhin hat dieser (2.) einen weiteten bisher nicht angeschlosenen 18DS20 erkannt. Die danach angestrippten weiteren 18DS20 aber wieder nicht (weil inzwischen disconnted). Übrigens: Warum wird der erkannte Sensor im Raum OWTHERM angezeigt? Normal?

Thomas

Helmi55

Hallo und auch frohe Weihnachten
Ich bin kein Profi, aber wie rot schon geschrieben hat......
Du hast beim Anlegen von OWX meine Werte kopiert??!!

Gruß
Helmut
System1 fhem 6.1 auf RPi 4B mit 4GB, HMUSBConfig, DS9490R-1Wire, Busware USB 868, Pool-Solarsteuerung mit FHEM. System2 fhem 6.1 auf RPi 4B mit 4GB (Bullseye) mit Busware USB 868 und 433 und HMUARTLGW für Haussteuerung

https://www.flickr.com/photos/canonhelmi/

tho-mas

Zitat von: Helmi55 am 26 Dezember 2022, 09:18:55
Du hast beim Anlegen von OWX meine Werte kopiert??!!

Moin!

Ich habe die korrigierte Version genommen, die zu meinem Stick passen sollte.

Gruß
Thomas

rob

Hallo.

Wünsche allen noch einen schönen 2. Weihnachtsfeiertag.

Ich versuche mal ein wenig zu sortieren.
Zitat von: tho-mas am 25 Dezember 2022, 12:51:52
Wenn auf dem Pi der owserver nicht vorhanden ist, wie/wo bekommt FHEM mit dem Modul OWX denn überhaupt die Daten vom 1wire Filesystem her? Ist das im OWX-Modul implementiert?
Ja, OWX kann selbst auf Busmaster zugreifen und benötigt kein OWserver.

Zitat von: tho-mas am 25 Dezember 2022, 12:51:52
"In OWX verbose auf 4" - ich habe kein Auswahlmenü gefunden wo ich das einstellen kann.
In der Übersicht vom OWX-Busmaster-Device hast Du unten ein DropDown-Feld. Alternativ:
attr OWX verbose 4
in die Befehlszeile in FHEM eingeben. Das Busmater-Device muss dann auch OWX heißen, sonst den Befehl entspr. anpassen.

Zitat von: tho-mas am 25 Dezember 2022, 12:51:52
Das 1wire Dateisystem auf dem Pi wird wohl nicht gefunden. Oder? Und warum ist der Busmaster nicht mehr in der Liste der USB-Geräte?
Lass Dich davon nicht irritieren. Nach dem Anstecken des Denkovi MUSS ein Serial-Device angezeigt werden, ganz egal, ob Du OWserver installiert hast. Hat nichts mit OWFS zu tun. Der FTDI auf dem Denkovi stellt das Serial-Device bereit und der Linux-Kernel bindet es entspr. ein.
Den Grund, warum das Gerät mal da ist und mal nicht, wollen wir ja herausfinden. Solange das nicht stabil klappt, kann kein OWX / OWserver richtig zugreifen.

Zitat von: tho-mas am 25 Dezember 2022, 12:51:52
Ich habe inzwischen den zweiten, baugleichen, zur selben Zeit gekauften Busmaster wiedergefunden und angebaut. Auch diese ist verbunden - nicht verbunden - verbunden - nicht ver.... :-((
Ein zweiter Denkovi? Zum Testen ideal. Für den zweiten hattest Du das Serial-Device gefunden und im Define in Fhem entspr. angepasst?
Vorschlag: Zum Testen zunächst beim zweiten bleiben, um evtl. Hardwareprobleme vom ersten halbwegs auszuschließen.
Zeig mal bitte was ls -l /dev/serial/by-id/ sagt, sobald der zweite Denkovi steckt.

Verschwindet der im Terminal auch dauernd und auch wenn er als einziger am USB steckt?
Einen anderen USB-Port versuchen. Anderes Kabel. Doch testweis an einem Hub...

Schießt ggf. der modemmanager quer? Testweise stoppen.
Oder reicht die Stromversorgung am Raspi nicht mehr aus? Anderes Netzteil versuchen. 
Hast Du einen Laptop/ PC mit Linux, wo Du die zwei Denkovi mal einzeln anstöpseln kannst? Was sagt
ls -l /dev/serial/by-id/
bzw.
dmesg | grep DAE

dort? Bleibts dort stabil?

VG
rob

tho-mas

#39
Zitat von: rob am 26 Dezember 2022, 12:52:18

In der Übersicht vom OWX-Busmaster-Device hast Du unten ein DropDown-Feld. Alternativ:
Ach da. Ich hatte bei den beiden Feldern oben gesucht.

Zitat von: rob am 26 Dezember 2022, 12:52:18

Vorschlag: Zum Testen zunächst beim zweiten bleiben, um evtl. Hardwareprobleme vom ersten halbwegs auszuschließen.
Zeig mal bitte was ls -l /dev/serial/by-id/ sagt, sobald der zweite Denkovi steckt.

Gerne:

lrwxrwxrwx 1 root root 13 26. Dez 12:19 usb-0658_0200-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 26. Dez 12:19 usb-ESERA-Automation_eBus_Coupler_12001_AL54PGN1-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 26. Dez 12:19 usb-FTDI_FT232R_USB_UART_DAE003E4-if00-port0 -> ../../ttyUSB1



Zitat von: rob am 26 Dezember 2022, 12:52:18
Verschwindet der im Terminal auch dauernd und auch wenn er als einziger am USB steckt?
Einen anderen USB-Port versuchen. Anderes Kabel. Doch testweis an einem Hub...

Ja, hatte ich ja gestern schon geschrieben.

Anderer USB-Port: Folgt gleich.
Kabel habe ich nur 2 im Einsatz, ich werde noch mal die Grabbelkiste "befragen" und ggf. tauschen.
Hub: Werde ich im Laufe des Tages probieren.

Zitat von: rob am 26 Dezember 2022, 12:52:18

Schießt ggf. der modemmanager quer? Testweise stoppen.

Einen Modemmanager kenne ich nicht, da brauche ich eine genaue Vorgehensanweisung für.

Zitat von: rob am 26 Dezember 2022, 12:52:18

Oder reicht die Stromversorgung am Raspi nicht mehr aus? Anderes Netzteil versuchen.
Unwahrscheinlich: Industrie-Schaltschranknetzteil 5V 3A, mit Meßgerät (Meßumfang 3999 Digit) 5,05V. Aber ich werde nachher noch mal das Oszi anklemmen und eine Messung machen.

Zitat von: rob am 26 Dezember 2022, 12:52:18
Hast Du einen Laptop/ PC mit Linux, wo Du die zwei Denkovi mal einzeln anstöpseln kannst? Was sagt
ls -l /dev/serial/by-id/
bzw.
dmesg | grep DAE

dort? Bleibts dort stabil?

Ja, einen Laptop habe ich, aber den kann ich nur am Schreibtisch testen (der Pi mit den Meßstellenkabeln hängt im Flur auf 2,3m Höhe).


Was ich gestern noch probiert habe:

Ich habe weitere OWX'se angelegt, einmal per "by-id" (schon genannt), dann per "ttyUSB0" und per "ttyUSB1". Die sind seit gestern nacht (nicht ständig geschaut) dauerhaft "opended". Ja, alle 3... Und obwohl im Moment 3 Kabel am Busmaster hängen sind nur 2 Sensoren erkannt. (zwei Kabel je 1 Sensor, ein Kabel kann mehrere Sensoren dran haben.)

Die beiden erkannten Sensoren haben als IODev beide "OWX_ttyUSB1" und ein Meßdatum von genau jetzt (26.12. 13:28:21). 

Beta-User

Wenn du auf "by-id" umstellst (was zu empfehlen ist), solltest du ALLE USB.-Geräte by-id einbinden, zumindest alles, was zum selben "Subtyp" gehört (hier: ttyUSBx). Es könnte sonst z.B. sein, dass das esera-Ding sich denselben Port schnappt...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

tho-mas

Um Busmaster2 am Laptop zu nutzen habe ich Busmaster1 wieder am Pi angeklemmt. Dazu ein neues OWX_1 (für Busmaster1) angelegt, was auch sofort von FHEM angelegt wurde - und erstaunen - 4 Sensoren erkannte. Allerdings hat sich seitdem (13:54:25) auch nichts mehr "bewegt", die Meßdaten sind jetzt (14:18:12) 24 Minuten alt (Anzeige FHEM Übersicht). Wenn ich allerdings ins DeviceOverview von einem der Sensoren gehe ist die letzte Messung von 14:19. Die Sensoren arbeiten, aber in FHEM wird nichts aktualisier??? Normalerweise erfolgt die Werteaktualsierung automatisch, nach einen Seiten-Neuladen sind auch die aktuellen Zeiten der Meßwerte auf der FHEM-Hauptseite zu sehen.

Im Anhang ein Bild vom Busmaster2.


MadMax-FHEM

event-on-change-reading o.ä. gesetzt?

Wenn es keine Events gibt (obwohl sich die Werte in der Detailansicht aktualisieren), dann bekommt das FHEMWEB (u.U.) nicht mit...

Oder evtl. Attribut longpoll?
Zitat von: commandref
longpoll [0|1|websocket]
If activated, the browser is notifed when device states, readings or attributes are changed, a reload of the page is not necessary. Default is 1 (on), use 0 to deactivate it.
If websocket is specified, then this API is used to notify the browser, else HTTP longpoll. Note: some older browser do not implement websocket.

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

tho-mas

#43
Hallo Joachim,

guter Hinweis. In der alten Sensorenliste wae "on Change" teilweise auf 1 Minute gesetzt, jetzt sind die Sensoren ja neu eingelesen worden und diese Einstallungen fehlen.

"Longpoll" hatte irgendwie nie richtig funktioniert, ich hatte immer nur die per stateformat ausgegebenen Werte beobachtet. Aber standartmäßig ist das ja sowieso an. Was ich ich dem Zusammenhang nie verstanden habe: API vs. HTTP. Dazu reicht mein Englsich nicht aus.

Nachtrag ca. 45 min später: In der Weboberfläche von FHEM wurden die Temperaturen ohne mein Zutun aktualisiert (10 min Rhytmus). Warum das auf einmal geht ist mir ein Rätsel. Mal sehen ob das System mit nur 4 Sensoren soweit stabil bleibt. Ggf. werde ich heute am Abend weitere Sensoren anklemmen.

Neuer Nachtrag gegen 19 Uhr:


lrwxrwxrwx 1 root root 13 26. Dez 13:34 usb-0658_0200-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 26. Dez 13:34 usb-ESERA-Automation_eBus_Coupler_12001_AL54PGN1-if00-port0 -> ../../ttyUSB2
lrwxrwxrwx 1 root root 13 26. Dez 13:40 usb-FTDI_FT232R_USB_UART_DAE003DN-if00-port0 -> ../../ttyUSB4
2022.12.26 13:44:11 1: OWX_Init called for bus OWX_1 with interface state opened, now going for detect
2022.12.26 13:44:11 1: OWX_SER::Detect 1-Wire bus OWX_1: interface master DS2480 detected for the first time
2022.12.26 13:44:12 3: OWTHERM:  Device OWX_28_6A0437060000 defined.
2022.12.26 13:44:12 3: OWTHERM:  Device OWX_28_594F64080000 defined.
2022.12.26 13:44:12 3: OWTHERM:  Device OWX_28_B72737060000 defined.
2022.12.26 13:44:12 3: OWTHERM:  Device OWX_28_FF0235521704 defined.
2022.12.26 13:44:12 3: OWTHERM:  Device OWX_28_FF0BF1011703 defined.
2022.12.26 13:44:13 1: OWX_Discover: 1-Wire devices found on bus OWX_1 (OWX_28_6A0437060000,OWX_28_594F64080000,OWX_28_B72737060000,OWX_28_FF0235521704,OWX_28_FF0BF1011703)
2022.12.26 13:44:13 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003DN-if00-port0 reappeared (OWX_1)
2022.12.26 13:48:11 1: OWX_Complex called while interface OWX_ttyUSB1 disconnected
2022.12.26 13:48:20 1: OWX_Complex called while interface OWX_ttyUSB1 disconnected
2022.12.26 13:53:11 1: OWX_Complex called while interface OWX_ttyUSB1 disconnected
2022.12.26 13:53:20 1: OWX_Complex called while interface OWX_ttyUSB1 disconnected
2022.12.26 13:58:11 1: OWX_Complex called while interface OWX_ttyUSB1 disconnected
2022.12.26 13:58:20 1: OWX_Complex called while interface OWX_ttyUSB1 disconnected
2022.12.26 14:03:11 1: OWX_Complex called while interface OWX_ttyUSB1 disconnected
2022.12.26 14:03:20 1: OWX_Complex called while interface OWX_ttyUSB1 disconnected
2022.12.26 14:08:11 1: OWX_Complex called while interface OWX_ttyUSB1 disconnected
2022.12.26 14:08:20 1: OWX_Complex called while interface OWX_ttyUSB1 disconnected
2022.12.26 14:13:11 1: OWX_Complex called while interface OWX_ttyUSB1 disconnected
2022.12.26 14:13:20 1: OWX_Complex called while interface OWX_ttyUSB1 disconnected
2022.12.26 14:18:11 1: OWX_Complex called while interface OWX_ttyUSB1 disconnected
2022.12.26 14:18:20 1: OWX_Complex called while interface OWX_ttyUSB1 disconnected
2022.12.26 14:23:11 1: OWX_Complex called while interface OWX_ttyUSB1 disconnected
2022.12.26 14:23:20 1: OWX_Complex called while interface OWX_ttyUSB1 disconnected
2022.12.26 14:28:11 1: OWX_Complex called while interface OWX_ttyUSB1 disconnected
2022.12.26 14:28:20 1: OWX_Complex called while interface OWX_ttyUSB1 disconnected
2022.12.26 14:33:11 1: OWX_Complex called while interface OWX_ttyUSB1 disconnected
2022.12.26 14:33:20 1: OWX_Complex called while interface OWX_ttyUSB1 disconnected
2022.12.26 14:38:11 1: OWX_Complex called while interface OWX_ttyUSB1 disconnected
2022.12.26 14:38:20 1: OWX_Complex called while interface OWX_ttyUSB1 disconnected
2022.12.26 14:43:11 1: OWX_Complex called while interface OWX_ttyUSB1 disconnected
2022.12.26 14:43:20 1: OWX_Complex called while interface OWX_ttyUSB1 disconnected
2022.12.26 14:48:11 1: OWX_Complex called while interface OWX_ttyUSB1 disconnected
2022.12.26 14:48:20 1: OWX_Complex called while interface OWX_ttyUSB1 disconnected
2022.12.26 14:53:11 1: OWX_Complex called while interface OWX_ttyUSB1 disconnected
2022.12.26 14:53:20 1: OWX_Complex called while interface OWX_ttyUSB1 disconnected
2022.12.26 14:58:11 1: OWX_Complex called while interface OWX_ttyUSB1 disconnected
2022.12.26 14:58:20 1: OWX_Complex called while interface OWX_ttyUSB1 disconnected
2022.12.26 15:03:11 1: OWX_Complex called while interface OWX_ttyUSB1 disconnected
2022.12.26 15:03:20 1: OWX_Complex called while interface OWX_ttyUSB1 disconnected
2022.12.26 15:08:11 1: OWX_Complex called while interface OWX_ttyUSB1 disconnected
2022.12.26 15:08:20 1: OWX_Complex called while interface OWX_ttyUSB1 disconnected


Soweit ich den Ausschnitt oben verstehe:
- Der Busmaster wurde erkannt, per ID, aber im System als USB4 (wieso 4???) eingetragen.

- Das Gerät OWX_1 (mein Busmaster nummer 1) hat 5 Sensoren "entdeckt".

- Irgendein OWX_Complex findet auf ttyUSB1 nichts (klar, wenn die Daten auf USB4 stehen). Aber warum sucht der Complex auf 1?

Das letzte wiederholt sich im Minutenabstand.

OWX_1 ist ständig wieder "disconneted".

Beta-User

Hektische Umstöpseleien bringen nur Verwirrung rein.

Hast du jetzt endlich ALLE IO-FHEM-Devices, die auf USB zugreifen per "by-id" definiert? Schaut nämlich nicht so aus....
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files