Läuft: Heizung mit eBus-Schnittstelle

[istler]

Bei einem einfachen read liefert der ebusd die Werte aus seinem Cach. Wenn du die Werte direkt vom eBus haben möchtest, musst du die Option -f beim read verwenden.
Gruß
Maik

[guenni]

dann poste doch mal die read Definition. Üblicherweise ist die andere Richtung dann ganz banal.

Ich habe nach einem etwas gründlicherem Studium der Dokumentation (ich weiß, hätte ich schon eher machen sollen:)) auch die Mesagedefinitionen für das Schreiben der Legionellenschutzprogramm-Werte hinbekommen. Hier sind die Definitionen zum Lesen und Schreiben:

Code Auswählen Erweitern


ebusctl define -r "r,700,LegioTag,Legionellen Tag,,15,b524,020000002b00,,s,IGN:4,,,,,s,UIN,0=aus;1=Mo;2=Di;3=Mi;4=Do;5=Fr;6=Sa;7=So;8=Mo-So,,"
ebusctl define  -r "w,700,LegioTag,Legionellen Tag,,15,b524,020100002b00,,,UIN,0=aus;1=Mo;2=Di;3=Mi;4=Do;5=Fr;6=Sa;7=So;8=Mo-So,"
ebusctl define -r "r,700,LegioZeit,Legionellen Uhrzeit,,15,b524,020000002a00,,s,IGN:4,,,,,s,HTM,"
ebusctl define -r "w,700,LegioZeit,Legionellen Uhrzeit,,15,b524,020100002a00,,,HTM,,,,,,BCD,=0,"

John, könntest Du dies in Konfig 15.700 mit aufnehmen?.
Und ich habe noch einen "Änderungswunsch" für eine Konfig-Datei. Der ebusd zieht für meine Heizung die Konfigurationsdatei bai.308523.inc. Die Message-ID für die Heizungsteillast (Register d.00) ist bei mir aber nicht "0704", sondern "6C00". Könntest du das auch ändern, oder zieht der ebusd evtl. die falsche Konfigurationsdatei?
VG
Günni

[john30]

Ich habe nach einem etwas gründlicherem Studium der Dokumentation (ich weiß, hätte ich schon eher machen sollen:)) auch die Mesagedefinitionen für das Schreiben der Legionellenschutzprogramm-Werte hinbekommen. Hier sind die Definitionen zum Lesen und Schreiben:

Code Auswählen Erweitern


ebusctl define -r "r,700,LegioTag,Legionellen Tag,,15,b524,020000002b00,,s,IGN:4,,,,,s,UIN,0=aus;1=Mo;2=Di;3=Mi;4=Do;5=Fr;6=Sa;7=So;8=Mo-So,,"
ebusctl define  -r "w,700,LegioTag,Legionellen Tag,,15,b524,020100002b00,,,UIN,0=aus;1=Mo;2=Di;3=Mi;4=Do;5=Fr;6=Sa;7=So;8=Mo-So,"
ebusctl define -r "r,700,LegioZeit,Legionellen Uhrzeit,,15,b524,020000002a00,,s,IGN:4,,,,,s,HTM,"
ebusctl define -r "w,700,LegioZeit,Legionellen Uhrzeit,,15,b524,020100002a00,,,HTM,,,,,,BCD,=0,"

John, könntest Du dies in Konfig 15.700 mit aufnehmen?.
Und ich habe noch einen "Änderungswunsch" für eine Konfig-Datei. Der ebusd zieht für meine Heizung die Konfigurationsdatei bai.308523.inc. Die Message-ID für die Heizungsteillast (Register d.00) ist bei mir aber nicht "0704", sondern "6C00". Könntest du das auch ändern, oder zieht der ebusd evtl. die falsche Konfigurationsdatei?

poste doch mal dein "scan result", anhand dessen wird die .inc gepickt

[guenni]

poste doch mal dein "scan result", anhand dessen wird die .inc gepickt

pi@raspberrypi:~ $ ebusctl scan result
08;Vaillant;BAI00;0104;7803;21;18;34;0010021924;0001;009260;N7
15;Vaillant;70000;0510;6403;21;18;32;0020242192;0082;050499;N6
ec;Vaillant;70000;0510;6403;21;18;32;0020242192;0082;050499;N6

