Plötzlich keine Verbindung mehr zum OWServer

[efyzz]

Moin,

ich hatte nun seit einigen Wochen erfolgreich DS1820 Sensoren über den OWServer in FHEM eingelesen.

Gestern habe ich mit meinem Raspberry ein apt upgrade durchgeführt und nun verbindet sich FHEM scheinbar nicht mehr mit dem OWServer.

Auf das Webinterface des OWServer auf Port 2121 kann ich zugreifen und sehe dort auch, dass die Temperaturen aktualisiert werden. Aber in FHEM kommen keine Temperaturen mehr an. Das Device steht auf Initialized.


Hier die Definition in FHEM:

Code Auswählen Erweitern

defmod owServer OWServer localhost:4304
attr owServer room Heizungskeller,OWDevice
Und hier die /etc/owfs.conf:

Code Auswählen Erweitern

# Sample configuration file for the OWFS suite for Debian GNU/Linux.
#
#
# This is the main OWFS configuration file. You should read the
# owfs.conf(5) manual page in order to understand the options listed
# here.

######################## SOURCES ########################
#
# With this setup, any client (but owserver) uses owserver on the
# local machine...
! server: server = localhost:4304
#
# ...and owserver uses the real hardware, by default fake devices
# This part must be changed on real installation
#server: FAKE = DS18S20,DS2405
#
# USB device: DS9490
#server: usb = all
#
# Serial port: DS9097
#server: device = /dev/ttyDS1820
server: passive = /dev/ttyDS1820
#
# owserver tcp address
#server: server = 192.168.1.9:3131
#
# random simulated device
#server: FAKE = DS18S20,DS2405
#
######################### OWFS ##########################
#
#mountpoint = /mnt/1wire
#allow_other
#
####################### OWHTTPD #########################

http: port = 2121

####################### OWFTPD ##########################

ftp: port = 2120

####################### OWSERVER ########################

server: port = localhost:4304


Echt merkwürdig, dass es seit dem Upgrade plötzlich nicht mehr geht. An FHEM habe ich nichts relevantes geändert ... Jemand eine Idee dazu?

Vielen Dank im Voraus!

[Dr. Boris Neubert]

Hi,

ich tippe auf ein Problem mit der Library. In der Commandref zu OWServer gibt es Hinweise auf den Einsatz der richtigen ow*-Pakete unter Debian.

Viele Grüße
Boris

[efyzz]

Hallo Boris,

vielen Dank für den Hinweis! Ich nehme an, ich müsste jetzt die entsprechende ownet.pm in die FHEM/lib kopieren, wie Du es hier beschrieben hast:
https://forum.fhem.de/index.php?topic=85542.msg784834#msg784834

Aber wie finde ich raus, welche Version ich brauche und wo kriege ich die her? Google wollte es mir bisher nicht sagen ... Außer, dass das Projekt wohl nach Github umgezogen ist:
https://github.com/owfs/owfs/blob/master/module/ownet/perl5/OWNet/lib/OWNet.pm

Aber da steht auch nichts von Version. 

Nochmals danke!

[Dr. Boris Neubert]

Du könntest es mit dieser Version von OWNet.pm versuchen:

https://github.com/owfs/owfs/blob/master/module/ownet/perl5/OWNet/lib/OWNet.pm

Die ist seit 3 Jahren nicht mehr angepasst worden. Vielleicht läuft sie mit dem bei Dir installierten owserver. Welche Version hat denn das owserver-Paket in Deiner Raspbian-Installation?

[efyzz]

Das war ja genau mein Problem, dass ich nicht wusste, wie ich die Version rauskriege 
Aber nun:

Code Auswählen Erweitern

$ dpkg -l

