Läuft: Heizung mit eBus-Schnittstelle

Begonnen von Prof. Dr. Peter Henning, 29 November 2014, 13:36:59

Vorheriges Thema - Nächstes Thema

john30

Zitat von: Prof. Dr. Peter Henning am 21 Februar 2016, 10:45:20
Allerdings finde ich in den Konfigurationsdateien aus dem Github ein paar Inkonsistenzen.

Beispiel: In der bai00 HW7401 steht überall als Datentyp temp, in der _templates hingegen temps
Beispiel: In der _templates selber wird mal temps, mal temp als Datentyp verwendet.
das liegt schlicht daran, dass derzeit der Name des Templates als Feldname übernommen wird. Somit wird also ein "temps", was natürlich eine Temperatur darstellt, auch also solche bezeichnet.
Seit Mitte letzten Jahres unterstützt die _templates.csv die Angabe des Namens, wie er dann in der Nachricht verwendet werden soll (z.B. so: "temps:temp,SCH,,°C,Temperatur"). Somit könnte man das relativ einfach gerade ziehen.
Das würde ich auch übernehmen, wenn keiner was dagegen hat.

Zitat von: Prof. Dr. Peter Henning am 21 Februar 2016, 10:45:20
Außerdem sind die Namensgebungen der Kommandos manchmal etwas optimierbar - ist das jeweils Deine Formulierung, oder kommt das aus der Vaillant-DB ??
Die Namen werden aus der MDB genommen und durchlaufen eine umfangreiche Transformation zur Vereinheitlichung, die derzeit aus rund 150 Regeln besteht. Somit wird bspw. aus dem Suffix "TopTemp" ein "TempTop" usw.
Nachdem mir aber die Zeit fehlt, alle 36 CSVs mit fast 3000 Definitionen dahingehend zu überpüfen, bin ich hier auf Feedback angewiesen.

Zitat von: Prof. Dr. Peter Henning am 21 Februar 2016, 10:45:20
Beispiel: Die Solltemperatur wird immer als ...Desired... bezeichnet, die Solldrehzahl allerdings mit ...Target...
Hierfür kann ich problemlos eine neue Transformationsregel einführen

Zitat von: Prof. Dr. Peter Henning am 21 Februar 2016, 10:45:20
Beispiel: Bei IonisationVoltageLevel ist die Bezeichnung verdoppelt (Eine Spannung ist immer ein Wert, das "Level" ist überflüssig), hingegen sollte es z.B. statt CirPump besser CircPumpStatus heißen.
Ersteres ist auch kein Problem.
Die "CirPump" heißt urspr. "CirculationPump_DK" und wird derzeit durch die Regeln ("_DK" verwerfen, "Circulation" kürzen auf "Cir") in "CirPump" umgesetzt. Da noch einen "Status" (oder "State"?) anzuhängen ist auch machbar. dann muss ich nur prüfen, ob es auch einen "Pump" Suffix gibt, der keinen Status darstellt.
author of ebusd

Prof. Dr. Peter Henning

ZitatHierfür kann ich problemlos eine neue Transformationsregel einführen

Prima, das vereinfacht die Arbeit. Folgender Vorschlag zur Systematisierung:

Name =

[Wenn nötig, Name des Kreislaufs = Hc,Hc1..n,Hwc,Mc,Sc,Sc1..n][Gerät = Burner,Storage,Pump,Fan,Gasvalve etc.oder (logischer )Ort = Flow,Return,Outside][Option Prozess, z.B. Postrun][Was wird gemessen/gesetzt = Temp,Pow(er),Rate,Freq(uency)/Speed,Faults,Time][Optional Art der Messung/Festlegung = Desired,Max,Min,Av(erage),Switch]

LG

pah

Sven77