[john30]

1. Für den Kreis "hc" der Vaillant auroTERM - SOLSY id 26 - scheinen ein paar Set-Befehle zu fehlen. Zumindest, wenn ich das mit dem Kreis "mc" vergleiche. So kann der Betriebsmodus und die Heizkurve erst verstellt werden, wenn die entsprechenden Befehle definiert wurden:

Code Auswählen Erweitern


# Vorlage mc
# w,mc,SetMode,Betriebsart setzen,,50,b505,02,mcmode,m,UCH,0=disabled;1=on;2=off;3=auto;4=eco;5=low,,Mischer Modus
# w,mc,SetHeatingCurve,Heizkurve setzen,,50,b505,0b,curve,m,UIN,100,,Heizkurve
#
# definition für hc
define "w,hc,SetMode,Betriebsart setzen,,26,b505,02,mcmode,m,UCH,0=disabled;1=on;2=off;3=auto;4=eco;5=low,,Heizkreis Modus"
define "w,hc,SetHeatingCurve,Heizkurve setzen,,26,b505,0b,curve,m,UIN,100,,Heizkurve"


Kann man diese Befehle in die allgemeine "Befehlsliste" aufnehmen, damit man sie nicht nach jedem reboot des Pi neu definieren muss?

konntest du die Funktionsfähigkeit der Defs vollständig nachvollziehen?

2. Beim Auslesen der Heizkurven HeatingCurve liefert der ebusd nach dem Schreiben mit "SetHeatingCurve" allerdings weiterhin die alten Werte - die Steuerung hat die neuen Werte über "SetHeatingCurve" direkt übernommen (direkt an der Steuerung geprüft; sowohl für mc als auch hc).
Erst wenn man den Befehlt "HeatingCurve" auch beschreibt, dann wird der Wert wohl aktualisiert und anschließend mit einem read auch ausgegeben. DAbei spielt es scheinbar keine Rolle, welchen Befehl man für "write -c hc HeatingCurve x" eingibt, da dieser nicht geschrieben wird aber für das aktualisieren notwendig ist.

Code Auswählen Erweitern


localhost: write -c hc SetHeatingCurve 0.65
done

localhost: read -c hc HeatingCurve
0.70

localhost: write -c hc HeatingCurve 0.7
done

localhost: read -c hc HeatingCurve
0.65


Update: Das Problem scheint aktuell nur temporär zu sein - ich vermute, dass ebusd nicht immer direkt eine für ihn bekannte Message direkt wieder auf dem Bus sendet, solange er keinen Grund dafür erkannt hat. Das kann mit einem "write" oder auch anderen Messages aufgelöst werden.

solange die read und write Definition nicht exakt den gleichen Namen tragen, weiß ebusd nichts von dem Zusammenhang und beantwortet ein read an HeatingCurve aus dem Cache. da müsstest Du also die Verwendung des Cache beim Lesen unterbinden (read -f). Besser ist es, der Write Definition den gleichen Namen zu geben, dann invalidiert ebusd den read cache bei jedem Schreiben an die Write automatisch.

3. read-Befehle für bestimmte Kommandos liefern den falschen Wert zurück bzw. werden nicht immer ausgeführt. In dem Beispiel werden die beiden Heizkurven für hc und mc auf unterschiedliche Werte eingestellt (Einstellung an der Steuerung direkt geprüft und OK).

Code Auswählen Erweitern


localhost: write -c hc SetHeatingCurve 0.75
done

2019-10-31 22:46:45.355 [update notice] sent write hc SetHeatingCurve QQ=31: 0.75
2019-10-31 22:46:45.360 [main notice] write hc SetHeatingCurve: decode done


localhost: write -c mc SetHeatingCurve 0.70
done

2019-10-31 22:47:40.483 [update notice] sent write mc SetHeatingCurve QQ=31: 0.70
2019-10-31 22:47:40.487 [main notice] write mc SetHeatingCurve: decode done
2019-10-31 22:47:40.494 [bus notice] >3150b505030b46003c<000000>00


