Adapter: ebus

[Thomas Braun]

@pairo sagte in Adapter: ebus:

ich weis nicht wieso er die csv für die Geräte "ID=7000" und "ID=VMS02" nicht lädt.

Weiß ich auch nicht. Aber ich weiß dass man sich nicht als root anmeldet.

[PaiRo]

wow das ging schnell, für die Abfrage nicht als root?
Bleibt allerdings gleich

[Thomas Braun]

@pairo

Grundsätzlich meldet man sich nicht als root an.

[PaiRo]

@thomas-braun ok

[Glasfaser]

@pairo sagte in Adapter: ebus:

--configpath=/etc/ebusd

Versuche mal Online die Daten zu holen .

EBUSD_OPTS="-d /dev/ttyUSB0 -p 8888  --latency=10000 --receivetimeout=100000 -l /var/log/ebusd.log --configpath=http://ebusd.eu/config/  --scanconfig=full  --httpport=8889 --htmlpath=/var/ebusd/html"

[PaiRo]

@glasfaser

habe es geändert, leider ist es nicht besser geworden:

pi@raspberrypi:~ $ service ebusd status
● ebusd.service - LSB: controls ebusd, the daemon for communication with eBUS heating systems.
   Loaded: loaded (/etc/init.d/ebusd; generated)
   Active: active (running) since Fri 2021-07-02 18:01:03 CEST; 11min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 7643 ExecStart=/etc/init.d/ebusd start (code=exited, status=0/SUCCESS)
    Tasks: 4 (limit: 4915)
   CGroup: /system.slice/ebusd.service
           └─7650 /usr/bin/ebusd --pidfile /var/run/ebusd.pid -d /dev/ttyUSB0 -p 8888 --latency=10000 --receivetimeout=100000 -l /var/log/ebusd.log --configpath=http://ebusd.eu/config/ --s

Jul 02 18:01:03 raspberrypi systemd[1]: Starting LSB: controls ebusd, the daemon for communication with eBUS heating systems....
Jul 02 18:01:03 raspberrypi ebusd[7643]: Starting ebusd: ebusd.
Jul 02 18:01:03 raspberrypi systemd[1]: Started LSB: controls ebusd, the daemon for communication with eBUS heating systems..

eher schlechter:

pi@raspberrypi:~ $ ebusctl i
version: ebusd 21.2.v21.2
signal: acquired
symbol rate: 23
max symbol rate: 130
min arbitration micros: 629
max arbitration micros: 3956
min symbol latency: 4
max symbol latency: 8
reconnects: 0
masters: 3
messages: 214
conditional: 3
poll: 0
update: 10
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0104;HW=7803", loaded "vaillant/bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2
address 31: master #8, ebusd
address 36: slave #8, ebusd
address ed: slave, scanned "MF=Vaillant;ID=VMS02;SW=0108;HW=1703"

ist es normal, dass ich nach einer config Änderung die Heizung aus und wieder einschalten muss?

Ich mache immer:
service ebusd stop
nano /etc/default/ebusd - anpassen
service ebbst start

Danach findet er garnichts mehr. Schalte ich die Heizungsanlage aus und danach wieder ein findet er was - siehe oben ebusctl i