Zitat von: john30 am 20 Februar 2016, 14:54:00
Hier hängt die CSV nicht nur von ID, HW und SW aus dem Ident Telegramm ab, sondern zusätzlich auch noch von der Produktnummer sowie einer zweiten Softwareversion.
Das macht die Angelegenheit sehr eklig und ich überlege noch, wie ich das am besten in die CSVs einkippen kann.
Ich weiß jetzt nicht, ob Du alles aus der MDB extrahieren kannst. Aber falls Du hier Rückmeldung brauchst, hier ausdrücklich meine Bereitschaft dazu (falls Du nicht auch eine icoVIT156/3-7 hast):
address 08: slave #3, scanned "MF=Vaillant;ID=BAI00;SW=0902;HW=7401", loaded "vaillant/08.bai.HW7401.csv"
VG, Sven

Prof. Dr. Peter Henning

#1548
Hallo John,

interessanter Effekt. In der csv-Datei steht

Zitat
*hwc,hwc,,,,25,B504,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
hwc,,Mode,SP1.TagesTemp/Mode,,,,01,,,temp0;hwcmode;IGN:3;HEX;IGN;onoff;IGN,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,

Die entsprechende Nachricht geht auch sauber als 1025b5040101 heraus und wird ordentlich mit 1+9 Byte  09370300000283000100 beantwortet. Allerdings spuckt ebusd eine Fehlermeldung aus:

Zitat2016-02-22 19:42:22.865 [update error] unable to parse hwc Mode from 1025b5040101 / 09370300000283000100: ERR: invalid position

Aus irgendeinem Grund wird das 2. Byte (0x37 = 55) nicht richtig gelesen. Nimmt man aus der Konfigurationsdatei alles außer dem temp0 heraus (ist als UCH definiert), also
Zitat
*hwc,hwc,,,,25,B504,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
hwc,,Mode,SP1.TagesTemp/Mode,,,,01,,,temp0,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
gibt es zwar keine Fehlermeldung, aber bekommt man als Wert 210 statt 55 angezeigt.

Edit: Klar, es ist das "w" in der Abkürzung "hwc" - das wird eben nicht mehr als default "r" interpretiert. OK, war ein Versuch.

LG

pah

Sven77

Eine kleine Umfrage...

Ich versuche gerade mit FHEM warm zu werden - bisher nutz(t)e ich CCU.io, was mir aber zu RAM-hungrig ist.
Die ebusd-Anbindung kann ja über ECMD oder GAEBUS erfolgen - welches nutzt ihr so, oder gibt es noch weitere?

Bei ECMD ist mir irgendwie zu viel Handarbeit nötig... (mind. 4 Konfig-Zeilen *pro* Wert, mindestens 3 Zeilen in externer Class-Datei allein zum Lesen), außerdem landen die Werte nicht in meinem DbLog!
GAEBUS läuft fast unverändert mit den normalen CSVs und lässt sich zusammenklicken, aber ermöglicht keine Abfrage von kombinierten Werten ("22.5°C;ok") und kann die Werte nicht einzeln im WebGUI darstellen?!

Gibt es irgendeine gute Möglichkeit, die alles kombiniert?
- (selektives) Hinzufügen aller definierten ebusd-Werte
- Festlegen des Zahlenformates (Anz. Nachkommastellen)
- Logging der Änderung (!) von Werten ins DbLog

Oder gibt es eine Art Wizard zur Konfiguration von ECMD mit der Class-Datei?
VG, Sven

Reinhart

@Sven77

eigentlich hast du dir schon alles selbst beantwortet und die Vor- und Nachteile beider Methoden richtig erkannt.
GAEBUS ist einfach aber nicht so flexibel. Ich verwende hauptsächlich ECMD wegen deiner erwähnten Vorteile, außerdem steuere ich die Abfragen mit 2 Timern, weil es ja nicht so wichtige Datenpunkte gibt die ich nicht so oft brauche (Druck und irgendwelche Errorcounter etc.).

Beim GAEBUS kommst du schnell in Versuchung zu viel zu erfassen dann ist halt der eBus ständig damit beschäftigt diese abzufragen.