localhost: read -c mc HeatingCurve
0.65
# kein ebus send message zu finden - zudem war zuvor 0.60 für mc eingestellt (0.65 war hc)


localhost: read -c hc HeatingCurve
0.65
# jetzt auch keine ebus send message für den hc read zu finden - die 0.65 waren die alte Einstellung


localhost: read -c hc HeatingCurve
0.75

2019-10-31 22:50:28.824 [update notice] sent read hc HeatingCurve QQ=31: 0.75
2019-10-31 22:50:28.831 [bus notice] >3126b509030d3500d1<00064b0046007800c1>00
# Wiederholung nach kurzer Zeit brachte die send message hervor und der hc Wert wurde korrekt ausgegeben

localhost: read -c mc HeatingCurve
0.75

2019-10-31 22:51:33.521 [update notice] sent read mc HeatingCurve QQ=31: 0.75
2019-10-31 22:51:33.528 [bus notice] >3150b509030d3500c8<00064b0046007800c1>00
# anschl. Nochmals für mc ausgelesen - hier wird der Wert des hc zurück gemeldet.


localhost: read -c mc Params
22;19;0.70;mixer;13;0;25;38;0


das ist dann ne cache Antwort, siehe oben.

Hier wird von der Steuerung also der Wert für die mc HeatingCurve nicht korrekt zurück gegeben - auf dem Bus ist bereits der falsche Wert zu sehen '4b' = 75 (5. & 6. Stelle in der Antwort); also scheint das Problem nicht am ebusd zu liegen.
In den "Params" von mc wird der Wert korrekt ausgegeben. Könnte es daher ggf. an einer falschen Adresse bei dem "read -c mc HeatingCurve" liegen? Oder ist das wirklich "nur" ein Bug in der Vaillant Steuerung?

ich tippe hier auf eine Steuerungs-interne Spezialität

Bei anderen Werten habe ich aktuell den gleichen Verdacht - z.B. TempDesiredLow.
Hier wird bei mc auch der Wert von hc zurück gegeben, obwohl er in der Message "Params" richtig hinterlegt zu sein scheint.

Code Auswählen Erweitern



localhost: read -c hc TempDesiredLow
18.0

localhost: read -c mc TempDesiredLow
18.0

localhost: read -c mc Params
22;19;0.70;mixer;13;0;25;38;0


Kennt das Problem jemand und hat ggf. auch eine Lösung? Über die Suche habe ich leider nichts konkretes gefunden...

bei solchen Tests unbedingt immer "read -f ..." benutzen, da sonst der ebusd Cache antwortet.

[john30]

Ich habe nach einem etwas gründlicherem Studium der Dokumentation (ich weiß, hätte ich schon eher machen sollen:)) auch die Mesagedefinitionen für das Schreiben der Legionellenschutzprogramm-Werte hinbekommen. Hier sind die Definitionen zum Lesen und Schreiben:

Code Auswählen Erweitern


ebusctl define -r "r,700,LegioTag,Legionellen Tag,,15,b524,020000002b00,,s,IGN:4,,,,,s,UIN,0=aus;1=Mo;2=Di;3=Mi;4=Do;5=Fr;6=Sa;7=So;8=Mo-So,,"
ebusctl define  -r "w,700,LegioTag,Legionellen Tag,,15,b524,020100002b00,,,UIN,0=aus;1=Mo;2=Di;3=Mi;4=Do;5=Fr;6=Sa;7=So;8=Mo-So,"
ebusctl define -r "r,700,LegioZeit,Legionellen Uhrzeit,,15,b524,020000002a00,,s,IGN:4,,,,,s,HTM,"
ebusctl define -r "w,700,LegioZeit,Legionellen Uhrzeit,,15,b524,020100002a00,,,HTM,,,,,,BCD,=0,"

John, könntest Du dies in Konfig 15.700 mit aufnehmen?.
Und ich habe noch einen "Änderungswunsch" für eine Konfig-Datei. Der ebusd zieht für meine Heizung die Konfigurationsdatei bai.308523.inc. Die Message-ID für die Heizungsteillast (Register d.00) ist bei mir aber nicht "0704", sondern "6C00". Könntest du das auch ändern, oder zieht der ebusd evtl. die falsche Konfigurationsdatei?

