FHEM Forum

Moin!

Seitr ca. 6 Jahren läuft meine FHEM-Installation mit ca. 20 bis 30 1Wire Sensoren. Vor 3 Tagen habe ich ein Update gemacht (Bullsey/Raspi4 und FHEM ("Update"). Erst kamen keine Werte von den Sensoren, ich habe dann mehrfach neu gestartet (Strom raus - 10 s gewartet - Strom an. Neustart per Menü der RaspPi Oberfläche. Nur USB-Stecker für 10 s vom Master abgezogen). Half alles nichts.

Die genaue Beobachtung der beiden LEDs auf den Busmaster:
Bei Strom an blinken beide LED kurz auf, nach einigen Sekunden noch einmal beide kurz an, dann absolute Stille.

Ich weis das bei normalem Betrieb die LEDs immer nach einiger Zeit (20s? 1 min?) unregelmäßig aufblitzen (Datenverkehr auf dem 1Wire).

Was kann das sein? Wegen Software? Oder Hardware defekt?

Gruß
Thomas

Bitte mal ein list vom Gerät.

Ich hoffe du meinst mit "Gerät" den OWServer. Falls nicht, dann präzesiere die Frage bitte.

Internals:
   DEF        localhost:4304
   FUUID      61e34760-f33f-1cdf-20d7-b4b55a8aa31e0dce
   LAST_READ_FAILED 0
   NAME       1wire
   NOTIFYDEV  global
   NR         46
   NTFY_ORDER 50a-1wire
   OWNET_VERSION 3.1p5
   STATE      Initialized
   TYPE       OWServer
   eventCount 2
   READINGS:
     2022-12-17 09:12:47   /settings/reopen 0
     2022-12-16 20:40:02   /settings/timeout/directory 60
     2022-12-16 20:40:02   /settings/timeout/ftp 900
     2022-12-16 20:40:02   /settings/timeout/ha7 60
     2022-12-16 20:40:02   /settings/timeout/network 1
     2022-12-16 20:40:02   /settings/timeout/presence 120
     2022-12-16 20:40:02   /settings/timeout/serial 5
     2022-12-16 20:40:02   /settings/timeout/server 10
     2022-12-16 20:40:02   /settings/timeout/stable 300
     2022-12-16 20:40:02   /settings/timeout/uncached 0
     2022-12-16 20:40:02   /settings/timeout/usb 5
     2022-12-16 20:40:02   /settings/timeout/volatile 15
     2022-12-16 20:40:02   /settings/timeout/w1 30
     2022-12-16 20:40:02   /settings/units/pressure_scale mbar
     2022-12-16 20:40:02   /settings/units/temperature_scale C
     2022-12-17 11:04:35   state           Initialized
   fhem:
     protocol   localhost:4304
Attributes:
   nonblocking 1

Ja, das war schon so gemeint.
Nur bei OWServer bin ich raus. Ich nutze den Denkovi mit dem OWX Modul.

Denke du musst deinen Fehler im OWServer suchen.

Wenn ich den Fehler selbst suchen könnte würde ich hier nicht fragen...

Wahrscheinlich ist detektivisches Rantasten nötig, weil imho verschiedene Ursachen Infrage kommen.
Hast Du die Möglichkeit nur einen DS18B20 o.ä. direkt am Schraubterminal vom Denkovi anzubringen (anstelle d. kompletten Busses)?
Einmal mit OWServer testen, ob der erkannt wird. Wenn nicht, OWServer stoppen und mit OWX stattdessen testweise einbinden, wie Frank bereits vorschlägt. Wird dann was erkannt? Wenn nein, spräche m.E. viel für den Denkovi als Ursache. Notfalls Testreihe mit anderem DS18B20 wiederholen.
Wie hast Du den Jumper am Denkovi gesetzt - RC-Filter aktiv? Im Zweifel Jumper ändern und Testreihe wiederholen.
Mal schauen ob/ wo etwas "zuckt"  und dann tasten wir weiter :)

Moin!

Rob, vielen Dank für die konstruktiven Ideen. Vieles läßt sich erst nach der Arbeit probieren. Einzelne DS18B20 habe ich noch liegen, Ergebnis eben am Abend. OWServer habe ich vor vielen Jahren nach Anleitung eingerichtet, OWX sagt mir im Moment gar nichts. Den Jumper habe ich testweise schon gestern mal umgesetzt, keine Änderung des Verhaltens.