Die Arbeit bei ECMD hält sich in Grenzen (Copy und Paste eines bestehenden Define mit ein paar spezifischen Anpassungen) und wenn du mit GAEBUS weiter auswerten oder verarbeiten willst ist es fast mehr Aufwand.
Mir ist schon aufgefallen das gerade Einsteiger mit ECMD besser zurecht kommen als mit GAEBUS, aber das muss ohnehin jeder selbst wissen was er bevorzugt und das kann man erst sagen wenn man beides probiert hat.

In der Praxis ändere ich an den einmal definierten Werten nichts mehr wenn alles stabil läuft.

zu deinen Fragen:
Gibt es irgendeine gute Möglichkeit, die alles kombiniert?- ja beide System gleichzeitig anwenden
- (selektives) Hinzufügen aller definierten ebusd-Werte - nur bei GAEBUS
- Festlegen des Zahlenformates (Anz. Nachkommastellen)- nur bei ECMD gut handelbar
- Logging der Änderung (!) von Werten ins DbLog- bei ECMD normales (Db)Filelogging unter Fhem, braucht man ja zur Anzeige der Plots

Oder gibt es eine Art Wizard zur Konfiguration von ECMD mit der Class-Datei? - außer dem Installer ist mir nichts bekannt

LG
Reinhart
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

hasenhirn

Hallo Seven77,

ich habe genau das gleich Problem da ich ja auch blutiger Anfänger bin.
Den Ebusd am laufen zu haben und erste Werte mit FHEM abfragen zu können ist schon mal ein Erfolg  ;D
Hier bin auch total dankbar für die super Unterstützung hier aus dem Forum und vor allem von John  :)
Zur Zeit lese ich mich in Perl ein um die ECMD-Abfragen etwas nach meinem Geschmack anpassen zu können.
Ebusd, FHEM und Perl zu erlernen ist im Moment jede Menge Stoff auf einmal  :P
Zu allem überfluss hatte ich Zeit als ich auf die Teile und die Platinen für den ebus gewartet habe und jetzt wo die Platinen laufen, komme ich kaum noch dazu  :(
Na ja, ich kämpfe mich so durch und suche mir hier im Forum dies und das zusammen.
Reinhart macht mit seinen Anleitungen auch eine super Arbeit und das bringt mich auch gut vorran ( auch hier mal danke an der Stelle  ;) )

Gruß

Thomas

Reinhart

@hasenhirn

Danke fürs Lob!

wenn du dich mit ECMD und den vielen Möglichkeiten näher befassen willst, dann sieh dir die Beispiele von pah im Wiki genauer an (ECMD Classdefinition Heizkreis), da kannst du am meisten davon lernen welche Varianten hier machbar sind. Die Commands stimmen zwar in der Zwischenzeit nicht mehr ganz und müssen noch überarbeitet werden, aber von der Programmiertechnik kann man sich einiges abschauen und lernen.

LG

FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

Sven77

Zitat von: Reinhart am 23 Februar 2016, 10:29:41Oder gibt es eine Art Wizard zur Konfiguration von ECMD mit der Class-Datei? - außer dem Installer ist mir nichts bekannt

Ohh - vielen Dank!!
Ich war von den anderen Punkten so enttäuscht (ja - copy&paste geht, aber gerade zum Warmwerden klicke ich gern erstmal etwas zusammen), dass ich den Link glatt übersehen hatte!

Das sieht ja sehr vielversprechend aus, das probiere ich unbedingt mal aus - dank Dir!

Sven
VG, Sven

istler

Hallo zusammen,