so ganz nehme ich die Definition noch nicht ab. insbes. die 0=aus sowie die Länge 4 im UIN weichen von allen anderen bisherigen Defintionen ab. Könntest Du bitte mal die read Message als Hex posten? die solltest du mittels "find -d -h LegioTag" bekommen. Und bitte finde raus, ob 1=Mo wirklich am Montag zum Start der Funktion führt.

[dnlGrande]

Hi John,

erstmal danke für deine Arbeit und deine Hilfe - und sorry, dass ich erst jetzt wieder zum Antworten komme... das mit den cache antworten habe ich dann auch verstanden.

Code Auswählen Erweitern


# Vorlage mc
# w,mc,SetMode,Betriebsart setzen,,50,b505,02,mcmode,m,UCH,0=disabled;1=on;2=off;3=auto;4=eco;5=low,,Mischer Modus
# w,mc,SetHeatingCurve,Heizkurve setzen,,50,b505,0b,curve,m,UIN,100,,Heizkurve
#
# definition für hc
define "w,hc,SetMode,Betriebsart setzen,,26,b505,02,mcmode,m,UCH,0=disabled;1=on;2=off;3=auto;4=eco;5=low,,Heizkreis Modus"
define "w,hc,SetHeatingCurve,Heizkurve setzen,,26,b505,0b,curve,m,UIN,100,,Heizkurve"


konntest du die Funktionsfähigkeit der Defs vollständig nachvollziehen?

Wenn du damit meinst, ob ich alle möglichen Werte mit den Befehlen geprüft habe -> leider nein. Die einzelnen Modis per SetMode habe ich geprüft, aber z.B. noch keine fehlerhaften Eingaben. Bei SetHeatingCurve habe ich auch nicht alle möglichen Daten getestet - nur ein paar relevante Werte zwischen 0,5 und 0,75 mit 0,05 Skalierung.
Aber es handelt sich um bestehende Definitionen, bei denen ich lediglich den circuit und die entsprechende Adresse ausgetauscht - alles andere blieb gleich.
Da ich nur bestehende Definitionen von mc auf hc übernommen habe wollte ich erstmal keine bestehenden Definitionen überschreiben.

Zudem gibt "mc Mode" auch mehr als den aktuellen Modus zurück; daher wollte ich in diese Definition nicht auch noch schreiben (kenn mich ja so schon kaum aus, dann war mir das zu heiß).

Code Auswählen Erweitern


# vergleich der beiden Befehle aus der auto-config für mc Mode und SetMode
# definition von r,mc,Mode
r,mc,Mode,Betriebsart/Temperatur,,50,b504,01,temp0,s,UCH,,°C,Temperatur,mcmode,s,UCH,0=disabled;1=on;2=off;3=auto;4=eco;5=low,,Mischer Modus,days,s,UCH,,,Tage,temp0,s,UCH,,°C,Temperatur,mcmode,s,UCH,0=disabled;1=on;2=off;3=auto;4=eco;5=low,,Mischer Modus,mctype7,s,BI0:7,0=inactive;1=mixer;2=fixed;3=hwc;4=returnincr;5=pool,,Mischer Typ,,s,IGN:1,,,,daynight,s,UCH,0=night;1=day;7=floorpaving,,Tag-/Nachtmodus

#definition von w,mc,SetMode
w,mc,SetMode,Betriebsart setzen,,50,b505,02,mcmode,m,UCH,0=disabled;1=on;2=off;3=auto;4=eco;5=low,,Mischer Modus



Zu mehr bin ich in den letzten Tagen leider nicht gekommen...

Ich würde in nächster Zeit mal versuchen die Definition in eine lokale Config zu schreiben und von dort zu laden, damit sie nach einem reboot auch wieder vorhanden sind... oder hättest du noch einen anderen/ weiteren guten Tip?

Danke und Grüße

[guenni]

so ganz nehme ich die Definition noch nicht ab. insbes. die 0=aus sowie die Länge 4 im UIN weichen von allen anderen bisherigen Defintionen ab. Könntest Du bitte mal die read Message als Hex posten? die solltest du mittels "find -d -h LegioTag" bekommen. Und bitte finde raus, ob 1=Mo wirklich am Montag zum Start der Funktion führt.

