Neues YouTube-Video: Visualisierung im Devices-Adapter

[DRUROB]

@weissnicht Hi! Danke für den Tip. Tatsächlich ist es wohl so, dass in der 15.700.csv die ich derzeit regulär über den Server via config-Option beziehe, der Wert nicht mehr enthalten ist. Es gibt eine Diskussion auf Github wo dieses Thema bereits diskutiert wird. Aber bisher gibt es noch keine Lösung. VG!

[Nobody else]

Hallo Zusammen,

Folgendes Problem, ich habe eine Vaillant Gastherme und alles erfolgreich eingerichtet, bekomme Daten kann auch steuern, nur würde ich jetzt gern die Daten der Solarthermie abrufen, das scheint ja über VMS01 zu laufen.
Es wird alles unter ebusctl info angezeigt, aber es kommen keine Daten.

LG

[Acidgod]

@rene_hm said in eBus Adapter Vaillant:

@hiltex sagte in eBus Adapter Vaillant:

Vielleicht kannst du das regelmäßige Abfragen ja vereinfachen, indem man diese Einstellung an dem Zahnrad des jeweiligen Datenpunktes vornehmen kann, statt die Bezeichnung händisch in den Instanzeinstellungen vornehmen zu müssen?

Ich habe es nun etwas anders gemacht, aber ich denke das führt auch zum Ziel:

Man gibt den Namen des Gerätes an (hier in meinem Beispiel cc) und drückt auf den Search-Button. Danach erscheinen alle im ebusd konfigurierten Datenpunkte in der Liste. Nun muss man nur noch diejenigen aktiv schalten, die man regelmässig abrufen möchte.
Eine Einschrännkung hat das noch: Die Konfiguration im ebusd heisst nicht automatisch, dass der Parameter im vorliegenden System auch wirklich vorhanden ist...

Moin,

bei mir funktioniert das leider nicht. Das ging zwar schon mal aber ich musste alles neu installieren und jetzt scheint das nicht mehr zu funktionieren.

[Kanumouse]

ich brauche wieder einmal eure Hilfe.
Habe jetzt den iobroker neu auf einem Pi5 unter Trixie aufgesetzt. Jetzt bekomme ich den ebusd nicht zum laufen. auf meinem Pi4 mit Bookworm lief alles problemlos.
Wenn ich jetzt den ebusd starten will erhalte ich folgende Meldungen

pi@TrixiePI:/etc/default $ systemctl start ebusd
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
Authentication is required to start 'ebusd.service'.
Authenticating as: xx
Password:
==== AUTHENTICATION COMPLETE ====
Job for ebusd.service failed because the control process exited with error code.
See "systemctl status ebusd.service" and "journalctl -xeu ebusd.service" for details.

 journalctl -xeu ebusd.service
May 31 14:08:14 TrixiePI ebusd[16539]: /usr/bin/ebusd: error while loading shared libraries: libz.so.1: ELF load command address/offset not page-aligned
May 31 14:08:14 TrixiePI systemd[1]: ebusd.service: Control process exited, code=exited, status=127/n/a
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ An ExecStart= process belonging to unit ebusd.service has exited.
░░
░░ The process' exit code is 'exited' and its exit status is 127.
May 31 14:08:14 TrixiePI systemd[1]: ebusd.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ The unit ebusd.service has entered the 'failed' state with result 'exit-code'.
May 31 14:08:14 TrixiePI systemd[1]: Failed to start ebusd.service - ebusd, the daemon for communication with eBUS heating systems..
░░ Subject: A start job for unit ebusd.service has failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A start job for unit ebusd.service has finished with a failure.
░░
░░ The job identifier is 37494 and the job result is failed.

Ich weiß momentan nicht, wo das Problem liegt?

[Marc Berg]

@Kanumouse sagte:

libz.so.1: ELF load command address/offset not page-aligned

Welche Version hast du aktuell installiert und woher kam das Paket?

Hier die arm64 Version für Trixie nehmen:

https://github.com/john30/ebusd/releases

[Kanumouse]

@Marc-Berg
Ich habe die 64-Bit Version genau von dieser Quelle installiert.

Nach etlichen Recherchen im Internet habe ich jetzt am Ender der Datei "/boot/firmware/config.txt" folgende Zeile eingefügt "kernel=kernel8.img" und den PI gebootet.

Seitdem läuft auch der ebusd!

Inhaltlich kann ich das leider nicht ganz nachvollziehen, aber vielleicht weiß jemand den Hintergrund?

[Thomas Braun]

@Kanumouse sagte:

aber vielleicht weiß jemand den Hintergrund?

Damit wird der entsprechende Kernel erzwungen.
Welcher Kernel lief denn davor auf welcher Hardware und welches kernel-Modul wurde da für ebus herangezogen?

Edit:

Laut

Debian 12 (Bookworm), 11 (Bullseye), and 10 (Buster) install packages for amd64, 386, armv7 (Raspberry Pi 2/3/4), and arm64 (Raspberry Pi 3/4 64 bit) are attached and are also available in the Debian repository as described here.

gibt es kein passendes vorkompiliertes Paket für den Kernel, der in einem Debian 13 Trixie (RPi 5) eigentlich vorgesehen ist. Deswegen muss der Kernel für einen Pi4 erzwungen werden.

[Kanumouse]

@Thomas-Braun
Ok, jetzt bin ich etwas schlauer. Wie kann man das Problem nun grundsätzlich lösen?

[Thomas Braun]

@Kanumouse Das Modul selber bauen oder mit dem Fallback auf das image8 leben.

[Kanumouse]

@Thomas-Braun

Mit dem Modul selbst bauen bin ich überfordert, da werde ich wohl vorläufige mit dem image8 leben müssen.