Gruß vom der Glatteisbahn (NINA warnt schon)

Thomas

Moin Thomas.

Lass Dich da draußen bloß nicht aufs Glatteis führen ;)
Scherz beiseite: gerne in Ruhe schauen und Schritt für Schritt ausschließen. Oft gerät man in Panik, ändert viel auf einen Schlag und weiß am Ende nicht mehr was alles. Sollte der Denkovi in einer Situation doch noch tun, wären in dieser ggf. die Nodes und der Bus zu prüfen. Ggf. schwieriger per Ausschlussverfahren, deshalb erst mal am verdächtigen Busmaster starten.

OWX ist ganz easy:
define <name> OWX <serial-device>
Normalerweise wird Dir per Autocreate dann ein Device für den DS18B20 angelegt (z.B. OWX_10_blablabla).

Wär halt interessant, weil Du ja auch vom Zusammenhang mit dem Update schreibst.
Btw.: Kam nur Bullseye auf die Kiste und es war vorher schon der Raspi4 oder ist der Raspi auch neu? Frag nur, weil es beim USB hier und da Probleme geben soll. Das wäre die nächste Testreihe: längeres USB-Kabel, USB2-Hub usw.

Interessant auch wie der Denkovi konkret eingebunden wird:
dmesg | grep usb
ls -lah /dev/serial/by-id

Aber Schritt für Schritt  :)

VG
rob

Moin Thomas,

die Infos für OWX hast du ja schon hier eingesammelt: https://forum.fhem.de/index.php/topic,130974.0.html

Es müsste bei dir dann so heissen: define OWX-Device OWX /dev/ttyUSB0

Gruss
  Enno

Moin!

So, ein direkt angeklemmter Sensor liefert keine Werte.

Das define von OWX habe ich gemacht (aber nicht USB0, sondern USB1), das "OWX_Device" ist sichtbar, per drop-Down wird mir angezeigt das Geräte da sind. Aber ich sehe sie nicht (FHEM-Webseite). Der Einzelsensor ist sichtbar, nach dem Essen klemme ich die anderen Kabel wieder an.

OWServer stoppen: Da muß ich erst noch mal suche, ich habe den "alten" OWServer erst mal gelöscht.

Der Pi4 ist seit mind. 2 Jahren unverändert in Betrieb, mit Bullenaugen seit mind. Februar 22, letzte Woche kam nur eine Onlineaktualisierung. Warum längeres USB-Kabel? Ein Hub ist nicht dazwischen (es sei denn, der Pi4 hat sowas "eingebaut").

Was mir noch eingefallen ist: Stimmt vielleicht die Zuordnung OWServer zur USB-Schnittstelle nicht mehr? Mir ist so als wäre da vor längerer Zeit was gewesen.

Gruß
Thomas

ZitatDas define von OWX habe ich gemacht, das "OWX_Device" ist sichtbar, per drop-Down wird mir angezegt das Geräte da sind.

