Läuft: Heizung mit eBus-Schnittstelle

[distel]

Nach der Umstellung und Vereinheitlichung könnte also aus PrEnergyCountHwc1 bspw. ein Hwc1PrimaryEnergyCount werden, wobei ich nicht weiß, was Count und Sum hier für einen Sinn haben.

Sum liefert bei mir irre hohe Werte, die ungefähr durch 85.000 geteilt kWh ergeben. Ähnlich zu einem Gaszähler wird dieser Wert nur größer.
Count hab ich noch nicht geprüft.

[flash91]

Hallo

ich benötige Hilfe beim einrichten von ebusd am Raspberry

akuteller Projekstand:
Platine + USB2TTL Adapter hängen schon am ebus eines Wolf SM1
ebusd debian packages erfolgreich installiert und über

Code Auswählen Erweitern

ebusd -f -c /tmp --logareas bus --loglevel info -d /dev/ttyUSB0
sowie

Code Auswählen Erweitern

ebusctl raw
rieseln die regelmäßigen Sync-Werte (<aa) ein

zwischendurch kommt dann sowas wie

Code Auswählen Erweitern

71 fe 50 17 10 01 01 80 02 1b 00 00 00 00
was ja perfekt passen würde, da der Service 5017 den Solardaten entspricht.

als csv habe ich nur

Code Auswählen Erweitern

ebusd-configuration/ebusd-2.x.x/de/wolf/50.csv
hergenommen und unter "type" alle "w" durch ein "u" für update ersetzt.
Zusammen mit "broadcast.csv", "memory.csv" und "_templates.csv" befinden sich diese im ordner /etc/ebusd

Nun zum Problem: durch

Code Auswählen Erweitern

ebusctl read -c solar temp erhalte ich immer Fehlermeldungen "no data" und mit

Code Auswählen Erweitern

ebusctl find -c solar temp ebenfalls "no data stored"
Dabei sollten sich die Werte doch selbstständig updaten?

Bitte um Hilfe 

[theotherhalf]

Hallo!
Ich bin durch Probleme in der Kommunikation zwischen meiner Vaillant auromatic 620 und meiner Therme ecoTec plus VC 196 3/5 auf diese Seite gestossen.
Sehr interessant!
Mein Problem ist, dass die vom Regler angezeigte Vorlauftemperatur nicht mit der empfangenen Vorlauftemperatur in der Therme übereinstimmt. (ebus Kommunikation).
Um nun etwas genauer zu sehen was da übermittelt wird, wäre es prima wenn ich den Datenverkehr schnüffeln könnte.
Ich verstehe es so, dass ich hierzu einen entsprechenden Adapter benötige und die passenden Dateien für die o.g. Geräte, richtig?
Entschuldigt bitte, dass ich nicht so im Thema stecke, aber vielleicht kann mir einer der Experten das in Kürze beschreiben?
Viele Grüße
Martin

[henry22]

Hallo Martin

ist alles beschrieben in eBus Schaltung in Betrieb nehmen


gruss
Henry22

[amunra]

als csv habe ich nur

Code Auswählen Erweitern

ebusd-configuration/ebusd-2.x.x/de/wolf/50.csv
hergenommen und unter "type" alle "w" durch ein "u" für update ersetzt.
Zusammen mit "broadcast.csv", "memory.csv" und "_templates.csv" befinden sich diese im ordner /etc/ebusd

Werte (aus)lesen kann man mit "r" (Du hast dich für "u" entschieden) und wenn das zyklisch passieren soll, dann hängt man eine Zahl an den Aktionstyp dran. Mögliche Werte für ein Zyklus sind "1-9".
Das aber gerne auch hier zum nachlesen.

[theotherhalf]

Hallo Martin

ist alles beschrieben in eBus Schaltung in Betrieb nehmen


gruss
Henry22

Hallo Henry,

vielen Dank für den Link!
Habe derzeit aber leider gar nicht die Zeit mir den Adapter zu löten. Sonst immer gerne.
Gibt es auch fertige Adapter, die mit der Vaillant Peripherie funken?
Oder gibt es hier im Forum jemanden, der mir seinen evtl. leihen kann (gegen Leihgebühr versteht sich!)

Grüße
Martin

[amunra]

Gibt es auch fertige Adapter, die mit der Vaillant Peripherie funken?

Siehe hier

[flash91]

