Adapter: ebus
-
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...
-
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. -
@kanumouse Was funktioniert denn konkret nicht? Gibt es Fehlermeldungen? Was sagt das log?
Auf meinem System (live und test) habe ich keine Probleme... -
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? -
@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?
-
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 sendDas 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.
-
@kanumouse welche Version vom ebusd nutzt du? Hast du den auch aktualisiert? Funktioniert dein write-Befehl in Telnet noch?
-
Ich benutze ebusd- Version 21.2.
direkt mit telnetfunktioniert das Schreiben noch. -
@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. -
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. -
Hat jemand eine Idee, warum ich auf den ebus plötzlich mit telnet nicht mehr schreiben kann?
Das Lesen der Datenpunkte funktioniert einwandfrei. -
Ok, ich habe das Problem gefunden und kann jetzt auch schreiben.
Die ebusd-config habe ich um den Eintrag "accesslevel=*" ergänzt. War also ein Berechtigungsproblem. Warum das vorher funktioniert hat kann ich nicht nachvollziehen. Der Fahler ist also rein zufäälig mit dem Update des ebus-Adapter zu Tage getreten.
Der Adapter funktioniert also ordnungsgemäß.
Danke rene_hm für die Unterstützung! -
HAllo LEute,
ich habe seit gestren das Problem, das ich keine Daten mehr von meine Ebus empfange.
Das Problem scheint der Port zusein
pi@raspberrypi:~ $ sudo ebusctl stop error connecting to localhost:8888 pi@raspberrypi:~ $ sudo ebusctl start error connecting to localhost:8888 pi@raspberrypi:~ $ sudo nano /etc/default/ebusd pi@raspberrypi:~ $ ebusctl --server=192.168.178.48 i error connecting to 192.168.178.48:8888 pi@raspberrypi:~ $ sudo ebusctl info error connecting to localhost:8888 pi@raspberrypi:~ $ sudo ebusctl stop error connecting to localhost:8888 pi@raspberrypi:~ $ sudo ebusctl start error connecting to localhost:8888Egal was ich eingebe ich bekomme immer diese Antwort.
Was ist da los?
Hat sich da die Portfreigabe in der Fritzbox geändert/gelöscht?
Oder ??? ....Danke
-
@timmerx Läuft Dein eBusD ? Was sagen ?
systemctl status ebusd ps aux | grep -i ebusd -
Ich hab dies neuerdings im Log stehen. Was hat das zu bedeuten?
ebus.0 2021-10-03 09:52:08.245 info Terminated (NO_ERROR): Without reason ebus.0 2021-10-03 09:52:08.243 info all http done ebus.0 2021-10-03 09:52:08.162 info found ebusd version 21.2 ebus.0 2021-10-03 09:52:06.724 warn updateObject: not updated bai.messages.SetMode.fields.hwcflowtempdesired.value value: null ebus.0 2021-10-03 09:52:06.721 warn Key : bai.messages.SetMode.fields.hwcflowtempdesired.value, Value : null name SetMode ebus.0 2021-10-03 09:52:06.712 warn updateObject: not updated bai.messages.SetMode.fields.hwctempdesired.value value: null ebus.0 2021-10-03 09:52:06.708 warn Key : bai.messages.SetMode.fields.hwctempdesired.value, Value : null name SetMode ebus.0 2021-10-03 09:52:02.740 info starting. Version 2.3.2 in /opt/iobroker/node_modules/iobroker.ebus, node: v12.22.6, js-controller: 3.3.18 -
@cino ebusd stellt den Datenpunkt zwar zur Verfügung, liefert aber keinen Wert dazu. Ich habe das erst mal als Warnung eingebaut, ist aber nur kritisch, wenn man genau den Datenpunkt benötigt...
-
Hi
bei mir war das Problem, das der Bus nicht gelaufen ist.
-
Hallo in die Runde,
habe ein kleines Problem. Ich habe ein Gesheizung mit Pufferspeicher, Solarkollektoren und Trinkwasseranlage.Daten werden auch alle top geladen.
address 01: master #6 address 03: master #11 address 06: slave #6, scanned "MF=Vaillant;ID=PMS02;SW=0209;HW=8402", loaded "vaillant/06.pms.csv" address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0104;HW=7803", loaded "vaillant/bai.308523.inc", "vaillant/08.bai.csv" address 0a: slave, scanned "MF=Vaillant;ID=PMW01;SW=0206;HW=8302", loaded "vaillant/0a.pmw.hwc.csv" address 10: master #2 address 12: slave, scanned "MF=Vaillant;ID=PMW01;SW=0206;HW=8302" address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0613;HW=6903", loaded "vaillant/15.700.csv" address 26: slave, scanned "MF=Vaillant;ID=VR_71;SW=0104;HW=0503", loaded "vaillant/26.vr_71.csv" address 31: master #8, ebusd address 36: slave #8, ebusd address ec: slave, scanned "MF=Vaillant;ID=SOL00;SW=0613;HW=6903", loaded "vaillant/ec.sol.sc.csv" address ed: slave, scanned "MF=Vaillant;ID=PMS02;SW=0209;HW=8402" address f7: master #20 address fc: slave #20, scanned "MF=Vaillant;ID=PMW01;SW=0206;HW=8302"Jetzt zum Problem. Sowohl in der "vaillant/06.pms.csv"
r,,Ntc1Sensor,Ntc1Sensor,,,,"0500",,,tempsensor,,,Temperature in solar flow (from solar collector) r,,Ntc2Sensor,Ntc2Sensor,,,,"0600",,,tempsensor,,,Temperature in solar back flow (to solar collector) r,,Ntc3Sensor,Ntc3Sensor,,,,"0700",,,tempsensor,,,Temperature in buffer flow (to buffer) r,,Ntc4Sensor,Ntc4Sensor,,,,"0800",,,tempsensor,,,Temperature in buffer back flow (from buffer)als auch in der "0a.pmw.hwc.csv"
r,,Ntc1Sensor,Ntc1Sensor,,,,"0000",,,tempsensor,,,T1 Temperature r,,Ntc2Sensor,Ntc2Sensor,,,,"0100",,,tempsensor,,,T2 Temperature r,,Ntc3Sensor,Ntc3Sensor,,,,"0200",,,tempsensor,,,T3 Temperaturestehen NTC1Sensor, NTC2Sensor und NTC3Senor drin.
Wie kann ich denn bei der Abfrage im ebusd Adapter im ioBroker unterscheiden, welchen er einsammelt.
Aktuell sammelt er Sensor 1-3 nur vom "hwc" ein und nicht vom "pms".
-
@dre83 wie sieht denn das ganze in den Datenpunkten in ioBroker aus? Intern schicke ich ein
read -f Ntc1Sensoran den ebusd.
Du kannst aber auch basierend auf der Doku unter ebusd - Read ein eigenes Kommando bauen, welches du dann auf den Datenpunktebus.0.cmdschreibst.
-
@rene_hm Sorry aber ich verstehe die Frage nicht. Was meinst du mit "wie sieht es in den Datenpunkten aus"?
Ich habe sowohl unter "pms" als auch bei "sc" und "hwc" z.B. den NTC Sensor 1. Allerdings bekomme ich nur für einen NTC1Sensor, einen NTC2Sensor, einen NTC3Sensor und einen NTC4 Sensor die Daten geliefert. Die anderen Sensoren, welche genauso heißen aktualisiert es nicht
Also Umgehungslösung habe ich es aktuell so gelöst, dass ich auf dem Raspberry mit einem Cron-Trigger
sudo crontab -edie Daten jetzt aller 5 Minuten mit dem Raspberry abfrage. Danach werden auch die Daten aller NTC-Sensoren sauber importiert.
*/5 * * * * ebusctl r -c sc NTC1Sensor */5 * * * * ebusctl r -c sc NTC2Sensor */5 * * * * ebusctl r -c sc NTC3Sensor */5 * * * * ebusctl r -c sc NTC4Sensor */5 * * * * ebusctl r -c pms NTC1Sensor */5 * * * * ebusctl r -c pms NTC2Sensor */5 * * * * ebusctl r -c pms NTC3Sensor */5 * * * * ebusctl r -c pms NTC4Sensor */5 * * * * ebusctl r -c hwc NTC1Sensor */5 * * * * ebusctl r -c hwc NTC2Sensor */5 * * * * ebusctl r -c hwc NTC3SensorKann ich auch mehrere Kommandos auf ebus.0.cmd legen?
Wenn ja wie ist dann die Syntax?
