Läuft: Heizung mit eBus-Schnittstelle

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

Vorheriges Thema - Nächstes Thema

sua

Zitat von: Jojo11 am 13 April 2016, 19:58:28
...bei der Calormatic 470f, mcOperatingMode (zumindest hieß der damals so), Register 2F00.
hwmode2   UCH   0=off;1=manual;2=auto
...
Nachtrag:
5 scheint Sommerbetrieb zu sein.
Hallo,

in meiner 15.470.csv steht dazu:
r;w,,Hc1OPMode,Betriebsart Heizkreis 1,,,,"2F00",,,UCH,2=auto;3=on;4=night;5=summer,,operation mode of the first heating circuit,,,

Das könnte dann zu:
0=off;1=manual;2=auto;3=on;4=night;5=summer
zusammenwachsen...

LG,
sua

Jojo11

Danke!

schöne Grüße
Jo

Gesendet von meinem Nokia 8210


wollet42

#1667
Hallo,

ich versuche gerade vom rein lesenden Betrieb zum schreibenden Betrieb zu wechseln.

Als erstes habe ich mir den WW Mode ausgesucht, klappt aber leider nicht.

Device:

localhost: info
version: ebusd 2.0.3b6f385
signal: acquired
symbol rate: 74
masters: 3
messages: 493
address 10: master #6
address 15: slave #6, scanned "MF=Vaillant;ID=UI   ;SW=0307;HW=6201", loaded "vaillant/15.ui.csv"
address 23: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0302;HW=6301", loaded "vaillant/23.solsy.cc.csv"
address 25: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0302;HW=6301", loaded "vaillant/25.solsy.hwc.csv"
address 26: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0302;HW=6301", loaded "vaillant/26.solsy.hc.csv"
address 3f: master #15
address 44: slave #15, scanned "MF=Vaillant;ID=SOLSY;SW=0302;HW=6301"
address 50: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0302;HW=6301", loaded "vaillant/50.solsy.mc.csv"
address ec: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0302;HW=6301", loaded "vaillant/ec.solsy.sc.csv"


ebusctl command:
localhost: read -c hwc OperatingMode2
auto

localhost: write -c hwc OperatingMode2 off
done

localhost: read -c hwc OperatingMode2
auto


im Log sehe ich folgendes:
...
2016-04-26 18:31:50.325 [main debug] >>> write -c hwc OperatingMode2 off
2016-04-26 18:31:50.325 [bus info] send message: 3125b509040e2b0002
2016-04-26 18:31:50.326 [network debug] [00002] wait for result
2016-04-26 18:31:50.337 [bus debug] switching from ready to send command
2016-04-26 18:31:50.400 [bus debug] switching from send command to receive command ACK
2016-04-26 18:31:50.405 [bus debug] switching from receive command ACK to receive response
2016-04-26 18:31:50.413 [bus debug] switching from receive response to send response ACK
2016-04-26 18:31:50.420 [bus debug] notify request: done
2016-04-26 18:31:50.420 [bus debug] read res: 00
2016-04-26 18:31:50.423 [main info] write hwc OperatingMode2: decode done
2016-04-26 18:31:50.424 [main debug] <<< done
2016-04-26 18:31:50.424 [bus debug] switching from send response ACK to send SYN
...


Die ebusd Daten sehen für mich ok aus, leider wird der Wert nicht gesetzt.

Mach ich irgendetwas falsch oder hab ich einen Wert erwischt, den man nicht schreiben kann?

Falls ja, über welchen Parameter kann man denn den WW Mode setzen?

Gruss,
Wolle

edit:
Ich hab mal den vollständigen Scan eingefügt oben.

Muss ich den WW Mode evtl nicht im hwc (adr 25h) sondern im Mischer mc (adr 50h) setzten?
Sinn und Zweck des Mischers habe ich bisher nicht verstanden.

Prof. Dr. Peter Henning

Der Mischer steuert, wie der Name schon sagt, eine Mischereinheit.

http://www.miti24.de/Heizung/Wandgeraete-Kleinkessel/Installationszubehoer/Vaillant-Rohrgruppe-mit-3-Wege-Mischer-R-3-4-0020191813::300298.html