Werte (aus)lesen kann man mit "r" (Du hast dich für "u" entschieden) und wenn das zyklisch passieren soll, dann hängt man eine Zahl an den Aktionstyp dran. Mögliche Werte für ein Zyklus sind "1-9".
Das aber gerne auch hier zum nachlesen.

Hmm, das Wiki hab ich gelesen und mich extra für "u" entschieden weil es dann folgendes gilt

a passive message that ebusd will listen to in order to recognize updates of field values

Ich würde das so übersetzen, dass ebusd dadurch nur am Bus lauscht und falls mal eben sowas wie

Code Auswählen Erweitern

71 fe 50 17 10 01 01 80 02 1b 00 00 00 00
kommt versteht ebusd, dass es sich um eine Broadcastmeldung vom SM1 handelt, in dem die Solartemperaturen enthalten sind und updated die entsprechenden "field values" unter der Klasse "solar" mit dem Namen "temp".

Wie bereits gesagt funktioniert das leider nicht.
Nebenbeibemerkt ich starte ebusd mit --readonly, da ich vorerst nur lesen möchte.


Falls ich das "u" durch "r1" ersetze erhalte ich

Code Auswählen Erweitern

ERR: invalid address

(wenn ich das richtig verstanden habe dürfte poll aber gar nicht funktionieren weil ja nur --readonly)

Falls ich das "u" durch "r" ersetze erhalte ich

Code Auswählen Erweitern


pi@raspberry:~ $ ebusctl read -c solar temp
ERR: invalid numeric argument

Code Auswählen Erweitern

ebusd --checkconfig
liefert mir auch keine Fehlermeldungen

Bitte um Hilfe.. 

Edit:
habe auch für QQ=71 und für ZZ=fe eingetragen

[jkriegl]

Dein ebusctl read -c solar temp hat doch schon mal besser funktioniert s.o. nur waren keine Daten im cache.
Also versuch es mit ebusctl read -f -c solar temp
Um alle temp csv-Eintragungen herauszubekommen versuch es mit
ebusctl find -f -c solar temp

[flash91]

Dein ebusctl read -c solar temp hat doch schon mal besser funktioniert s.o. nur waren keine Daten im cache.
Also versuch es mit ebusctl read -f -c solar temp
Um alle temp csv-Eintragungen herauszubekommen versuch es mit
ebusctl find -f -c solar temp

Code Auswählen Erweitern

pi@raspberry:~ $ ebusctl read -f -c solar temp
ERR: element not found

Code Auswählen Erweitern

pi@raspberry:~ $ ebusctl find -f -c solar temp
u,solar,temp,,71,fe,5017,,pumpe,m,UCH,188=off;189=on,,SolarPumpe,,m,IGN:1,,,,kollektortemp,m,D2C,,°C,Kollektortemperatur,wwsolartemp,m,D2C,,°C,WW Solartemperatur


versteh ich nicht ganz...

Edit:

Code Auswählen Erweitern

pi@raspberry:~ $ ebusctl info
version: ebusd 2.1.28b50d2
signal: acquired
symbol rate: 20
masters: 1
messages: 14
address 31: master #8, ebusd
address 36: slave #8


Interessant ist, dass hier der master 71 nicht registriert ist
hatte bisher erst einmal die Meldung, dass er einen zusätzlichen master erkannt hat der dann unter ebusctl info mit der Adresse 71 aufgetaucht ist

Habe zuerst vermutet, dass der Broadcast zu selten kommt und ich zu früh mit read abfrage, aber habe mich im raw modus davon überzeugt dass der Broadcast min. jede 30 sek zu sehen ist.

Edit Edit:
Habs noch eine halbe Stunde laufen lassen, bis master 71 endlich registriert war.

Code Auswählen Erweitern

pi@raspberry:~ $ ebusctl info
version: ebusd 2.1.28b50d2
signal: acquired
symbol rate: 20
masters: 2
messages: 14
address 31: master #8, ebusd
address 36: slave #8
address 71: master #9

Allerdings trotzdem die Meldung:

Code Auswählen Erweitern

pi@raspberry:~ $ ebusctl find -v -c solar temp
solar temp = no data stored [ZZ=fe, passive read]


[john30]

Code Auswählen Erweitern

pi@raspberry:~ $ ebusctl read -f -c solar temp
ERR: element not found

Code Auswählen Erweitern

pi@raspberry:~ $ ebusctl find -f -c solar temp
u,solar,temp,,71,fe,5017,,pumpe,m,UCH,188=off;189=on,,SolarPumpe,,m,IGN:1,,,,kollektortemp,m,D2C,,°C,Kollektortemperatur,wwsolartemp,m,D2C,,°C,WW Solartemperatur