ii  ow-shell                            3.2p4+dfsg1-4.1+b1              arm64        shell utilities to talk to an 1-Wire owserver
ii  owfs                                3.2p4+dfsg1-4.1                  all          Dallas 1-wire support
ii  owfs-common                          3.2p4+dfsg1-4.1                  all          common files used by any of the OWFS programs
ii  owfs-fuse                            3.2p4+dfsg1-4.1+b1              arm64        1-Wire filesystem
ii  owftpd                              3.2p4+dfsg1-4.1+b1              arm64        FTP daemon providing access to 1-Wire networks
ii  owhttpd                              3.2p4+dfsg1-4.1+b1              arm64        HTTP daemon providing access to 1-Wire networks
ii  owserver                            3.2p4+dfsg1-4.1+b1              arm64        Backend server for 1-Wire control
Also habe ich die OWNet.pm von Github nach /opt/fhem/FHEM/lib/OWNet-3.2p4.pm kopiert (und natürlich chown auf fhem:dialout).

Aber es funktioniert trotzdem nicht und in FHEM wird immer noch die alte Version 3.1p5 angezeigt:

Code Auswählen Erweitern

Internals
DEF localhost:4304
FUUID 656115ec-f33f-6f7b-2c7c-046c2fb2ddd5957a
LAST_READ_FAILED 0
NAME owServer
NOTIFYDEV global
NR 684
NTFY_ORDER 50a-owServer
OWNET_VERSION 3.1p5
STATE Initialized
TYPE OWServer
eventCount 2
Übrigens steht im fhem.log bei einem set owServer reopen:

Code Auswählen Erweitern

2024.01.13 20:23:36 3: owServer: Opening connection to OWServer localhost:4304...
2024.01.13 20:23:36 3: owServer: Successfully connected to localhost:4304.

Code Auswählen Erweitern

Die ist seit 3 Jahren nicht mehr angepasst worden.Das hat mich auch irritiert. Ich habe meinen Rapsberry im November komplett neu mit Bookworm aufgesetzt und dann auch OWServer eingerichtet. Seitdem lief es. Und nun, bei einem Update nur 2 Monate später, geht nichts mehr.


Möglicherweise liegt die Wurzel des Problems aber auch ganz woanders (obwohl das für mich keinen Sinn ergibt):

Ich bin auf das Problem überhaupt erst aufmerksam geworden, weil ich gesehen habe, dass owserver beim Booten mehrere Versuche braucht, um zu starten. Im Moment läuft er sogar direkt nach einem Reboot erst mal gar nicht:

Code Auswählen Erweitern

$ sudo service owserver status
× owserver.service - Backend server for 1-wire control
    Loaded: loaded (/lib/systemd/system/owserver.service; enabled; preset: enabled)
    Active: failed (Result: exit-code) since Sat 2024-01-13 21:04:34 CET; 1min 7s ago
TriggeredBy: × owserver.socket
      Docs: man:owserver(1)
    Process: 646 ExecStart=/usr/bin/owserver --foreground -c /etc/owfs.conf (code=exited, status=1/FAILURE)
  Main PID: 646 (code=exited, status=1/FAILURE)
        CPU: 66ms

Jan 13 21:04:34 raspberryFHEM systemd[1]: owserver.service: Scheduled restart job, restart counter is at 5.
Jan 13 21:04:34 raspberryFHEM systemd[1]: Stopped owserver.service - Backend server for 1-wire control.
Jan 13 21:04:34 raspberryFHEM systemd[1]: owserver.service: Start request repeated too quickly.
Jan 13 21:04:34 raspberryFHEM systemd[1]: owserver.service: Failed with result 'exit-code'.
Jan 13 21:04:34 raspberryFHEM systemd[1]: Failed to start owserver.service - Backend server for 1-wire control.

Manuell lässt er sich dann aber starten:

Code Auswählen Erweitern

$ sudo service owserver start
$ sudo service owserver status
● owserver.service - Backend server for 1-wire control
    Loaded: loaded (/lib/systemd/system/owserver.service; enabled; preset: enabled)
    Active: active (running) since Sat 2024-01-13 21:09:06 CET; 4s ago
TriggeredBy: × owserver.socket
      Docs: man:owserver(1)
  Main PID: 1408 (owserver)
      Tasks: 3 (limit: 765)
        CPU: 52ms
    CGroup: /system.slice/owserver.service
            └─1408 /usr/bin/owserver --foreground -c /etc/owfs.conf