Wird beispielsweise eingesetzt, wenn ein Heizkreis geringere Temperatur erfordert - z.B. Fußbodenheizung. Ist aber nicht immer nötig oder vorhanden.

LG

pah

wollet42

Danke für die Antwort.

Bei mir wird die Therme zur Heizung und Aufladung eines Warmwasserspeicher verwendet.
Der Vorlauf wird mit einem 3-Wege Ventil umgeschaltet über einen reinen Schaltausgang.

Demnach wird dafür der Mischerkreis verwendet.


Kann ich eigentlich ein Hardware Problem ausschliessen bei dem Problem mit dem Schreiben
(wurde ja schon öfter hier im Thread diskutiert)

Ich hab den e-services Adapter seit Monaten zum reinen Lesen in Betrieb. Soweit ich verstehe beinhaltet auch das Lesen von Werten vom ebus Bus Schreiboperationen, diese funktionieren ja zuverlässig.
=> Hardwareproblem ausgeschlossen

Oder bin ich da zu optimistisch?

Gruss,
Wolle


istler

Hallo Wolle,

also bei mir funktioniert dies. Aber meine Geräte haben wohl eine neuere (?) Software:
ddress 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"

evtl. verhält sich deine SW anders.

Gruß
Maik

jkriegl

@ wollet42
Prüfe, ob hinter 2b00 durch hex-Lesen nicht der Modus von mehreren circuits steckt.
Falls ja, die ganze Liste schreiben.
Rpi 3/4, buster, Fhem, Cul 868, HM-CC-RT-DN, HM-Sec-Sco, HM-ES-PMSw1-Pl, ebus (Vaillant), ECMD, Telegram, HTTPMOD, Xiaomi, Shelly

wollet42

#1672
@jkriegl
leider verstehe ich nicht genau was ich prüfen soll

@all
Ich hab mal etwas weiter Debuginfos gesammelt

der Befehl

write -c hwc OperatingMode2 off

bewirkt folgendes auf dem Bus:


2016-04-27 16:06:57.182 [bus notice] <aa
2016-04-27 16:06:57.222 [bus notice] <aa
2016-04-27 16:06:57.262 [bus notice] <aa
2016-04-27 16:06:57.281 [network debug] [00001] wait for result
2016-04-27 16:06:57.281 [main debug]>>> write -c hwc OperatingMode2 off
2016-04-27 16:06:57.282 [bus info] send message: 3125b509040e2b0002
2016-04-27 16:06:57.302 [bus notice] <aa
2016-04-27 16:06:57.303 [bus notice]>31
2016-04-27 16:06:57.309 [bus notice] <31
2016-04-27 16:06:57.309 [bus debug] switching from ready to send command
2016-04-27 16:06:57.310 [bus notice]>25
2016-04-27 16:06:57.316 [bus notice] <25
2016-04-27 16:06:57.316 [bus notice]>b5
2016-04-27 16:06:57.323 [bus notice] <b5
2016-04-27 16:06:57.324 [bus notice]>09
2016-04-27 16:06:57.330 [bus notice] <09
2016-04-27 16:06:57.331 [bus notice]>04
2016-04-27 16:06:57.337 [bus notice] <04
2016-04-27 16:06:57.338 [bus notice]>0e
2016-04-27 16:06:57.344 [bus notice] <0e
2016-04-27 16:06:57.345 [bus notice]>2b
2016-04-27 16:06:57.351 [bus notice] <2b
2016-04-27 16:06:57.352 [bus notice]>00
2016-04-27 16:06:57.358 [bus notice] <00
2016-04-27 16:06:57.359 [bus notice]>02
2016-04-27 16:06:57.365 [bus notice] <02
2016-04-27 16:06:57.366 [bus notice]>cf
2016-04-27 16:06:57.372 [bus notice] <cf
2016-04-27 16:06:57.372 [bus debug] switching from send command to receive command ACK
2016-04-27 16:06:57.376 [bus notice] <00
2016-04-27 16:06:57.376 [bus debug] switching from receive command ACK to receive response
2016-04-27 16:06:57.380 [bus notice] <00
2016-04-27 16:06:57.385 [bus notice] <00
2016-04-27 16:06:57.385 [bus debug] switching from receive response to send response ACK
2016-04-27 16:06:57.386 [bus notice]>00
2016-04-27 16:06:57.392 [bus notice] <00
2016-04-27 16:06:57.392 [bus debug] notify request: done
2016-04-27 16:06:57.392 [bus debug] read res: 00
2016-04-27 16:06:57.392 [bus debug] switching from send response ACK to send SYN
2016-04-27 16:06:57.393 [bus notice]>aa
2016-04-27 16:06:57.395 [main info] write hwc OperatingMode2: decode done
2016-04-27 16:06:57.395 [main debug] <<<done
2016-04-27 16:06:57.399 [bus notice] <aa
2016-04-27 16:06:57.439 [bus notice] <aa
2016-04-27 16:06:57.479 [bus notice] <aa
2016-04-27 16:06:57.519 [bus notice] <aa
2016-04-27 16:06:57.559 [bus notice] <aa
2016-04-27 16:06:57.599 [bus notice] <aa