Schwer vorstellbar mit define OWX-Device OWX /dev/ttyUSB0 nach dem Bild sollte es ttyUSB1 sein.
Besser wär über die Serial-ID (https://wiki.fhem.de/wiki/Mehrere_USB-Ger%C3%A4te_einbinden) einzubinden.

Wäre dann define OWX OWX /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003DN-if00-port0

Wenn der Adapter OK ist, landen die automatisch erkannten Devices Stück für Stück im Raum OWX, schneller gehts mit einem get OWX devices

TomLee:

Deine Idee mit Serial-ID funktioniert nicht:

Unknown module /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003DN-if00-port0

Wenn du meine gezeigte Definition genauso in der Befehlszeile oben in FHEMWEB eingibst, kann ich mir nicht vorstellen das es zu dieser Meldung kommt, irgendwas (vorne im define) musst du geändert haben, zeig mal.

Wenn ich

define OWX OWX /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003DN-if00-port0


einkopiere kommt erstmal keine Fehlermeldung, aber nach wenigen Minuten ein "disconnect". Und KEINE Meßwerte, obwohl der Busmaster zwischendurch gut blinkte.

Ich hatte zuerst das 2fache OWX für einen Vertipper gehalten und eines davon gelöscht. War wohl zu gut gemeint, da kam die Fehlermeldung.

Was steht im Log ? Meine das ich das schon richtig von dem Screenshot abgelesen hab, aber zur Sicherheit : Zeig mal was im Log steht nachdem du oben in der Befehlszeile "ls -lah /dev/serial/by-id" eingegeben hast.

Sorry, ich kann dir nicht folgen. Daher meine Bitte, dich genauer zu äußern:

"ls .." sieht nach Terminal des Pis aus, nicht nach FHEM. Wir haben zuletzt aber nur in FHEM rumgemacht.

Welches log? FHEM? Falls nicht, dann Pi. Aber WO? Ich bin kein Unix-Spezialist, du mußt mir dann schon den genauen Pfad liefern.

Sry, mit "Log" war das Logfile in FHEM gemeint, wollte einfach "in FHEM" bleiben, zum erleichtern.

Das
"ls -lah /dev/serial/by-id"
gibst du einfach wie vorgeschlagen oben in der Befehlszeile in FHEM ein.

... dann wäre der Denkovi als Fehlerursache anscheinend widerlegt. Wären doch gute Nachrichten.

Zitat von: tho-mas am 19 Dezember 2022, 18:07:51
Was mir noch eingefallen ist: Stimmt vielleicht die Zuordnung OWServer zur USB-Schnittstelle nicht mehr? Mir ist so als wäre da vor längerer Zeit was gewesen.

Kann durchaus sein. Mal bekommt vielleicht der Denkovi ttyUSB1 mal Dein Esera, was zu komischem Verhalten führen kann (s. Ennos Wink mit dem Zaunpfahl). Quasi nach jedem Reboot möglich. In der Datei /etc/owfs.conf müsste erkennbar (gewesen) sein, wo der Owserver zugreifen sollte.

TomLees Empfehlung per serial/by-id zuzugreifen bringt hier imho Abhilfe (ggf. musst Du den Esera auch so im Blick behalten/ behandeln, damit er nicht reingrätscht).
Oder man folgt dieser Anleitung und legt je eine udev-rule an: https://wiki.fhem.de/wiki/OWServer_%26_OWDevice#Konfiguration_von_owserver (https://wiki.fhem.de/wiki/OWServer_%26_OWDevice#Konfiguration_von_owserver) und spricht den Denkovi dann via /dev/onewire an und den Esera dann z.B. via /dev/ebus. Aufpassen: Unter BullsEye muss ein Detail (SUBSYSTEMS) ggf. anders lauten. Führt jetzt aber vom Weg ab.

Zitat von: tho-mas am 19 Dezember 2022, 18:07:51
OWServer stoppen: Da muß ich erst noch mal suche, ich habe den "alten" OWServer erst mal gelöscht.

z.B. so:

sudo service owserver stop

Wäre nur nötig gewesen, um auszuschließen, dass er dem OWX in die Quere kommt. Ist jetzt wohl hinfällig.

Zitat von: tho-mas am 19 Dezember 2022, 18:07:51
Warum längeres USB-Kabel? Ein Hub ist nicht dazwischen (es sei denn, der Pi4 hat sowas "eingebaut").

Manche USB-Geräte stören sich am Wifi vom PI4 und ein USB-Kabel bringt sie weiter davon weg. Andere USB-Sticks, z.B. der Aeotec Zwave, halten sich nicht an die USB-Spezifikation und machen am USB3 vom PI4 Ärger. Ein USB2-Hub (welcher hoffentl. die Spezifikationen einhält), soll dann helfen.
Ist jetzt aber auch nicht mehr relevant.

VG
rob

Danke für die Infos, das ist mir heute zuviel um noch auszuprobieren. Ich werde mich morgen wieder um diese Problemeatik kümmern.

Gruß
Thomas

Hallo
ich hatte ja auch nach einem update und Bullseye die Probleme das mein Denkovi keine Werte mehr anzeigte.
Ich bin dann auf Shelly mit Addon umgestiegen. Hat den Vorteil das ich die Werte über MQTT und MQTTClient auch auf meinen Hauptrechner ohne das veraltete RFHEM bekomme.
Als ich diesen Thread gelesen habe, hat es mir natürlich keine Ruhe gelassen und ich habe auf meinem Testsystem OWX installiert
define OWX OWX /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003oi-if00-port0

(pi@homebridge:~ $ ls -lah /dev/serial/by-id
insgesamt 0
drwxr-xr-x 2 root root 60 20. Dez 10:55 .
drwxr-xr-x 4 root root 80 20. Dez 10:55 ..
lrwxrwxrwx 1 root root 13 20. Dez 10:55 usb-FTDI_FT232R_USB_UART_DAE003oi-if00-port0 -> ../../ttyUSB0
pi@homebridge:~ $
)

und das funktioniert
Internals:
   ALARM      1
   CFGFN     
   DEF        DS18B20 A7B66D632001
   ERRCOUNT   0
   FUUID      63a187ef-f33f-b084-cda0-4ad6707c7b1693c3
   INTERVAL   10
   IODev      OWX
   NAME       OWX_28_A7B66D632001
   NOTIFYDEV  global
   NR         40
   NTFY_ORDER 50-OWX_28_A7B66D632001
   OW_FAMILY  28
   OW_ID      A7B66D632001
   PRESENT    1
   ROM_ID     28.A7B66D632001.C7
   STATE      T: 24.50 °C ↓
   TYPE       OWTHERM
   eventCount 34
   owg_temp   24.5
   owg_th     75
   owg_tl     70
   READINGS:
     2022-12-20 11:01:19   IODev           OWX
     2022-12-20 11:08:01   state           T: 24.50 °C ↓
     2022-12-20 11:08:01   temperature     24.5
   tempf:
     factor     1
     offset     0
Attributes:
   IODev      OWX
   model      DS18B20
   room       OWX
   tempHigh   75
   tempLow    70

Danke für den Hinweis auch an @Bartimaus
Gruß
Helmut

Zitat von: TomLee am 19 Dezember 2022, 20:33:12
Das

Code Auswählen Erweitern

"ls -lah /dev/serial/by-id"
gibst du einfach wie vorgeschlagen oben in der Befehlszeile in FHEM ein.

Moin!

Ich hätte nicht gedacht das das ein sinnvolles Ergebnis liefert, aber dochj:

drwxr-xr-x 2 root root 100 19. Dez 20:11 .
drwxr-xr-x 4 root root  80 17. Dez 11:04 ..
lrwxrwxrwx 1 root root  13 17. Dez 11:17 usb-0658_0200-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root  13 19. Dez 17:55 usb-ESERA-Automation_eBus_Coupler_12001_AL54PGN1-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root  13 19. Dez 20:11 usb-FTDI_FT232R_USB_UART_DAE003DN-if00-port0 -> ../../ttyUSB1


Und weil es im Log gerade drüber zu sehen ist: Warum ist OWX "disconnected"? Im DeviceOverview steht "state opened 2022-12-19 19:58:01"

2022.12.20 21:19:32 1: OWX_Complex called while interface OWX_Gerate disconnected
2022.12.20 21:19:32 1: OWX_Complex called while interface OWX_Gerate disconnected
2022.12.20 21:19:40 3: DS18B20_FF0BF1011703: reading temperature did not return a value
2022.12.20 21:19:41 1: OWX_Complex called while interface OWX_Gerate disconnected
2022.12.20 21:19:43 1: OWX_Complex called while interface OWX_Gerate disconnected
2022.12.20 21:19:45 1: OWX_Complex called while interface OWX_Gerate disconnected
2022.12.20 21:19:52 1: OWX_Complex called while interface OWX_Gerate disconnected
2022.12.20 21:20:02 1: OWX_Complex called while interface OWX_Gerate disconnected
2022.12.20 21:20:02 1: OWX_Complex called while interface OWX_Gerate disconnected
2022.12.20 21:20:02 1: OWX_Complex called while interface OWX_Gerate disconnected
2022.12.20 21:20:02 1: OWX_Complex called while interface OWX_Gerate disconnected
2022.12.20 21:20:22 3: DS18B20_FFE58B311704: reading temperature did not return a value
2022.12.20 21:20:22 3: DS18B20_6A0437060000: reading temperature did not return a value
2022.12.20 21:20:22 3: DS18B20_594F64080000: reading temperature did not return a value

Zitat
Moin!

Ich hätte nicht gedacht das das ein sinnvolles Ergebnis liefert, aber dochj:

Zufall war nur an den Haaren herbeigezogen  ;)