Code Auswählen Erweitern

pi@raspberrypi:~ $ ebusctl find -d -h legiotag
700 LegioTag = 3115b52406020000002b00 / 0603002b000000

Aktuell ist der Legionellenschutz ausgeschaltet. Und die Interpretation der Werte (0 bis 8 ) habe ich direkt an der Regelung überprüft (d.h. per "ebusctl w" geändert und dann an der Reglung kontrolliert, und umgekehrt).
Änderung auf Montag:

Code Auswählen Erweitern

pi@raspberrypi:~ $ ebusctl w -c 700 legiotag 1
done
pi@raspberrypi:~ $ ebusctl r legiotag
Mo
pi@raspberrypi:~ $ ebusctl find -d -h legiotag
700 LegioTag = 3115b52406020000002b00 / 0603002b000100

VG
Günni

[guenni]

Nachtrag: die Heizung hat heute zu der definierten Zeit begonnen, das Wasser zu erhitzen; d.h. das Legionellenschutzprogramm wurde gestartet.
VG
Günni

[max78]

Hi,
ich habe auch einen neuen Adapter in Betrieb genommen.
Am Raspi 4 habe ich den ttyebus Driver nicht zum laufen gebracht. Ich schätze die I/O... Adressen liegen dort wo anders.
Am 3B funktioniert es.
Für meine Ochsner OTE3 Wärmepumpe kann ich auch schon die wichtigsten Werte dekodiert.

Leider habe ich am MQTT Bus hin und wieder Probleme das ein 2tes Werte-paar im gleichen Wert auftaucht.
Als Beispiel: der erste Teil bis Temperatur ist ein anderer Wert.

Code Auswählen Erweitern

ebusd/WP-SOLL-IST/02-080-Schaltzyklen
{
     "group": {"value": 130},
     "value": {"value": 0},
     "type": {"value": "0d"},
     "unit": {"value": "02"},
     "max": {"value": 1000},
     "min": {"value": 0},
     "temperature": {"value": 37.7}}{
     "group": {"value": 80},
     "value": {"value": 1},
     "type": {"value": "1d"},
     "unit": {"value": "00"},
     "max": {"value": 1},
     "cycles": {"value": 7807}}
Mit ebusctl find -d schaut alles gut aus.

Code Auswählen Erweitern

WP-SOLL-IST 02-080-Schaltzyklen = 80;1;1d;00;1;7807
WP-SOLL-IST 21-002-Volumstrom = 130;10;0d;34;1000;0;16.4
HZ-SOLL-IST 01-002-Sollwert-heizkreis_Vorlauf = 130;0;0d;02;1000;0;37.7

Keine Ahnung wieso. Hat das jemand schon mal gehabt? Kann das am Config File liegen?

Vielen Dank, Markus

[Reinhart]

ja, das kenne ich, kommt auch bei den Statusmeldungen vor!

Du solltest MQTT2 verwenden und dann beim MQTT2_Server (oder Client wenn du den verwendest) autocreate auf "complex" stellen!
Ich habe da hier einmal zusammen geschrieben.

Hier unten im Bild siehst du die beiden Statusmeldungen mit jeweils gleichen Datenpunkten. Bei Complex, wird dann allerdings auch der erste Part dazu gehängt und kann somit unterschieden werden.

Ach ja, mit jsonmap kannst du dann auch sprechende Namen vergeben so wie im Bild.

Code Auswählen Erweitern

Status01_0_value:_Vorlauf
Status01_1_value:_Ruecklauf
Status01_2_value:_Aussentemp
Status01_3_value:_Warmwasser
Status01_4_value:_WWSpeicher
Status01_5_value:_Pumpenstatus
Status02_0_value:_HWCMode
Status02_1_value:_Maximaltemperatur
Status02_2_value:_ReglerMaxTEMP
Status02_3_value:_ReglerCurrentTemp

LG

[max78]

Das Problem dürfte schon vor FHEM liegen. Bei der Verbindung von EBUSD zu MQTT.