Jan 13 21:09:06 raspberryFHEM systemd[1]: Starting owserver.service - Backend server for 1-wire control...
Jan 13 21:09:06 raspberryFHEM systemd[1]: Started owserver.service - Backend server for 1-wire control.
Dasselbe gilt für owhttpd.


Warum starten owserver und owhttp nicht erfolgreich beim Booten, lassen sich aber manuell starten?

Und gibt es außer den beiden vielleicht noch einen weiteren Service, der laufen muss?


Nochmals danke!

[Dr. Boris Neubert]

Übrigens steht im fhem.log bei einem set owServer reopen:

Code Auswählen Erweitern

2024.01.13 20:23:36 3: owServer: Opening connection to OWServer localhost:4304...
2024.01.13 20:23:36 3: owServer: Successfully connected to localhost:4304.

Das ist erstmal gut. Außer owserver muss für FHEM nichts laufen. Ich bleibe mal bei dem FHEM-Problem.

Die heruntergeladenen OWNet.pm muss als OWNet-3.2p4.pm in den Ordner FHEM/lib (da wo die beiden anderen schon sind).

Die Versionsnummer dann im define angeben, Beispiel:

Code Auswählen Erweitern

define myOWServer OWServer raspi:4304 3.2p4
3.2p4 ist geraten. Du kannst auch einen anderen String im Namen des OWNet-Moduls und im Define verwenden.

Interessant wäre dann noch der Teil des FHEM-Logs, der beim Laden des OWServer-Moduls geschrieben wird.

Eine weitere Fehlerquelle ist üblicherweise noch /etc/owfs.conf, die ziehmlich genauso aussehen soll wie in der Commandref. Wenn die aber nicht verändert wurde (prüfen! vielleicht versehentlich beim Update überschrieben) und es vor dem Update lief, scheidet diese Fehlerquelle aus.

[efyzz]

Nabend,

Die heruntergeladenen OWNet.pm muss als OWNet-3.2p4.pm in den Ordner FHEM/lib (da wo die beiden anderen schon sind).

Genau so habe ich es gemacht:

Code Auswählen Erweitern

$ ls -l /opt/fhem/FHEM/lib/
total 3316
-rw-r--r-- 1 fhem dialout  80291 Nov 15  2015 74_AMADautomagicFlows0.8.1.xml
-rw-r--r-- 1 fhem dialout 209958 Dec 12  2016 74_AMADautomagicFlowset_2.6.7.xml
-rw-r--r-- 1 fhem dialout 330219 Sep 15  2018 74_AMADautomagicFlowset_4.2.3.xml
-rw-r--r-- 1 fhem dialout 334539 Nov 12  2019 74_AMADautomagicFlowset_4.4.3.xml
-rw-r--r-- 1 fhem dialout 410988 Sep 15  2018 74_AMADtaskerset_4.2.3.prj.xml
-rw-r--r-- 1 fhem dialout 465967 Nov 12  2019 74_AMADtaskerset_4.4.3.prj.xml
drwxr-xr-x 2 fhem dialout   4096 Apr 16  2021 AttrTemplate
drwxr-xr-x 4 fhem dialout   4096 Dec 12  2016 Device
drwxr-xr-x 2 fhem dialout   4096 Nov 19 20:09 EnOcean
-rw-r--r-- 1 fhem dialout   9355 Sep 15  2018 EnO_ReCom_Device_Descr.xml
-rw-r--r-- 1 fhem dialout  45332 Dec 24 20:09 fhem_zwave_deviceconfig.xml.gz
-rw-r--r-- 1 fhem dialout  11604 Nov 15  2015 LiquidCrystal.pm
drwxr-xr-x 3 fhem dialout   4096 Dec 12  2016 MP3
drwxr-xr-x 3 fhem dialout   4096 Dec 12  2016 Net
-rw-r--r-- 1 fhem dialout 730362 Nov 19 21:16 openzwave_deviceconfig.xml.gz
-rw-r--r-- 1 fhem dialout 174240 Dec 24 20:09 openzwave_manufacturer_specific.xml
-rw-r--r-- 1 fhem dialout  21353 Sep 15  2018 OWNet-2.8p17.pm
-rw-r--r-- 1 fhem dialout  21474 Sep 15  2018 OWNet-3.1p5.pm
-rw-r--r-- 1 fhem dialout  21448 Jan 13 20:55 OWNet-3.2p4.pm
-rw-r--r-- 1 fhem dialout  21407 Nov 15  2015 OWNet.pm
-rw-r--r-- 1 fhem dialout   6413 Nov 15  2015 ProtoThreads.pm
-rw-r--r-- 1 fhem dialout   1162 Nov 15  2015 README.perl-firmata
-rw-r--r-- 1 fhem dialout 246073 Nov 19 21:16 SD_ProtocolData.pm
-rw-r--r-- 1 fhem dialout  80768 Nov 19 21:16 SD_Protocols.pm
-rw-r--r-- 1 fhem dialout  29754 Nov 19 21:16 SHC_packet_layout.xml
drwxr-xr-x 4 fhem dialout   4096 Dec 12  2016 SWAP
drwxr-xr-x 2 fhem dialout   4096 Sep 15  2018 UPnP
-rw-r--r-- 1 fhem dialout  39700 Apr  9  2023 zwave_alliancelinks.csv.gz
-rw-r--r-- 1 fhem dialout  22473 Sep 15  2018 zwave_pepperlinks.csv.gz