ich habe eine Frage zum ebusd:
Der Empfang klappt, ich kann aber nichts senden, er empfängt immer nur Fehler:
2016-02-25 23:02:23.271 [bus notice] <aa
2016-02-25 23:02:23.317 [bus notice] <aa
2016-02-25 23:02:23.317 [bus notice] >ff
2016-02-25 23:02:23.338 [bus notice] <ff
2016-02-25 23:02:23.338 [bus notice] >08
2016-02-25 23:02:23.348 [bus error] send to 08: ERR: read timeout, retry
2016-02-25 23:02:23.363 [bus notice] <08
2016-02-25 23:02:23.363 [bus notice] <f5
2016-02-25 23:02:23.946 [bus notice] <aa
2016-02-25 23:02:23.946 [bus notice] >ff
2016-02-25 23:02:23.967 [bus notice] <ff
2016-02-25 23:02:23.967 [bus notice] >08
2016-02-25 23:02:23.977 [bus error] send to 08: ERR: read timeout, retry
2016-02-25 23:02:23.992 [bus notice] <08
2016-02-25 23:02:23.992 [bus notice] <f5
2016-02-25 23:02:24.576 [bus notice] <aa
2016-02-25 23:02:24.576 [bus notice] >ff
2016-02-25 23:02:24.597 [bus notice] <ff
2016-02-25 23:02:24.597 [bus notice] >08
2016-02-25 23:02:24.607 [bus error] send to 08: ERR: read timeout
2016-02-25 23:02:24.607 [main error] hex read scan.08 ident: ERR: read timeout
2016-02-25 23:02:24.622 [bus notice] <08
2016-02-25 23:02:24.623 [bus notice] <f5
2016-02-25 23:02:25.206 [bus notice] <aa
2016-02-25 23:02:25.207 [bus info] poll cmd: ffecb509030d0100
2016-02-25 23:02:25.207 [bus notice] >ff
2016-02-25 23:02:25.228 [bus notice] <ff
2016-02-25 23:02:25.228 [bus notice] >ec
2016-02-25 23:02:25.237 [bus error] poll sc WS1 failed: ERR: read timeout
2016-02-25 23:02:25.253 [bus notice] <2c
2016-02-25 23:02:25.253 [bus notice] <f5

Mein eBus-Adapter hängt am Standard COM1-Port. :-)
Gibt es evtl. sowas wie eine "brute foce" Methode beim Schreiben?
Lesen klappt ohne Probleme.

Gruß
Maik

Reinhart

@istler

Ja da scheint deine Hardware defekt zu sein. Ist so wie hier dargestellt. Kommt jetzt darauf an was du für einen eBus Adapter benutzt, bei einem Fertiggerät bleibt dir eh nichts anderes übrig als es einzusenden, bei Eigenbau musst du den Fehler suchen, kann aber nicht viel sein weil die Schaltung ja sehr einfach aufgebaut ist (kommt jetzt drauf an welche Schaltung du verwendest).


Da ja bei dir der Empfang tadellos funktioniert aber nach dem Senden keine Antwort kommt (Timeout), kann man davon ausgehen das dein Sendesignal nicht weg geht.


Bei dem oben verlinkten Beispiel war die Zenerdiode defekt (bei Schaltung pah)!


LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

istler

@Reinhart: Danke! Der eBus-Adapter läuft inzwischen, die Hardware ist i. O. Der COM-Port vom Motherboard hat Probleme (UART-Buffer?) gemacht. Ich habe den eBus-Adapter jetzt an einen USB/RS232-Adapter gehängt und nun klappt auch das senden! :-)

Nun kommt aber meine nächste Frage:
Wie bekomme ich die JSON-Dateien über die HTTP-Schnittstelle des ebusd heraus? Der Daemon läuft bei mir mit folgenden Parametern:
root      4774  0.4  0.0 320340  1948 ?        Ssl  11:27   0:07 ebusd -s --device=/dev/ttyUSB1 --loglevel=info --httpport=8020 --htmlpath=/var/lib/ebusd/html
Das Verzweichnis /var/lib/ebusd/hml ist leer!? Wenn ich eine Verbindung mit dem Browser auf den ebusd-http-Port machen. Erhalte ich nur eine leer Seite!?
Im Log steht dazu nur dies:
2016-02-26 11:52:57.287 [network info] [00001] HTTP connection opened 192.168.1.63
2016-02-26 11:52:57.288 [network info] [00001] connection closed
2016-02-26 11:52:58.291 [network info] [00002] HTTP connection opened 192.168.1.63
2016-02-26 11:52:58.292 [network info] [00002] connection closed
2016-02-26 11:52:59.139 [network info] [00003] HTTP connection opened 192.168.1.63
2016-02-26 11:52:59.140 [network info] [00003] connection closed