Habe den Beginn des Problems gefunden.
Es werden die Werte von "02-020-Aussentemp-mittel" im nächsten Datensatz "01-007-Soll-Temp-TWV-Vorlauf" wiederholt, obwohl sie überhaupt nichts miteinander zu tun haben.
Und bei "01-007-Soll-Temp-TWV-Vorlauf" sollte nur der zweite Teil stehen sollte.

Mit ebusctl find stimmt alles, in einem MQTT Logging Prog. sieht man das die Daten zusammengehängt sind...

Code Auswählen Erweitern


ebusd/HZ-SOLL-IST/02-020-Aussentemp-mittel
{
     "group": {"value": 20},
     "value": {"value": 1},
     "type": {"value": "0d"},
     "unit": {"value": "02"},
     "max": {"value": 500},
     "min": {"value": -500},
     "temperature": {"value": 6.8}}

ebusd/WP-SOLL-IST/01-007-Soll-Temp-TWV-Vorlauf
{
     "group": {"value": 20},
     "value": {"value": 1},
     "type": {"value": "0d"},
     "unit": {"value": "02"},
     "max": {"value": 500},
     "min": {"value": -500},
     "temperature": {"value": 6.8}}{
     "group": {"value": 135},
     "value": {"value": 0},
     "type": {"value": "0d"},
     "unit": {"value": "02"},
     "max": {"value": 1000},
     "min": {"value": 0},
     "temperature": {"value": 0.0}}

[cs-online]

...etwas off topic, was ist das denn für ein Logging Prog. ? ich stehe nämlich so ein kleinwenig mit Mqtt auf Kriegsfuss und das könnte etwas helfen...

Grüsse Christian

[Reinhart]

@max78

Die Art und Type der Messpunkte ist mir nicht bekannt, spielt aber keine Rolle. Wie gesagt, mit "complex" erhältst du dann 2 verschiedene Readings angelegt und daher sollte es kein Problem darstellen das weiter zu verarbeiten.

Es sieht irgendwie so aus, als würde beim "WP-SOLL-IST/01-007-Soll-Temp-TWV-Vorlauf" hier ein Teil aus dem Cache nochmals gelistet. Teste doch mal und frage vorher was anderes ab. Mit was logst du eigentlich, ist das ein Mosquitto Log?

LG

[Reinhart]

...etwas off topic, was ist das denn für ein Logging Prog. ? ich stehe nämlich so ein kleinwenig mit Mqtt auf Kriegsfuss und das könnte etwas helfen...

Grüsse Christian

also wenn du MQTT2 einsetzt logst du ganz normal in Fhem mit verbose 5. Wenn du Mosquitto einsetzt dann logst du ganz normal mit Mosquitto in der Konsole.
Das sieht dann in etwa so aus wenn was reinkommt (MQTT2)

Code Auswählen Erweitern

2019.11.12 19:23:32 5: in:  PUBLISH: 0(241)(1)(0)(18)ebusd/bai/Status02{(10)     "0": {"name": "hwcmode", "value": "auto"},(10)     "1": {"name": "temp0", "value": 60},(10)     "2": {"name": "temp1", "value": 70.0},(10)     "3": {"name": "temp0", "value": 70},(10)     "4": {"name": "temp1", "value": 48.0}}
2019.11.12 19:23:32 4:   ebusMQTT_10.0.0.6_39188 ebusd_3.3_565 PUBLISH ebusd/bai/Status02:{
     "0": {"name": "hwcmode", "value": "auto"},
     "1": {"name": "temp0", "value": 60},
     "2": {"name": "temp1", "value": 70.0},
     "3": {"name": "temp0", "value": 70},
     "4": {"name": "temp1", "value": 48.0}}
2019.11.12 19:23:32 5: ebusMQTT: dispatch autocreate=complex\000ebusd_3.3_565\000ebusd/bai/Status02\000{\n     "0": {"name": "hwcmode", "value": "auto"},\n     "1": {"name": "temp0", "value": 60},\n     "2": {"name": "temp1", "value": 70.0},\n     "3": {"name": "temp0", "value": 70},\n     "4": {"name": "temp1", "value": 48.0}}

Warum stehst du mit MQTT auf Kriegsfuß, bei MQTT2 geht doch alles von selbst und es stehen außerdem noch Templates zur Verfügung, die formatieren die Readings vollautomatisch.

LG