Die Versionsnummer dann im define angeben

Ach ja, na klar ...

Geht aber trotzdem nicht, er nutzt scheinbar trotzdem noch 3.1p5:

Code Auswählen Erweitern

Internals
DEF OWServer localhost:4304 3.2p4
FUUID 656115ec-f33f-6f7b-2c7c-046c2fb2ddd5957a
LAST_READ_FAILED 0
NAME owServer
NOTIFYDEV global
NR 684
NTFY_ORDER 50a-owServer
OWNET_VERSION 3.1p5
STATE Initialized
TYPE OWServer
eventCount 2

Interessant wäre dann noch der Teil des FHEM-Logs, der beim Laden des OWServer-Moduls geschrieben wird.

Habe mein Device owServer auf Verbose 5 gesetzt und FHEM neu gestartet:

Code Auswählen Erweitern

2024.01.14 22:45:39 1: in INITIALIZED
2024.01.14 22:45:39 1: in DEFINED
2024.01.14 22:45:39 3: owServer: Opening connection to OWServer OWServer...
2024.01.14 22:45:39 3: owServer: Successfully connected to OWServer.
2024.01.14 22:45:39 1: PERL WARNING: Use of uninitialized value in split at ./FHEM/10_OWServer.pm line 496.
2024.01.14 22:45:39 0: Featurelevel: 6.2
2024.01.14 22:45:39 0: Server started with 692 defined entities (fhem.pl:28227/2023-11-29 perl:5.036000 os:linux user:fhem pid:141656)
Sieht doch eigentlich ganz gut aus...?

Eine weitere Fehlerquelle ist üblicherweise noch /etc/owfs.conf, die ziehmlich genauso aussehen soll wie in der Commandref

Sollte passen und wurde durch das Update nicht verändert:

Code Auswählen Erweitern

# Sample configuration file for the OWFS suite for Debian GNU/Linux.
#
#
# This is the main OWFS configuration file. You should read the
# owfs.conf(5) manual page in order to understand the options listed
# here.

######################## SOURCES ########################
#
# With this setup, any client (but owserver) uses owserver on the
# local machine...
! server: server = localhost:4304
#
# ...and owserver uses the real hardware, by default fake devices
# This part must be changed on real installation
#server: FAKE = DS18S20,DS2405
#
# USB device: DS9490
#server: usb = all
#
# Serial port: DS9097
#server: device = /dev/ttyDS1820
server: passive = /dev/ttyDS1820
#
# owserver tcp address
#server: server = 192.168.1.9:3131
#
# random simulated device
#server: FAKE = DS18S20,DS2405
#
######################### OWFS ##########################
#
#mountpoint = /mnt/1wire
#allow_other
#
####################### OWHTTPD #########################

http: port = 2121

####################### OWFTPD ##########################

ftp: port = 2120

####################### OWSERVER ########################

