Weihnachtsangebot 2025! 🎄

[Laser]

@thomas-braun
habe die funktionierende OWFS.conf vom Raspi und die nicht funktionierende der VM mit CAT dargestellt und im Editor eingefügt. Nebeneinander gestellt.
Ausser, dass ich natürlich die Adresse des Rechners anpassen muß, finde ich, ist Alles gleich. Für mich. Nun ist das schon lange her, daß ich den Pi konfiguriert habe. Ganz weit entfernt: Zu Schluß mußte ich das Ganze als root ausführen und ganz unten die echte Adresse des Rechners angeben.
Aber Ehrlich- warum es zum Schluss funktionierte, weiß ich nicht sicher!

[Laser]

@Ich werde nochmal bei Null anfangen. Mit Debian neu als VM installieren.

[Laser]

@Habe Proxmox neu installiert. Danach ging es.
EDIT: falsches Forum (Proxmox ließ keine neue Debian- VM installieren)
-komplett neu gemacht, Proxmox, Debian, mal sehen wie es weiter geht.

[Laser]

@Was die Ursache für die Fehlfunktion war, kann ich nicht sagen. Es waren mehrere Probleme.

1. Ich konnte unter Proxmox keine VM mit Debian neu installieren. Um nicht eine neue Fehlersuch- Orgie auszulösen, habe ich Proxmox neu installiert. Danach ging es.
2. VM neu. Alle Installationsschritte, auch der Guest-Agent, funktionierten auf Anhieb. Der USB Busmaster für i2c wurde erkannt und funktionierte mit der "alten" Konfig.
   Irgendwo war in den unendlichen Linux- Tiefen ein (mehrere) Fehler. Die zu finden- das ist so, als wenn ich als Einzelperson eine komplette Chemieanlage aus Einzelteilen zusammenbauen will. Fehlerfrei. Das geht sicher, dauert aber mehrere 100 Jahre...
   Manchmal ist Neumachen schneller als Fehlersuche. Da ich Proxmox nur als Testobjekt habe, ist das i.O. Als Produktivumgebung an der Heizung bei -15 °C wäre das schon etwas problematisch. Kommt für mich (lange noch )nicht in Frage.

[Laser]

Heute wieder das gleiche Problem gehabt. IOBroker auf VM installiert. Danach OW Sever installiert. Ging nicht. Alles gelöscht, dann zuerst den OWserver installiert, dann IOBroker. Funktionierte.

[Laser]

Zu früh gefreut. OWServer funktioniert nicht mehr. Das erinnert mich an die Zeiten mit Windows 3.0. War genau so zuverlässig wie das derzeitige Linux- Gedöns. Man hatte immer ein 7cm dickes DOS- Handbuch neben sich liegen. Fehlersuche ohne Ende.

[Thomas Braun]

@laser

Und das Gedöns meldet was genau in den Gedöns-Logs?
Beim Gedöns-Server hat der gedönsige Admin genau wie das Einstellungs-Gedöns eingestellt?

[Laser]

@thomas-braun
In ein Log habe ich noch nicht geschaut. Aber an der SSH Oberfläche:

otto@debian:/etc$ systemctl start owserver
Failed to start owserver.service: Access denied
See system logs and 'systemctl status owserver.service' for details.
otto@debian:/etc$ sudo systemctl start owserver
[sudo] Passwort für otto:
otto@debian:/etc$ systemctl status owserver
● owserver.service - Backend server for 1-wire control
     Loaded: loaded (/lib/systemd/system/owserver.service; enabled; vendor pres>
     Active: failed (Result: signal) since Thu 2022-12-29 09:47:50 CET; 3s ago
TriggeredBy: ● owserver.socket
       Docs: man:owserver(1)
    Process: 638 ExecStart=/usr/bin/owserver --foreground -c /etc/owfs.conf (co>
   Main PID: 638 (code=killed, signal=SEGV)
        CPU: 20ms

[Laser]

Ich kann ja zum Glück zwischen verschiedenen gesicherten Zuständen über Backup hin und herschalten. Ohne IOBroker- OWServer ist über Port 2121 zugänglich. Mit IOBroker nicht (mehr). Hier ohne IOBroker:

otto@debian:~$ sudo sysrtemctl status owserver
sudo: sysrtemctl: Befehl nicht gefunden
otto@debian:~$ sudo systemctl status owserver
● owserver.service - Backend server for 1-wire control
     Loaded: loaded (/lib/systemd/system/owserver.service; enabled; vendor pres>
     Active: active (running) since Thu 2022-12-29 09:55:36 CET; 3min 22s ago
TriggeredBy: ● owserver.socket
       Docs: man:owserver(1)
   Main PID: 485 (owserver)
      Tasks: 3 (limit: 2337)
     Memory: 1.0M
        CPU: 19ms
     CGroup: /system.slice/owserver.service
             └─485 /usr/bin/owserver --foreground -c /etc/owfs.conf

Dez 29 09:55:36 debian systemd[1]: Starting Backend server for 1-wire control...
Dez 29 09:55:36 debian owserver[485]: DEFAULT: ow_opt.c:(780) systemd mode -- i>
Dez 29 09:55:36 debian owserver[485]: DEFAULT: ow_opt.c:(670) systemd mode -- i>
Dez 29 09:55:36 debian owserver[485]: DEFAULT: ow_usb_msg.c:(214) Opened USB DS>
Dez 29 09:55:36 debian owserver[485]: DEFAULT: ow_usb_cycle.c:(119) Set DS9490 >
Dez 29 09:55:36 debian systemd[1]: Started Backend server for 1-wire control.
lines 1-18/18 (END)
● owserver.service - Backend server for 1-wire control
     Loaded: loaded (/lib/systemd/system/owserver.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2022-12-29 09:55:36 CET; 3min 22s ago
TriggeredBy: ● owserver.socket
       Docs: man:owserver(1)
   Main PID: 485 (owserver)
      Tasks: 3 (limit: 2337)
     Memory: 1.0M
        CPU: 19ms
     CGroup: /system.slice/owserver.service
             └─485 /usr/bin/owserver --foreground -c /etc/owfs.conf

Dez 29 09:55:36 debian systemd[1]: Starting Backend server for 1-wire control...
Dez 29 09:55:36 debian owserver[485]: DEFAULT: ow_opt.c:(780) systemd mode -- ignore foreground request
Dez 29 09:55:36 debian owserver[485]: DEFAULT: ow_opt.c:(670) systemd mode -- ignore 'p' option
Dez 29 09:55:36 debian owserver[485]: DEFAULT: ow_usb_msg.c:(214) Opened USB DS9490 bus master at 2:2.
Dez 29 09:55:36 debian owserver[485]: DEFAULT: ow_usb_cycle.c:(119) Set DS9490 2:2 unique id 0x00 (no dev>
Dez 29 09:55:36 debian systemd[1]: Started Backend server for 1-wire control.
~

[Laser]

Auszug aus "/log/messages":

Dec 29 10:20:53 debian owserver[480]: *** WARNING *** The program 'owserver' uses the Apple Bonjour compatibility layer of Avahi.
Dec 29 10:20:53 debian owserver[480]: *** WARNING *** Please fix your application to use the native API of Avahi!
Dec 29 10:20:53 debian owserver[480]: *** WARNING *** For more information see <http://0pointer.de/blog/projects/avahi-compat.html>
Dec 29 10:20:53 debian kernel: [    7.105900] owserver[483]: segfault at 7fe8dc844178 ip 00007fe8dc844178 sp 00007fe8dafc0d18 error 15 in libow-3.2.so.4.0.0[7fe8dc817000+2e000]

Nach was soll ich suchen? Auf dem Raspi läuft IOBroker mit OWFS, auf der VM nicht. Mit identischen OWServer Einstellungen.

[Thomas Braun]

@laser

Wie ist owserver installiert worden?

[Laser]

@thomas-braun
so habe ich mir das in einer Textdatei gespeichert, für später, immer gleiche Vorgehensweise:

- OWFS server installieren und konfigurieren (/etc/owfs.conf):

sudo apt-get install owfs owserver
sudo nano /etc/owfs.conf	 // OW Server
sudo apt-get install owhttpd   // Weboberfläche <IP>:2121
sudo apt-get install i2c-tools // Tools für SSH Konfig

[Laser]

Habe OWFS noch mal auf einen neuen Raspi 3 installiert. Da funktioniert der Zugriff über Port 2121 erst, wenn ich in der Raspi-config 1-Wire aktiviere! Trotz angeschlossenem Busmaster wird damit irgend etwas Geheimnisvolles getan! Evtl. fehlt dieses "Etwas" in der VM.
in /dev gibt es kein i2C-1 oder 2, beim Raspi schon

[Laser]

Auf einem Mini-PC, aber ohne Proxmox- Virtuelle Maschine, funktioniert der Web- Zugriff auf Port 2121 auf Anhieb. IOBroker drauf installiert- geht alles, wie erwartet. Web Interface ist noch vorhanden. Der Wurm muß in der virtuellen Maschine liegen.
EDIT: Proxmox und VM neu installier mit owserver und IOBroker. Alles funktionierte wunderbar bis zum Reboot der VM. Dann ging der owserver nicht mehr.

otto@debian11:~$ sudo systemctl status owserver
[sudo] Passwort für otto:
● owserver.service - Backend server for 1-wire control
     Loaded: loaded (/lib/systemd/system/owserver.service; enabled; vendor pres>
     Active: failed (Result: signal) since Fri 2022-12-30 16:26:56 CET; 4min 11>
TriggeredBy: ● owserver.socket
       Docs: man:owserver(1)
    Process: 468 ExecStart=/usr/bin/owserver --foreground -c /etc/owfs.conf (co>
   Main PID: 468 (code=killed, signal=SEGV)
        CPU: 25ms

Dez 30 16:26:56 debian11 systemd[1]: owserver.service: Scheduled restart job, r>
Dez 30 16:26:56 debian11 systemd[1]: Stopped Backend server for 1-wire control.
Dez 30 16:26:56 debian11 systemd[1]: owserver.service: Start request repeated t>
Dez 30 16:26:56 debian11 systemd[1]: owserver.service: Failed with result 'sign>
Dez 30 16:26:56 debian11 systemd[1]: Failed to start Backend server for 1-wire >
lines 1-14/14 (END)
● owserver.service - Backend server for 1-wire control
     Loaded: loaded (/lib/systemd/system/owserver.service; enabled; vendor preset: enabled)
     Active: failed (Result: signal) since Fri 2022-12-30 16:26:56 CET; 4min 11s ago
TriggeredBy: ● owserver.socket
       Docs: man:owserver(1)
    Process: 468 ExecStart=/usr/bin/owserver --foreground -c /etc/owfs.conf (code=killed, signal=SEGV)
   Main PID: 468 (code=killed, signal=SEGV)
        CPU: 25ms

Dez 30 16:26:56 debian11 systemd[1]: owserver.service: Scheduled restart job, restart counter is at 5.
Dez 30 16:26:56 debian11 systemd[1]: Stopped Backend server for 1-wire control.
Dez 30 16:26:56 debian11 systemd[1]: owserver.service: Start request repeated too quickly.
Dez 30 16:26:56 debian11 systemd[1]: owserver.service: Failed with result 'signal'.
Dez 30 16:26:56 debian11 systemd[1]: Failed to start Backend server for 1-wire control.

[Laser]

Das was mir der Proxmox- Zauberkasten bringen sollte- eine Zeitersparnis beim Testen der Anwendung für die Hausautomatisierung- hat sich nicht erfüllt. Die Suche nach Ursachen von Fehlfunktionen dauert länger, als wenn ich die Software direkt auf einen Klein- PC installiere, statt auf einer virtuellen Maschine. Auf dem PC läuft es, auf der virtuellen Maschine nicht, warum auch immer. Nutzen == Null. Aufwand == xx100 %. Der Klein PC kann winzig sein, mit geringer Leistungsaufnahme. So, als wenn ich einen Eimer Sand 3m mit Kran und Tieflader transportiere (Proxmox auf Superrechner). Das geht natürlich. Oder direkt in die Hand nehme, ohne Hilfsmittel (Mini PC mit Debian und IOBoker). Geht auch. Mit geringerem Aufwand.
Zum Zeitvertreib werde ich mit Proxmox spielen. Zum Arbeiten gibt es bessere Möglichkeiten.

[crunchip]

@laser sagte in Proxmox VM mit IOBroker OWServer:

Alles funktionierte wunderbar bis zum Reboot der VM. Dann ging der owserver nicht mehr.

und der service ist auch korrekt eingetragen, das er starten soll nach einem reboot?

@laser sagte in Proxmox VM mit IOBroker OWServer:

Das was mir der Proxmox- Zauberkasten bringen sollte- eine Zeitersparnis beim Testen der Anwendung für die Hausautomatisierung

tut es auch, jedoch nur, wenn man es richtig anwendet

@laser sagte in Proxmox VM mit IOBroker OWServer:

Auf dem PC läuft es, auf der virtuellen Maschine nicht, warum auch immer

weil virtuell, dazu muss man je nach Anwendung eben noch bestimmte Dinge einrichten.

[Laser]

@crunchip
"und der service ist auch korrekt eingetragen, das er starten soll nach einem reboot?
"bestimmte Dinge tun, Alles richtig machen" geht es auch etwas genauer?

[Laser]

Dieser blaue Busmaster wird über die VM einfach nicht erkannt. Am Bus erscheint er immer als "ausgesteckt". Statt über die ID auch mal an den Steckplatz gebunden.
In die nano /etc/pve/qemu-server/101.conf als usb0: host=2-4,usb3=1
eingetragen. Ein USB Stick wird erkannt, der Busmaster nicht. Egal an welchem PORT ich den anschließe.

[Laser]

Aus reiner Neugier eine VM mit FHEM eingerichtet. Dort funktioniert das Auslesen der Temperaturfühler mit dem Busmaster. Auf Anhieb, ohne daß ich mich großartig in FHEM eingearbeitet habe. Mit den Bordmitteln. Ohne "Verbiegen" irgendwelcher config- Files.
Warum ist das mit IOBroker nicht möglich?

[crunchip]

@laser sagte in Proxmox VM mit IOBroker OWServer:

Aus reiner Neugier eine VM mit FHEM eingerichtet. Dort funktioniert das Auslesen der Temperaturfühler mit dem Busmaster. Auf Anhieb

und was ist an der VM anders und was hat das mit iobroker zu tun?