Die Serial-ID ist also vermutlich korrekt, list des OWX-Device steht zur Bestätigung aber immer noch aus.

Ich weiß mit beiden Meldungen aus dem Log auch nicht weiter zu helfen.

Ähm, hatte ich nicht gesehen. Nun aber:

Internals:
   ALARMED    1
   ASYNCHRONOUS 0
   CFGFN     
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003DN-if00-port0
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003DN-if00-port0
   FD         85
   FUUID      63a238cc-f33f-1cdf-d80c-2bfa0067b5b6b927
   INITDONE   1
   INTERFACE  DS2480
   NAME       OWX
   NR         576
   PARTIAL   
   PRESENT    0
   ROM_ID     FF
   STATE      opened
   TYPE       OWX
   eventCount 5
   interval   300
   timeout    2
   DEVHASH:
     OWX        Busmaster
     OWX_28_B72737060000 28.B72737060000.2A
   DEVS:
     28.B72737060000.2A
   READINGS:
     2022-12-21 06:41:49   state           opened
Attributes:

Vlt. eine Idee noch. Stöpsel mal zum Test die zwei anderen USB-Devices aus und boote das komplette System neu, sind die disconnected Meldungen evtl. dann weg ?

Zitat von: tho-mas am 19 Dezember 2022, 18:07:51
...ich habe den "alten" OWServer erst mal gelöscht...