server: port = localhost:4304


[Dr. Boris Neubert]

Hallo,

ich bräuchte bitte noch den Teil des Logs, wo der

Code Auswählen Erweitern

define owServer OWServer localhost:4304 3.2p4 protokolliert wird. Da steht was von "Suggesting OWNet version ..." im Protokoll.

Viele Grüße
Boris

[efyzz]

Hallo Boris,

gern:

Code Auswählen Erweitern

2024.01.15 18:46:37 5: Cmd: >define owServer OWServer OWServer localhost:4304 3.2p4<
2024.01.15 18:46:37 5: Loading ./FHEM/10_OWServer.pm
2024.01.15 18:46:37 5: owServer: Suggesting OWNet version localhost:4304 3.2p4
2024.01.15 18:46:37 2: owServer: Suggested OWNet version localhost:4304 3.2p4 not available, falling back to default version 3.1p5
2024.01.15 18:46:37 5: owServer: Loading OWNet version 3.1p5...
2024.01.15 18:46:37 3: owServer: OWNet version 3.1p5 loaded.
2024.01.15 18:46:37 3: owServer: Opening connection to OWServer OWServer...
2024.01.15 18:46:37 3: owServer: Successfully connected to OWServer.
2024.01.15 18:46:37 2: owServer: Could not read owserver version, using OWNet version 3.1p5.
2024.01.15 18:46:37 5: Cmd: >setuuid owServer 656115ec-f33f-6f7b-2c7c-046c2fb2ddd5957a<
2024.01.15 18:46:37 5: Cmd: >attr owServer room Heizungskeller,OWDevice<
2024.01.15 18:46:37 5: Cmd: >attr owServer verbose 5<
Danke nochmal für Deine Zeit!

[Wernieman]

Auffallend:

Code Auswählen Erweitern

2024.01.15 18:46:37 2: owServer: Suggested OWNet version localhost:4304 3.2p4 not available, falling back to default version 3.1p5
Was mir da gleich auffällt, welche Berechtigung hat denn eigentlich das "lib"-Verzeichnis?

Code Auswählen Erweitern

ls -lhad /opt/fhem/FHEM/lib
Und zur Sicherheit: Liegt FHEM bei Dir wirklich unter /opt/fhem?

[efyzz]

Und zur Sicherheit: Liegt FHEM bei Dir wirklich unter /opt/fhem?

Ja.

Code Auswählen Erweitern

$ ls -lhad /opt/fhem/FHEM/lib
drwxr-xr-x 9 fhem dialout 4.0K Jan 13 20:55 /opt/fhem/FHEM/lib
Ich habe spasseshalber mal die originale 3.1p5 nach 3.2p5 kopiert, um sicherzustellen, dass die Datei von Github nicht defekt ist. Das Ergebnis ist dasselbe:

Code Auswählen Erweitern

2024.01.15 21:23:31 5: owServer: Suggesting OWNet version localhost:4304 3.2p5
2024.01.15 21:23:31 2: owServer: Suggested OWNet version localhost:4304 3.2p5 not available, falling back to default version 3.1p5

[Dr. Boris Neubert]

Ich glaube, wir haben einen Fehler in Zeile 200 von 10_OWServer.pm:

Code Auswählen Erweitern

my $filename= $attr{global}{modpath}."/FHEM/lib/OWNet-$v.pm";
Vermutlich geht es schneller, wenn Du es ausprobierst: entferne mal bitte /FHEM aus dem Pfad in Zeile 200, dann FHEM neu starten, und nochmal schauen, ob er OWNet-3.2p4 jetzt findet.

[efyzz]

Hat leider nichts geändert, die Fehlermeldung ist wie gehabt.

Code Auswählen Erweitern

2024.01.16 21:48:29 5: owServer: Suggesting OWNet version localhost:4304 3.2p4
2024.01.16 21:48:29 2: owServer: Suggested OWNet version localhost:4304 3.2p4 not available, falling back to default version 3.1p5
Ich habe jetzt auch nochmal die originale 3.1p5 mit der Version von Github überschrieben (und nach dem Test natürlich wieder rückgängig gemacht). Temperaturen sehe ich trotzdem nicht.