versteh ich nicht ganz...

hier habt ihr ziemlich gut aneinander vorbei geschrieben.
also, wenn --readonly aktiviert ist, dann kann ebusd damit keine aktiven Abfragen auf den Bus geben, ergo kannst Du mit ebusctl read wiederum nur noch Daten aus dem ebusd cache abrufen.
Dabei wird ohne Verwendung von "-f" oder "-m ..." ein cache timeout von 5 Minuten zugrunde gelegt.
"ebusctl read -f -c solar temp" geht dann natürlich nicht mehr, weil "-f" ja die Nutzung des cache verhindert.

Interessant ist, dass hier der master 71 nicht registriert ist

das ist in der Tat merkwürdig. Man müsste mal schauen, ob die CRC bei dem Broadcast stimmt. Wenn die nicht stimmt, wird die Nachricht als ungültig angesehen und der Sender auch nicht in die Liste aufgenommen.
Siehst Du denn im Logging von ebusd die Einträge mit "[update notice] update solar temp"?

VG John

[flash91]

Okay ich dachte mit "read -f" wird auch ein passiver read über den bus geforced (um eben nicht aus dem cache zu lesen)

Wenn ich das richtig verstanden habe, wird ein logfile nur über den Dämon erstellt.
Bis jetzt hatte ich immer den service deaktiviert und separat "ebusd -f --readonly" gestartet

Mit "service ebusd start" wird /var/log/ebusd.log erstellt in dem steht:

Code Auswählen Erweitern

2016-05-20 11:21:46.367 [main notice] ebusd 2.1.28b50d2 started
2016-05-20 11:21:46.379 [main notice] found messages: 14 (0 conditional on 0 conditions, 0 poll, 7 update)
2016-05-20 11:21:47.029 [bus notice] signal acquired

Was ich noch nicht verstanden habe:
wenn ich ebusd über "service ebusd start" starte, konfiguriert man dann den Dämon nachträglich über den befehl "ebusd" also z.B. "ebusd --readonly" oder kann das nur beim start durch "service ebusd start --readonly" mitgegeben werden?
"service ebusd start -d /dev/ttyUSB0" liefert bei mir: (ich weiß ttyUSB0 ist eh default)

Code Auswählen Erweitern

2016-05-20 11:33:52.425 [main notice] ebusd 2.1.28b50d2 started
2016-05-20 11:33:52.438 [main notice] found messages: 14 (0 conditional on 0 conditions, 0 poll, 7 update)
2016-05-20 11:33:52.440 [bus error] unable to open /dev/ttyUSB0: ERR: generic device error
2016-05-20 11:34:02.441 [bus error] unable to open /dev/ttyUSB0: ERR: generic device error
2016-05-20 11:35:42.128 [main notice] SIGTERM received
2016-05-20 11:35:42.230 [main notice] ebusd stopped

danach nochmal gestartet erhielt ich

Code Auswählen Erweitern

2016-05-20 11:35:47.114 [bus notice] new master 71, master count 2
2016-05-20 11:35:56.582 [bus error] send to 76: ERR: read timeout, retry
2016-05-20 11:35:56.715 [bus error] send to 76: ERR: CRC error, retry
2016-05-20 11:35:56.864 [bus error] send to 76: ERR: CRC error, retry
2016-05-20 11:35:57.026 [bus error] send to 76: ERR: CRC error
2016-05-20 11:35:57.026 [main error] scan config 76 message: ERR: CRC error

seltsam dass jetzt "[main notice] ebusd 2.1.28b50d2 started" fehlt...
und warum zu 76 gesendet wird...

danach nochmal service ebusd neugestartet erhielt ich nur noch
ERR: generic device error

also sudo reboot und
"service ebusd start -d /dev/ttyUSB1" pobiert. lieferte ebenfalls

Code Auswählen Erweitern

2016-05-20 12:00:42.722 [main notice] ebusd 2.1.28b50d2 started
2016-05-20 12:00:42.732 [main notice] found messages: 14 (0 conditional on 0 conditions, 0 poll, 7 update)
2016-05-20 12:00:42.760 [bus notice] signal acquired
obwohl ttyUSB1 nichts zugewiesen ist, schätze mal die parameter nach service ebusd start werden verworfen
auch nach 15 min laufzeit steht nicht mehr info im logfile vorhanden