Was mir noch aufgefallen ist, bei mir steht bei der Abfrage service ebusd status in Zeile 9 --pidfile /var/run/ebusd.pid```
CGroup: /system.slice/ebusd.service
└─7650 /usr/bin/ebusd --pidfile /var/run/ebusd.pid -d /dev/ttyUSB0 -p 8888 --latency=10000 --receivetimeout=100000 -l /var/log/ebusd.log --configpath=http://ebusd.eu/config/ --s

das habe ich so noch nirgends gesehen, liegt es evtl. daran?

[Glasfaser]

@pairo
Versuche mal damit ,hier war das gleiche :

https://forum.iobroker.net/topic/29359/ebus-adapter-vaillant/119

und einmal hier :

https://forum.iobroker.net/topic/29359/ebus-adapter-vaillant/135

[PaiRo]

@glasfaser ok schaue ich mir an.

[Rene_HM]

Anscheinend gibt es ein Problem beim Lesen der Daten vom ebusd mit Version 21.2 .

siehe issue im github

Seit Version 21.2 vom ebusd werden teilweise Knoten mit eckigen Klammern im Namen gesendet. Das führt zum Absturz des Adapters. Ich arbeite derzeit an einem workaround. Gleichzeitig habe ich aber ein Ticket bei John30 eröffnet, weil ich mir nicht sicher bin, ob das evtl. ein Problem vom ebusd ist.

Mich würde deshalb interessieren, wer das Problem noch hat und wie sich das auswirkt.
Bei mir stellt sich das Problem im browser so dar:

[Rene_HM]

Im github und NPM liegt die 2.3.2 zum Testen bereit.

siehe auch github

Es gibt folgende Änderungen:

• ebusd in der Version 21.2 wird nun unterstützt
• Datenpunkte, welche als Wert on / off liefern, können nun optional als Boolean interpretiert werden (muss im admin aktiviert werden). Der Datenpunkt im ioBroker ist dann vom Type boolean und liefert true /false. Original war es ein string und lieferte on / off

Feedback ist wie immer willkommen...

[Kanumouse]

@rene_hm

Kann das sein, dass es in dieser Version ei Problem mit dem Schreiben auf dem ebus gibt?
Bisher hatte das bei mir problemlos funktioniert, seit dem update auf die neue Version nicht mehr.

[Rene_HM]

@kanumouse Was funktioniert denn konkret nicht? Gibt es Fehlermeldungen? Was sagt das log?
Auf meinem System (live und test) habe ich keine Probleme...

[Kanumouse]

@rene_hm

Im Log habe ich keine Fehlermeldung gefunden. Das Kommando wird richtigerweise durch mein Script in „cmd“ der ebus-Objekte geschrieben. Wenn die zyklische Abfrage des ebus erfolgt, verschwindet das Kommando auch von dort. Mit telnet kann ich auf port 8888 auch auf den ebusd zugreifen. Alle lesenden Abfragen des ebusd funktionieren auch fehlerfrei. Ich kann momentan das Problem leider nicht weiter eingrenzen.
Was mit noch einfällt und mich gewundert hat: bei der ebus-Objekten ist auch unter „cmd result“ die Beschreibung des write-Befehls zu finden. Ist das richtig?

[Rene_HM]

@kanumouse erstelle mal bitte ein issue in github. Ich schaue mir das nochmal an...

Bei mir sieht das so aus:

und wie erkennst du, dass das Schreiben nicht funktioniert?

[Kanumouse]

@rene_hm

Bei mir steht unter „cmdResult“-Wert das:

usage: write [-s QQ] [-d ZZ] -c CIRCUIT NAME [VALUE[;VALUE]]
or: write [-s QQ] [-d ZZ] -def DEFINITION [VALUE[;VALUE]] (only if enabled)
or: write [-s QQ] [-c CIRCUIT] -h ZZPBSBNN[DD]*
Write value(s) or hex message.
-s QQ override source address QQ
-d ZZ override destination address ZZ
-c CIRCUIT CIRCUIT of the message to send
NAME NAME of the message to send
VALUE a single field VALUE
-def write with explicit message definition (only if enabled):
DEFINITION message definition to use instead of known definition
-h send hex write message:
ZZ destination address
PB SB primary/secondary command byte
NN number of following data bytes
DD data byte(s) to send

Das nichts geschrieben wird sehe ich an den unveränderten Werten, die ich beim Lesen im Log mitlesen kann. Außerdem habe ich sicherheitshalber auch noch direkt an der Heizung kontrolliert. Vorher hat alles problemlos funktioniert, ich konnte z.B. Solltemperatungen, Heizprogramme, Wartungstermine, ect. schreiben.

[Rene_HM]

@kanumouse welche Version vom ebusd nutzt du? Hast du den auch aktualisiert? Funktioniert dein write-Befehl in Telnet noch?

[Kanumouse]

@rene_hm

Ich benutze ebusd- Version 21.2.
direkt mit telnetfunktioniert das Schreiben noch.

[Rene_HM]

@kanumouse und du nutzt in telnet den gleichen Schreibbefehl wie aus deinem script?

Das was als Resultat in cmdResult steht, ist das, was ich vom ebusd als Ergebnis auf die Ausführung des Kommandos erhalte. Wenn der ebusd mit

usage: write  ...

antwortet, will er uns damit sagen, dass die Syntax des Befehls nicht passt. Da ich den Befehl aus dem Datenpunkt "cmd" direkt durchreiche, vermute ich ein Problem mit dem Kommando selbst.
Stelle den Adapter mal auf debug und poste das log.

[Kanumouse]

@rene_hm

Also ich habe das jetzt noch einmal vo meinem anderen PC direkt mit telnet getestet. Ich kann alle Elemente fehlerfrei lesen, habe jetzt aber doch festgestellt, dass ich nicht schreiben kann. Dann kommt immer ERR: Element not found.
Kann z.B. PhoneNumber mit „read -f PhoneNumber“ lesen, aber nicht mit dem Kommando „write -c 470 PhoneNumber xxxxxxx“ schreiben.

[Kanumouse]

@kanumouse

Hat jemand eine Idee, warum ich auf den ebus plötzlich mit telnet nicht mehr schreiben kann?
Das Lesen der Datenpunkte funktioniert einwandfrei.