Also auch wenn es interessant ist, warum er die Datei nicht findet, mein Problem wird es wohl letztlich nicht lösen. Oder holt er sich die 3.1p5 womöglich ganz woanders her und nicht aus /opt/fhem/FHEM/lib?

[efyzz]

Ich bin auf das Problem überhaupt erst aufmerksam geworden, weil ich gesehen habe, dass owserver beim Booten mehrere Versuche braucht, um zu starten. Im Moment läuft er sogar direkt nach einem Reboot erst mal gar nicht:

Code Auswählen Erweitern

$ sudo service owserver status
× owserver.service - Backend server for 1-wire control
    Loaded: loaded (/lib/systemd/system/owserver.service; enabled; preset: enabled)
    Active: failed (Result: exit-code) since Sat 2024-01-13 21:04:34 CET; 1min 7s ago
TriggeredBy: × owserver.socket
      Docs: man:owserver(1)
    Process: 646 ExecStart=/usr/bin/owserver --foreground -c /etc/owfs.conf (code=exited, status=1/FAILURE)
  Main PID: 646 (code=exited, status=1/FAILURE)
        CPU: 66ms

Jan 13 21:04:34 raspberryFHEM systemd[1]: owserver.service: Scheduled restart job, restart counter is at 5.
Jan 13 21:04:34 raspberryFHEM systemd[1]: Stopped owserver.service - Backend server for 1-wire control.
Jan 13 21:04:34 raspberryFHEM systemd[1]: owserver.service: Start request repeated too quickly.
Jan 13 21:04:34 raspberryFHEM systemd[1]: owserver.service: Failed with result 'exit-code'.
Jan 13 21:04:34 raspberryFHEM systemd[1]: Failed to start owserver.service - Backend server for 1-wire control.


Hier bin ich jetzt einen Schritt weiter. Ich habe eine udev rule definiert, die den Symlink "ttyDS1820" anlegt, damit immer das richtige USB-Gerät benutzt wird.

Code Auswählen Erweitern

/etc/udev/rules.d/99-usb.rules

KERNELS=="1-1.5", SUBSYSTEM=="tty", ATTRS{idVendor}=="067b", ATTRS{idProduct}=="2303", SYMLINK+="ttyHeizung"
KERNELS=="1-1.3", SUBSYSTEM=="tty", ATTRS{idVendor}=="067b", ATTRS{idProduct}=="2303", SYMLINK+="ttyDS1820"
SUBSYSTEM=="tty", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", SYMLINK+="ttyStromzaehler"

Offensichtlich kann OWserver "ttyDS1820" beim Booten nicht finden, da scheinbar die udev rule noch nicht abgearbeitet wurde. Wenn ich den OWserver stattdessen direkt auf "ttyUSB1" konfiguriere, startet er erfolgreich beim Booten.

Hat jemand eine Idee, wie man den OWserver Dienst erst starten kann, nachdem die udev rule abgearbeitet wurde?
Und warum ändert sich sowas plötzlich, nur weil man ein apt upgrade durchgeführt hat?


Hilft übrigens nicht bei dem FHEM-Problem weiter, das ist wie bereits vermutet eine andere Baustelle.

[Dr. Boris Neubert]

Hallo,

zu dem Problem mit dem OWServer in FHEM kann ich tatsächlich nur in der Theorie beitragen, weil ich seit Umzug keine 1-Wire-Geräte mehr betreibe.

Wenn Du die mitgelieferte OWNet-xxx.pm, die FHEM lädt, mit der neuesten überschrieben hast, und diese dann geladen wird, und es immer noch nicht geht, dass kann wohl die neueste OWNet.pm nicht helfen. Warum der Lademechanismus nicht funktioniert, kann ich hier "trocken" testen und das Modul anpassen, wenn erforderlich.

Als nächstes könntest Du es mit einen Downgrade des owserver-Pakets versuchen auf die in der Commandref als funktionierend gekennzeichnete Version. Ich weiß aber nicht, ob das alte Debian-Paket auf Deinem System installierbar ist.

Viele Grüße
Boris