Edit:

und nein leider taucht nirgendwo "[update notice] update solar temp" auf 

[john30]

Okay ich dachte mit "read -f" wird auch ein passiver read über den bus geforced (um eben nicht aus dem cache zu lesen)

Wenn ich das richtig verstanden habe, wird ein logfile nur über den Dämon erstellt.
Bis jetzt hatte ich immer den service deaktiviert und separat "ebusd -f --readonly" gestartet

Mit "service ebusd start" wird /var/log/ebusd.log erstellt in dem steht:

Code Auswählen Erweitern

2016-05-20 11:21:46.367 [main notice] ebusd 2.1.28b50d2 started
2016-05-20 11:21:46.379 [main notice] found messages: 14 (0 conditional on 0 conditions, 0 poll, 7 update)
2016-05-20 11:21:47.029 [bus notice] signal acquired

Was ich noch nicht verstanden habe:
wenn ich ebusd über "service ebusd start" starte, konfiguriert man dann den Dämon nachträglich über den befehl "ebusd" also z.B. "ebusd --readonly" oder kann das nur beim start durch "service ebusd start --readonly" mitgegeben werden?

oha, da fehlts ja wohl noch an ein paar grundlegenden Kenntnissen zum Thema Linux / Services... Vielleicht magst du dich damit erst einmal vertraut machen?
kurz gesagt: ebusd ist ein Dienst, der im Hintergrund läuft. Auf einem Interface (ttyUSB*) kann natürlich nur einer gleichzeitig sinnvoll zugreifen. Wenn Du also ebusd im Vordergrund startest "-f" und gleichzeitig durch das System als Dienst starten lässt, kann das schlecht funktionieren.

[flash91]

Ja bin ein relativer Frischling was Linux betrifft. (und ja etwas peinlich dass ich Dämon statt Daemon geschrieben habe )
Aber ich hab ja auch geschrieben, dass ich den Dienst bisher immer deaktiviert habe bevor ich ebusd im Vordergrund ausgeführt habe.

Ich denke den Unterschied zwischen "ebusd -f" und "service ebusd start" habe ich verstanden.
(im Terminalfenster auf Abarbeitung des Programms gewartet und als Hintergrundprozess ausgeführt)
Mich wunderte warum "service ebusd start -d /dev/ttyUSB1" funktionierte, da ich dachte einem Hintergrundprozess werden die Parameter auf die gleiche Weise übergeben wie einem Prozess im Vordergrund.

Dennoch:
glaube ich das meine Linuxschwäche vorerst nichts mit dem jetzt bestehenden Problem zu tun hat 
(kein field value update)

Worauf ich nach dem erfolgreichen auslesen des Ebus hinaus wollte:
Ich habe zwei seperate Wolf SM1 Module, würde gerne über das Interface ttyUSB0 das 1. Modul durch einen ebusd Prozess auslesen und über ttyUSB1 das 2. Modul und dann die Prozesse so konfigurieren, dass sie auf unterschiedlichen Ports lauschen, um sie getrennt in einem python skript mit telnet anzusprechen und die jeweiligen Werte auszulesen.

Für Vordergrundprozesse ist es mir klar:
zwei Terminalfenster öffnen, im 1. "ebusd -f -d /dev/ttyUSB0 -p 8888" und im 2. "ebusd -f -d /dev/ttyUSB1 -p 8889"

Erst jetzt kommt erst meine Linuxschwäche zu tragen, da ich nicht weiß wie ich Linux erkläre im Hintergrund denselben Prozess zweimal mit unterschiedlichen Parametern zu starten.

Ich würde mich natürlich riesig freuen wenn du mir bei beiden Problemen behilflich sein kannst 

[jamesgo]

Hallo flash91,

ein sytemdienst wird durch ein start/stop script definert. Für den ebusd ist das /etc/init.d/ebusd.
Dieses Script liest /etc/default/ebusd um parameter für den ebusd zu bekommen.

Wenn du also zwei ebus adapter an zwei unterschiedlichen Heizungssystemen hast, dann musst du z.B. einen ebusd2 systemdienst erstellen.
(/etc/init.d/ebusd2 erstellen; /etc/default/ebusd2 erstellen, mit dem Befehl "update-rc.d ebusd2 enable" den systemdienst ebusd2 erstellen und starten)

Du solltest dir dann aber auch über regeln für udev gedanken machen da linux evlt. auch mal die devicenamen für deine adpater verdreht.

Grüße
Andy