Sieht für mich soweit richtig aus ich kann jedoch keine Werte erfolgreich schreiben.

Erfolglos getestet habe ich mittlerweile OperatingMode und DesiredTemp jeweils für hc und hwc (done kommt zurück aber kein Wert wird gesetzt)


Ein anderer Ansatz:

Bisher versuche ich im B5h 09h Register ueber die B5h 09h Operation auf dem Bus zu lesen (funktioniert) und zu schreiben (funktioniert nicht).
Was ist eigentlich der Unterschied zwischen B5h 09h und B5h 05h bzw B5h 04h?
Viele Parameter findet man ja in beiden Registern.
Viele Parameter kann man ja ueber beide OPerationen adressieren.

Ich hab das so verstanden, dass das B5h 09h im Wesentlichen von VrDialog verwendet wird und auch hier in den meisten configs auftaucht.

Das B5h 04h (read) bzw B5h 05h (write) wird zwischen VRSxxx und den verschiedenen Geräten verwendet.
Deshalb hatte ich mich da bisher zurückgehalten.


Schreibt jemand Werte in diese Register (B5h 05h) um die Heizung zu steuern?

Gruss,
Wolle

Prof. Dr. Peter Henning

Das ist leider grottenfalsch. Zum gefühlt hundertsten Mal hänge ich die immerhin halb fertige Protokolldokumentation an.

B5 steht für Vaillant

Das Byte danach charakterisiert die Operation.

LG

pah

wollet42

#1674
da hatte ich das ja her (Kapitel 3.1, 3.2 und 3.4)

edit ich meine die Operationen 04h und 05h hab ich aus dem pdf /edit

In den Vailant csv files, die für meine Geräte sind z.B.
https://github.com/john30/ebusd-configuration/blob/master/ebusd-2.x.x/de/vaillant/25.solsy.hwc.csv

wird vornehmlich die 09h Operation verwendet für diverse Parameter, die laut Deinem pdf auch via 04h/05h gelesen bzw geschrieben werden können z.B.

OperatingMode2 (2B00) oder TempDesired2 (3200) lassen sich beide auch über 04h/05h adressieren  (01h: SetTargetTemperature, 02h: SetOperationMode)

Was ist denn der richtige Weg?

Gruss,
Wolle


jkriegl

#1675
Habe folgendes (benutze erweiterte csvs noch von 1.x):
ebusctl r -f OperatingMode2 -> auto
ebusctl r -h 25b509030d2b00 -> 050303020303, also mehrere Infos
bei mir mit ebusctl r -f OperatingMode übersetzt -> auto;auto;off;auto;auto
Jetzt musst Du herausfinden wer für was zuständig ist.
Bei mir ist "off" der nicht benutzte HK1, dann HK2 und Solarkreis