Das treibt mich noch ein wenig um. Was heißt "gelöscht" genau? Disconnect könnte auch kommen, wenn noch ein anderer Prozess auf das Device zugreifen will und OWX stört. Wenn im Terminal
sudo service owserver status u.a. stopped oder eine Fehlermeldung á la "kenn ich nich" bringt, dann kann OWserver als Störer ausgeschl. werden. Steht dort running, müsste der OWserver gestoppt werden.

Vielleicht sicherheitshalber auch in Fhem schauen, ob noch irgendwas anderes auf ttyUSB1 definiert ist und indirekt auf das selbe Device zugreifen will. Gemäß TomLees Empfehlung hast Du einen Busmaster in Fhem angelegt mit dem Namen "OWX". Im Log wird aber das Device "OWX_Gerate" als disconnected angemerkt. Kommt aus der 00_OWX.pm:
Log3 $name, 1,"OWX_Complex called while interface $name disconnected";
Vielleicht zum konkreten list des OWX mal auch ein "list .*OWX.* absetzten?

DS18B20_FFE58B311704: reading temperature did not return a value
Könnten Nodes sein, welche noch über den OWServer angelegt wurden. Ich meine Nodes, die via OWX kommen, fangen doch mit "OWX_10_..." oder "OWX_28_..." usw. an, oder liege ich da falsch?

Zitat von: rob am 21 Dezember 2022, 10:29:36

Vielleicht zum konkreten list des OWX mal auch ein "list .*OWX.* absetzten?

Das bringt (weil ich seit gestern nur einen Sensor dran habe):

FileLog_OWX_28_13B936060000
OWX
OWX_28_B72737060000

Der Neustart ohne weitere USB kommt gleich, Rückmeldung in ca. 1 h.

Irgendwie ist jetzt alles durcheinander. Ich muß zugeben, das ich bei den ganzen Versuchen/Tests keine FHEM.cfg gesichert hatte, um bei zuviel Fehlern einfach neustarten zu können. Das hat sich jetzt gerächt, der Neustart erfolgte mit alten Einstellungen, die "irgendeinen" Stand haben.

Ich habe den owserver am Pi Terminal mit service stop stillgelegt. Ich habe einen Teil meiner Sensoren wieder angeschlossen, um Zeitstempel zu bekommen. Ich habe in der FHEM-Befehlszeile die lange Kette mit define OWX OWX ... neu eingegeben. Im FHEM-Webfester ist "OWX disconnected", ein Klick auf "reopen" bringt gar nichts. Im Webfenster vom FHEM sehe ich nun diverse "OWDevice"-Einträge mit Sensoren.

Nach einem erneutem Neustart (Strom vom Pi angezogen)  sehe ich Einträge unter OWDevice (die alten Einträger erkennbar an den vor Monaten eingetragenen Aliasen): Die Werte (Temperaturen) werden auf der Webseite NICHT aktualisiert, wenn ich aber einen Eintrag anklicke (Fenster DeviceOverview) dann sehe ich hinter State Temperatur die aktuelle Uhrzeit. Der Busmaster muß also laufen.

Ich verliere im Moment den Überblick - was ist da jetzt los?

Jetzt (nach den Neustarts) noch einmal das Ergebnis von "list .*OWX.*:

Internals:
   DEF        ./log/13B936060000-%Y.log DS18B20_13B936060000
   FD         9
   FUUID      61e44c16-f33f-1cdf-fed5-6bf5ba8c9dd75c4f
   NAME       FileLog_OWX_28_13B936060000
   NOTIFYDEV  DS18B20_13B936060000
   NR         58
   NTFY_ORDER 50-FileLog_OWX_28_13B936060000
   REGEXP     DS18B20_13B936060000
   STATE      active
   TYPE       FileLog
   currentlogfile ./log/13B936060000-2022.log
   logfile    ./log/13B936060000-%Y.log
   READINGS:
     2022-12-16 22:14:12   linesInTheFile  68944
Attributes:
   alias      Temp Bad

Warum da nur ein Sensor angezeigt wird obwohl mind. 5 Sensoren Temperaturen liefern - auch wieder so ein Rätsel.

Zitat von: tho-mas am 21 Dezember 2022, 17:41:40
...Ich verliere im Moment den Überblick...

Dito  ;) Deshalb die Versuche einen Ist-Zustand zu eruieren, um damit dann weiter zu machen.
Auch wenn der OWserver gestoppt sein sollte, weg isser nich  :) Nach dem nä. Reboot läuft er wieder.

Denkst du bitte noch an das list vom OWX? Das Device OWX_Gerate scheint ja verschwunden.

Internals:
   ALARMED    0
   ASYNCHRONOUS 0
   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
   NAME       OWX
   NR         496
   PARTIAL   
   PRESENT    1
   ROM_ID     FF
   STATE      disconnected
   TYPE       OWX
   eventCount 2
   interval   300
   timeout    2
   DEVHASH:
     OWX        Busmaster
   READINGS:
     2022-12-21 20:55:31   state           disconnected
Attributes:

Das Device OWX_Gerate scheint ja verschwunden.

Ja. Komischerweise sind Meßwerte sporadisch in OWDevice aktuell.

Neue Idee: Was ist denn aktuell am sinnvollsten: Weiter auf OWServer zu setzen oder auf OWX? Dann würde ich alles was mit 1Wire zu tun hat rauswerfen und neu installieren.

Ich würde sagen, auf OWX setzen. In der Konsole sudo service owserver stop und dann alles was dazu gehört erst mal deinstallieren. sudo apt purge owserver dann Rechner neu starten und alles weitere in FHEM einrichten...

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.

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.).

Zitat von: tho-mas am 21 Dezember 2022, 22:01:50

Code Auswählen Erweitern

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 :)

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

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

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

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

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

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

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

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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). 

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...

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.

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

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".

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....

Nein, weil ich die Sache mit dem eBus vor einem Jahr mal gemacht habe und nicht einfach löschen kann - denn dann läuft der Wohnzimmerregler der Vailant-Therme nicht mehr. Da werde ich mich morgen drum kümmern (Urlaub).

Schluß für heute
Thomas

Man kann (und sollte) auch ändern (per defmod bzw. Klick auf DEF).

Ohne wird das nur dann vielleicht klappen, wenn du die physischen Ports tauschst (und dazu etwas wartet vor dem Einstöpseln). So macht helfen jedenfalls keine Freude...

Moin!

Zur Umstellung auf "ID" noch zwei Fragen:

usb-ESERA-Automation_eBus_Coupler_12001_AL54PGN1-if00-port0 -> ../../ttyUSB2

Was / welcher Teil ist davon jetzt die ID?

Mein ZWave-Dongle erscheint bei "ls ... by-id" nicht. Hat der keine ID? Der ist jetzt per "DEF   
/dev/ttyACM0@" eingebunden. Kann das so bleiben?

Gruß
Thomas