Decodieren tut der ebusd aber:
2016-02-26 12:00:18.155 [bus notice] poll sc WS1: 26.12;ok
2016-02-26 12:00:20.646 [update notice] update bai Mode QQ=10: standby
2016-02-26 12:00:22.107 [update notice] update hc SumFlowSensor QQ=10: 26.12;ok
2016-02-26 12:00:23.697 [update notice] update bai Status01 QQ=10: 27.0;26.0;-;-;-;off
2016-02-26 12:00:28.745 [update notice] update hc DateTime QQ=10: ok;12:00:15;26.02.2016;4.938
2016-02-26 12:00:30.203 [bus notice] poll sc TempWaterStorage: 39.44;27.88;-;-;-
2016-02-26 12:00:30.786 [update notice] update bai Mode QQ=10: standby
2016-02-26 12:00:32.246 [update notice] update hc SumFlowSensor QQ=10: 26.12;ok
2016-02-26 12:00:32.596 [update notice] update sc swStatus QQ=10: 0;off;-;0
2016-02-26 12:00:33.813 [update notice] update bai Status01 QQ=10: 27.0;26.0;-;-;-;off
2016-02-26 12:00:35.276 [update notice] update sc Status QQ=10: 30;00;off;45;0


Das Info-Kommando auf der Telnet-Schnittstelle liefert dies:
version: ebusd 2.0.0ea7efc
signal: acquired
symbol rate: 34
masters: 3
messages: 685
address 03: master #3
address 08: slave #3, scanned "MF=Vaillant;ID=BAI00;SW=0706;HW=7401", loaded "vaillant/08.bai.csv"
address 10: master #6
address 15: slave #6, scanned "MF=Vaillant;ID=UI   ;SW=0501;HW=6201", loaded "vaillant/15.ui.csv"
address 23: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/23.solsy.cc.csv"
address 25: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/25.solsy.hwc.csv"
address 26: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/26.solsy.hc.csv"
address 50: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/50.solsy.mc.csv"
address ec: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/ec.solsy.csv"


Hat jemand eine Idee? Hab ich was falsch konfiguriert?

Gruß
Maik


Reinhart

das ist klar, wenn die Com Schnittstelle nicht funktioniert hast du den selben Effekt!

Warum willst du über httpmod die JsonDaten filtern, das wäre ja äußerst umständlich?
Wenn du den HTTP Modus (die IP wo der ebusd läuft eingeben + Port) nutzen willst, dann erhältst du ja nur eine grafische Ausgabe (siehe Bild).

Ich glaube du solltest in erster Linie einmal diesen Thread hier lesen, dann wird dir vieles klarer was du jetzt mit den Daten anfangen kannst. Außerdem gibt es hier noch einen Installer der dir einige Arbeit abnehmen kann. Um Daten abzufragen auszuwerten gibt es ECMD und GAEBUS, beides ist im obigen Link beschrieben und einfach zu konfigurieren.


LG
Reinhart
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

istler

Hallo Reinhart,

also eigentlich ist JSON gar nicht schlecht und schon gar nicht umständlich. :-) Ich möchte ja auch nicht mit fhem daran.
Laut edusd Doku liefert der Daemon über die http-Schnittstelle die JSON-Datei:
ZitatIn addition to the command line style client interface, ebusd also supports an HTTP port serving the data in JSON format.

Gruß
Maik

amunra

Hallo Maik,
ein paar Beispiele findest Du hier (Den Inhalt einfach in das Verzeichnis: /var/lib/ebusd/html kopieren).
Viele Grüße
Arthur