Edit: Hab den HK2 via fhem auf eco gesetzt. Ergebnis der Abfrage:
ebusctl r -f OperatingMode  -> auto;auto;off;eco;auto
Rpi 3/4, buster, Fhem, Cul 868, HM-CC-RT-DN, HM-Sec-Sco, HM-ES-PMSw1-Pl, ebus (Vaillant), ECMD, Telegram, HTTPMOD, Xiaomi, Shelly

wollet42

#1676
ok, interessant.

Das würde auch erklären, warum ich für die Abfrage des Mode bei allen Zieladressen (hc, mc, hwc) jeweils immer den Wert für den Warmwasser (hwc) Mode sehe.

Da muss ich wohl etwas tiefer suchen und die csv Dateien üeberarbeiten.

Danke für den Hinweis.

Gruss,
Wolle

edit

Ich hab das mal schnell getestet und siehe da:
localhost: r -f -h 26b509030d2b00
050101020303


Bedeutet:
05 - Länge
01 - Modus hwc oder mc auf 01=on
01 - Modus hwc oder mc auf 01=on
02 - Modus hc (HK1) auf 02=off
03 - HK2?
03 - ??

Modus für hwc und mc ändern immer synchron, welcher was ist weiss ich nicht.
HK2 hat jkriegl ja schon entschlüsselt, kann ich nicht prüfen.
Den letzten Wert kann ich nicht verändern/entschlüsseln. Leider ist es nicht der Solar Mode


Bleibt die Frage was der beste Weg ist die Parameter zu setzen über 09h wie hier oder über das Kommando 05h.
Kann mir jemand eine Empfehlung geben?

Danke.

Gruss,
Wolle

edit2
@jkriegl
Wenn Du den Mode über fhem setzt, welchen ebus Parameter schreibst Du denn dann? Den oben von Dir genannten?

jkriegl

Ja
set H.mode cmd { "w -c hc OperatingMode %temp\n" }
Rpi 3/4, buster, Fhem, Cul 868, HM-CC-RT-DN, HM-Sec-Sco, HM-ES-PMSw1-Pl, ebus (Vaillant), ECMD, Telegram, HTTPMOD, Xiaomi, Shelly

john30

Zitat von: Prof. Dr. Peter Henning am 21 Februar 2016, 14:24:21
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]

inzwischen habe ich mal versucht, mir einen Überblick zu verschaffen. Das wird kein einfaches Unterfangen, da der Hersteller m.E. Studenten ohne den nötigen Background für die Pflege der DB eingesetzt hat.
Mein Ansatz wäre nun, als erstes die einzelnen Teile der verwendeten Bezeichnungen aus der DB durch entsprechende Kategorien-Kennzeichner zu ersetzen, um damit für jeden Eintrag die Teile den Kategorien zuordnen zu können. Dann müssten für diejenigen Einträge, die eine Kategorie mehrfach enthalten, entschieden werden, was stattdessen daraus gemacht werden soll.

Aus Deinem Vorschlag hätten wir also folgende Teile, optionales dabei in eckigen Klammern:
[Kreislauf,]Gerät,[Prozess,]Was[,Art]

Hier mal ein Beispiel für einen Wert aus der BAI:
PrEnergyCountHwc1

Darin wären also:
- PrEnergy=Was (Primärenergie)
- Count=Was (Anzahl)
- Hwc1=Kreislauf

Da gehts also schon im kleinen los
- Energy=Was oder PrEnergy=Was? Oder wäre Pr dann schon ein Gerät? Man könnte ja auch Environment als Gerät bezeichnen und Pr wäre dann... tja was eigentlich?
- EnergyCount=Was oder Count=Art? Im ersten Fall wäre 2x Was enthalten.
- Es gibt auch PrEnergySumHwc1, also wäre Sum/Count doch eher eine Art, richtig?

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. Vielleicht könnte ein BAi Besitzer die Werte mal auslesen und Licht ins Dunkel bringen?
author of ebusd

Prof. Dr. Peter Henning

Öh - ja, aber Heizung ist jetzt im Sommerbetrieb. Mal sehen, ich schreibe es auf meine Liste. Bin aber aktuell gerade sehr mit anderen Sachen zu Gange.

LG

pah