P.S.:
List ZWDongle_0:
Internals:
   CallbackNr 0
   Clients    :ZWave:
   DEF        /dev/ttyACM0@
   DeviceName /dev/ttyACM0@
   FD         21
   FUUID      61e45998-f33f-1cdf-058b-2420c246a50c39d4
   MaxSendRetries 3
   NAME       ZWDongle_0
   NR         95
   PARTIAL   
   RAWMSG     0004000c0e600d01003202212c0001c4980000
   ReadTime   1672129306.41539
   STATE      Initialized
   SendRetries 0
   SendTime   1672128261.83102
   TYPE       ZWDongle
   WaitForAck 0
   ZWDongle_0_MSGCNT 35094
   ZWDongle_0_TIME 2022-12-27 09:21:46
   devioNoSTATE 1
   eventCount 4
   homeId     f44c0737
   nodeIdHex  01
   nrNAck     0
   setReadingOnAck 1
   MatchList:
     1:ZWave    .*
   READINGS:
     2022-12-26 13:34:33   caps            Vers:4 Rev:36 ManufID:0000 ProductType:0001 ProductID:0001 SERIAL_API_GET_INIT_DATA SERIAL_API_APPL_NODE_INFORMATION APPLICATION_COMMAND_HANDLER ZW_GET_CONTROLLER_CAPABILITIES SERIAL_API_SET_TIMEOUTS SERIAL_API_GET_CAPABILITIES SERIAL_API_SOFT_RESET UNKNOWN_09 ZW_SET_R_F_RECEIVE_MODE ZW_SET_SLEEP_MODE ZW_SEND_NODE_INFORMATION ZW_SEND_DATA ZW_SEND_DATA_MULTI ZW_GET_VERSION ZW_SEND_DATA_ABORT ZW_R_F_POWER_LEVEL_SET ZW_SEND_DATA_META ZW_GET_RANDOM MEMORY_GET_ID MEMORY_GET_BYTE MEMORY_PUT_BYTE MEMORY_GET_BUFFER MEMORY_PUT_BUFFER FLASH_AUTO_PROG_SET ZW_NVR_GET_VALUE NVM_GET_ID NVM_EXT_READ_LONG_BUFFER NVM_EXT_WRITE_LONG_BUFFER NVM_EXT_READ_LONG_BYTE NVM_EXT_WRITE_LONG_BYTE ZW_GET_NODE_PROTOCOL_INFO ZW_SET_DEFAULT ZW_REPLICATION_COMMAND_COMPLETE ZW_REPLICATION_SEND_DATA ZW_ASSIGN_RETURN_ROUTE ZW_DELETE_RETURN_ROUTE ZW_REQUEST_NODE_NEIGHBOR_UPDATE ZW_APPLICATION_UPDATE ZW_ADD_NODE_TO_NETWORK ZW_REMOVE_NODE_FROM_NETWORK ZW_CREATE_NEW_PRIMARY ZW_CONTROLLER_CHANGE ZW_SET_LEARN_MODE ZW_ASSIGN_SUC_RETURN_ROUTE ZW_REQUEST_NETWORK_UPDATE ZW_SET_SUC_NODE_ID ZW_DELETE_SUC_RETURN_ROUTE ZW_GET_SUC_NODE_ID ZW_SEND_SUC_ID ZW_EXPLORE_REQUEST_INCLUSION ZW_REQUEST_NODE_INFO ZW_REMOVE_FAILED_NODE_ID ZW_IS_FAILED_NODE ZW_REPLACE_FAILED_NODE UNKNOWN_66 UNKNOWN_67 ZW_FIRMWARE_UPDATE_NVM GET_ROUTING_TABLE_LINE LOCK_ROUTE_RESPONSE ZW_GET_PRIORITY_ROUTE ZW_SET_PRIORITY_ROUTE UNKNOWN_98 ZW_SET_WUT_TIMEOUT ZW_WATCHDOG_ENABLE ZW_WATCHDOG_DISABLE ZW_WATCHDOG_CHECK ZW_SET_EXT_INT_LEVEL ZW_RF_POWERLEVEL_GET ZW_TYPE_LIBRARY ZW_SEND_TEST_FRAME ZW_GET_PROTOCOL_STATUS WATCHDOG_START WATCHDOG_STOP ZW_SET_ROUTING_MAX UNKNOWN_ee UNKNOWN_ef
     2022-12-26 13:34:33   ctrlCaps        MEMBER PRIMARY SUC
     2022-12-26 13:34:33   homeId          HomeId:f44c0737 CtrlNodeIdHex:01
     2022-01-29 22:41:27   isFailedNode_0  yes
     2022-01-29 22:35:54   isFailedNode_1  no
     2022-01-16 23:59:16   isFailedNode_3  no
     2022-01-16 18:58:02   isFailedNode_5  no
     2022-01-16 18:59:25   neighborList_0  empty
     2022-01-20 21:53:59   neighborList_1  ZWave_THERMOSTAT_2 ZWave_THERMOSTAT_3 ZWave_THERMOSTAT_4 ZWave_THERMOSTAT_5 ZWave_SWITCH_MULTILEVEL_6 ZWave_SENSOR_MULTILEVEL_7 ZWave_SENSOR_NOTIFICATION_8 ZWave_SENSOR_MULTILEVEL_9 UNKNOWN_10 ZWave_SWITCH_MULTILEVEL_11 ZWave_METER_12 ZWave_SWITCH_BINARY_13 UNKNOWN_14
     2022-01-29 22:42:24   nodeInfo_0      node 0 is not present
     2022-01-20 21:53:45   nodeInfo_1      ProtocolVers:SDK4.5x+6.0x listening routing maxBaud:40kbps Controller SpecificDev BeamCap SpeedExt:100kbps RoleType:N/A BasicDevClass:STATIC_CONTROLLER GenericDevClass:STATIC_CONTROLLER SpecificDevClass:01
     2022-01-29 22:43:32   nodeList        ZWDongle_0 ZWave_THERMOSTAT_2 ZWave_THERMOSTAT_3 ZWave_THERMOSTAT_4 ZWave_THERMOSTAT_5 ZWave_SWITCH_MULTILEVEL_6 ZWave_SENSOR_MULTILEVEL_7 ZWave_SENSOR_NOTIFICATION_8 ZWave_SENSOR_MULTILEVEL_9 ZWave_SWITCH_MULTILEVEL_11 ZWave_METER_12 ZWave_SWITCH_BINARY_13 UNKNOWN_14 ZWave_WALL_CONTROLLER_15 ZWave_SENSOR_NOTIFICATION_16 ZWave_SENSOR_NOTIFICATION_17 ZWave_SWITCH_BINARY_18 ZWave_SWITCH_BINARY_19 UNKNOWN_20 ZWave_SENSOR_MULTILEVEL_21
     2022-12-26 13:34:33   random          fa2625040812c6554fee654861aac40ecb4393c3e28a61edd34d2fa624f1b156
     2022-12-26 13:34:33   state           Initialized
     2022-12-26 13:34:33   sucNodeId       1
   SendStack:
Attributes:
   homeId     f44c0737
   setReadingOnAck 1

Zitat von: tho-mas am 27 Dezember 2022, 09:22:38
Zur Umstellung auf "ID" noch zwei Fragen:

Antworten sollten hier zu finden sein:
https://wiki.fhem.de/wiki/Mehrere_USB-Ger%C3%A4te_einbinden

ZitatMein ZWave-Dongle erscheint bei "ls ... by-id" nicht. Hat der keine ID? Der ist jetzt per "DEF   
/dev/ttyACM0@" eingebunden. Kann das so bleiben?

Er hat eine ID, und du hast die hier auch gepostet!
Und die DEF ist "komisch", weil hinter dem @ eigentlich eine Baudrate stehen sollte. Vermutlich hast du die jetzt auf 9600 kastriert. Details spare ich mir, sonst kommen dazu Fragen, die vom eigentlichen Thema ablenken...

Moin!

Beta-User: Den Link habe ich mir durchgelesen. Wo die ID beginnt habe ich glaube ich auch verstanden.

Längeres Kabel habe ich probiert: Keine Änderung.

Hub: Mit Hub geht der Busmaster gar nicht.

Neue Infos: Bei OWX per ID eingebunden werden KEINE Sensoren (OWTHERM) angelegt. (Getestet mit Busmaster 1).

Bei Busmaster 2 wurden Sensoren als OWTHERM angelegt aber keine Filelogs. Sollte das nicht auch automatisch erfolgen?

Bei div. Neustarts des Pi habe ich festgestellt, das Busmaster 1 (inzwischen?) grundsätzlich nicht im System des Pis angemeldet wird, ich muß einmal das USB-Kabel zum Busmaster abziehen und wieder einstecken. Dann zusätzlich im Gerät OWX das Aufklappmenü "reopen" betätigen, dann bleibt das Gerät längere Zeit verbunden.

Der esera eBus-Adapter ist erstmal komplett raus (auch die Geräte in FHEM sind gelöscht).

Der ZWave-Dongle ist auf by-id umgestellt.

Als nächstes habe ich den Busmaster 1 und 2 getauscht (der Busmaster am Pi ist fest auf einer Hutschiene mit Verteilerklemmen angebaut, bisher hatte ich #2 immer nur fliegend angeklemmt). Auch der ist bei einem Rechnerneustart störrisch, er muß entweder per USB-Kabel ab oder per 3fach reopen zur Mitarbeit überredet werden.