Läuft: Heizung mit eBus-Schnittstelle

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

Vorheriges Thema - Nächstes Thema

Sven77

Zitat von: tom37 am 06 März 2017, 20:38:57Ich frage mich lediglich in dem Zusammenhang, was die Einstellung "Minimaltemperatur" in der VRC700 genau bezweckt (steht aktuell bei 30 Grad)!?
Auch hier wieder: bitte nicht Äpfel mit Birnen vergleichen...  ;)

Soweit ich das sehe, gibt es in der VRC700 nur eine "minimale Vorlauftemperatur" für einen Heizkreis, ebenso die maximale.
Letztere kann ich leicht erklären: was auch immer die eingestellte Heizkurve mit der Außentemperatur verlangt - beim Maximum wird gedeckelt.
Fürs Minimum könnte es ähnlich sein und einfach nur die Vorlauftemperatur minimal auf diesem Wert halten. Könnte aber auch bedeuten: wenn weniger verlangt, wird Heizkreis abgeschaltet - müsste man ausprobieren...

Wer hat die denn auf 30 Grad gestellt? Standard sollte 15 sein!
VG, Sven

mirror

Zitat von: Sven77 am 06 März 2017, 07:42:54

Ach ja, nur so als Warnung: wer eine VRC700 vor Version VRC700/4 hat, sollte mit dem Erhöhen der Sperrzeit sparsam umgehen, ich rate sogar eher zum Verkürzen der Sperrzeit und eher der Spreizung der Hysterese auf ein Maximum. Bei Interesse führe ich das gern genauer aus...

VG, Sven

Sven,
hat die 700 einen Eintrag für die Brennersperrzeit des Heizkreises? Ich habe das nur in der bai mit d.02.

Gruß,
Dietmar

Sven77

Nein, hat nur der Brenner. (soweit ich weiß)

Problem bei mir ist:
Wenn der Brenner nicht so oft taktet, wie's die VRC gern hätte, ändert letztere ihre Wärmeanforderung an den Brenner. Also wenn's ihr "zu warm" wird, weil der Brenner zu lange läuft, schraubt sie die Wärmeanforderung nach unten. Bis sie sie schließlich auf 0 setzt (in meinem Fall sobald der Pufferspeicher 10K über der eigentlichen Anforderung des Heizkreises ist). Dann irgendwann (wenn der allSTOR unter die Anforderung des Heizkreises abgekühlt ist), setzt sie dem Brenner wieder eine Anforderung. Wenn dieser dann nicht angeht, weil entweder FlowHysteresisOn zu klein ist oder er in der Sperrzeit ist, wird die Anforderung schrittweise erhöht.

Und hier kommt der Haken: wenn die geforderte Wärmeanforderung während der Sperrzeit  geändert wird, setzt der Brenner diese wieder hoch auf Maximum!
Das ist in angehängter Grafik ganz gut zu sehen, auch wenn hier die Puffertemperatur ausgeblendet ist. Auf diese Weise kommt es schonmal dazu, dass aus einer maximalen Sperrzeit von 20 Minuten effektiv 50 werden (nicht in Abbildung) und auf der anderen Seite, dass der Brenner seine Sperrzeit ignoriert und trotzdem angeht.
Zu allem Überfluss ist der Offset, den die VRC auf die eigentlich benötigte Vorlauftemperatur aufschlägt über einen mir unbekannten Zeitraum geglättet. Durch dieses beschriebene Spiel zwischen den beiden kommt es also irgendwann dazu, dass die VRC den gewünschten Brennervorlauf brutal erhöht (z.Bsp. 25K), nur um dann den Brenner mittendrin abzuwürgen, weil der Puffer 10K über dem Soll liegt (kein Wunder, denn die Anforderung war ja nochmal 15K höher).

Ob das mit allen Brennern zu beobachten ist, kann ich nicht sagen. Ebenso könnte es sein, dass das nur in Verbindung mit einem allSTOR überhaupt auftritt. Jedenfalls soll es mit dem VRC700/4 behoben sein. Bis dahin steht meine Sperrzeit auf 6 Minuten, womit ich sehr gut fahre. Die effektive Sperrzeit wird dann allein durch die Hysterese bestimmt und wenn das Vorlaufsoll nach Ablauf der Sperrzeit durch den Regler geändert wird, hat das keine negativen Auswirkungen mehr.

Sven
VG, Sven

lewej

Hallo,

ich lasse den ebusd mit mqtt laufen, jetzt sendet ebusd die Nachrichten an das Topic mit folgendem Format:

ebusd/ehp/SourceTempInput 17.31;ok

Kann man den ebusd so einstellen, das er an das Topic die Daten ohne das ok sendet?

ebusd/ehp/SourceTempInput 17.31

Gruß
lewej

Sven77

Du musst herausfinden, wie das erste Feld heisst - dann kannst Du gezielt nur dieses abfragen. Am Beispiel von "WaterPressure":

$ ebusctl r -c bai WaterPressure
2.461;ok

$ grep WaterPressure /etc/ebusd/vaillant/08.bai.csv
r,,WaterPressure,Wasserdruck,,,,"0200",,,presssensor,,,Wasserdruck

$ grep presssensor /etc/ebusd/vaillant/_templates.csv
presssensor,press;sensor,,,

$ ebusctl r -c bai WaterPressure sensor
ok

$ ebusctl r -c bai WaterPressure press
2.461
VG, Sven

john30

Zitat von: lewej am 10 März 2017, 09:39:59
ich lasse den ebusd mit mqtt laufen, jetzt sendet ebusd die Nachrichten an das Topic mit folgendem Format:

ebusd/ehp/SourceTempInput 17.31;ok

Kann man den ebusd so einstellen, das er an das Topic die Daten ohne das ok sendet?

ebusd/ehp/SourceTempInput 17.31
ja mit: --mqtttopic=ebusd/%circuit/%name/%field
Damit wird das Topic dann pro Feld gesendet, also z.B. ebusd/ehp/SourceTempInput/temp und ebusd/ehp/SourceTempInput/sensor
Allerdings ist dann ein Schreiben auf ein Topic mit Suffix /set derzeit nicht mehr möglich und expliziter Refresh mit /get muss dann auch das Feld beinhalten.
author of ebusd

lewej

Zitat von: john30 am 11 März 2017, 10:07:34
ja mit: --mqtttopic=ebusd/%circuit/%name/%field
Damit wird das Topic dann pro Feld gesendet, also z.B. ebusd/ehp/SourceTempInput/temp und ebusd/ehp/SourceTempInput/sensor
Allerdings ist dann ein Schreiben auf ein Topic mit Suffix /set derzeit nicht mehr möglich und expliziter Refresh mit /get muss dann auch das Feld beinhalten.

Hi,

@john: Danke, teste ich mal.

Ich will später doch mal was ins Topic schreiben. Deshalb die Frage, ob man mit Fhem Mitteln, die Readings nicht manipulieren könnte um z.B. das ok weg zu schneiden?

Grüsse
lewej

john30

Zitat von: lewej am 11 März 2017, 18:56:06
Ich will später doch mal was ins Topic schreiben. Deshalb die Frage, ob man mit Fhem Mitteln, die Readings nicht manipulieren könnte um z.B. das ok weg zu schneiden?
Das geht natürlich auch. Dazu via userReadings den entsprechenden Teil abtrennen, z.B. so:
attr DEVICENAME userReadings NEWNAME  { my @parts = split(/;/, ReadingsVal($name, READINGNAME, "")); return $parts[0]; }
Dabei DEVICENAME und READINGNAME durch die existierenden Namen ersetzen und NEWNAME durch den gewünschten neuen "Teilnamen".
author of ebusd

lewej

Hallo Zusammen,

ich habe ein Problem mit dem ebusd und meiner auromatic 560. Wenn ich den ebusd starte dann funktionieren erstmal keine Readings, da die auromatic kein broadcast auf den BUS sendet,  man muss expliziet die Readings triggern.

Dienst starte ich mit:

-c /etc/ebusd2x --pollinterval=5 --scanconfig -d /dev/ebusvaillantsolar -p 8889 -l /var/log/ebusdvaillantsolar.log --mqttport=1883 --mqtthost=ebus --mqtttopic=ebusdsolar"



ebusctl -p 8889 find -v
broadcast datetime = no data stored
broadcast error = no data stored
broadcast id = no data stored
broadcast signoflife = no data stored
broadcast id = no data stored
memory eeprom = no data stored
memory ram = no data stored


Ich muss zuerst ein
scan full
ausführen.

root@smarthome:/etc/ebusd/solar# ebusctl -p 8889 find -v
broadcast datetime = no data stored
broadcast error = no data stored
broadcast hwcStatus = no data stored
broadcast id = no data stored
broadcast load = no data stored
broadcast outsidetemp = no data stored
broadcast signoflife = no data stored
broadcast vdatetime = no data stored
broadcast id = no data stored
general valuerange = no data stored
memory eeprom = no data stored
memory ram = no data stored
scan id = no data stored
scan.15  = MF=Vaillant;ID=SDR_P;SW=0312;HW=6801
scan.15 id = prefix=??;year=??;week=??;product=??????????;supplier=????;counter=??????;suffix=??
scan.23  = MF=Vaillant;ID=SDR_P;SW=0312;HW=6801
sdr_p ActualTempDesired = no data stored
sdr_p BypassValve = no data stored
sdr_p C1C2 = no data stored
sdr_p CirPump = no data stored
sdr_p Coll1Sensor = no data stored
sdr_p Coll2Sensor = no data stored
sdr_p CollPump1 = no data stored
sdr_p CollPump1ActualPower = no data stored
sdr_p CollPump2 = no data stored
sdr_p CollPumpHRuntime = no data stored
sdr_p Date = no data stored
sdr_p DisableAutoSync = no data stored
sdr_p ElectronicCartridge = no data stored
sdr_p HwcLoadingDelay = no data stored
sdr_p HydraulicScheme = no data stored
sdr_p IsInHoliday = no data stored
sdr_p IsInParty = no data stored
sdr_p IsInSingleHwcLoading = no data stored
sdr_p LegioProtectionEnabled = no data stored
sdr_p LegioPump = no data stored
sdr_p NumCollPanels = no data stored
sdr_p OperatingMode = no data stored
sdr_p ResetOperatingTimes = no data stored
sdr_p ResetYield = no data stored
sdr_p SolDisableDiffTemp = no data stored
sdr_p SolEDEnable = no data stored
sdr_p SolEnableDiffTemp = no data stored
sdr_p SolEnableDiffTempMax = no data stored
sdr_p SolEnableDiffTempMin = no data stored
sdr_p SolFlowRate = no data stored
sdr_p SolHwcMaxLoadTemp = no data stored
sdr_p SolPumpBlockingTime = no data stored
sdr_p SolPumpPower = no data stored
sdr_p StartTimeFillingMode = no data stored
sdr_p StartTimeOperatingMode = no data stored
sdr_p Storage1Sensor = no data stored
sdr_p Storage2Sensor = no data stored
sdr_p Storage3Sensor = no data stored
sdr_p ThreeWayValve1 = no data stored
sdr_p Time = no data stored
sdr_p Weekday = no data stored
sdr_p Yield = no data stored
sdr_p YieldSensor = no data stored



Danach sind zwar die Readings da, aber die werden nicht gefühlt. Ich muss die Readings selber triggern.



ebusctl -p 8889 r Storage1Sensor
58.88;ok


Hat jemand eine Idee, warum die Reading nicht automatisch abgefragt werden, pollingintervall ist ja auch gesetzt.

Gruß
lewej

john30

Zitat von: lewej am 12 März 2017, 11:57:05
ich habe ein Problem mit dem ebusd und meiner auromatic 560. Wenn ich den ebusd starte dann funktionieren erstmal keine Readings, da die auromatic kein broadcast auf den BUS sendet,  man muss expliziet die Readings triggern.
Du kannst auch --scanconfig=full an ebusd übergeben, dann macht er initial einen full scan.

Zitat von: lewej am 12 März 2017, 11:57:05
Danach sind zwar die Readings da, aber die werden nicht gefühlt. Ich muss die Readings selber triggern.
Die Werte werden mit der jetzigen Definition (CSV) nicht zyklisch gepollt.
Du kannst entweder alle type Spalten mit "r" in den entsprechenden CSVs durch bspw. "r1" ersetzen, womit dann die poll priority auf 1 gesetzt wird und somit die Werte auch zyklisch abgefragt werden.
Oder Du nimmst das "read" Kommando und setzt dadurch die poll priority temporär um.
author of ebusd

lewej

Zitat von: john30 am 13 März 2017, 07:53:40
Du kannst auch --scanconfig=full an ebusd übergeben, dann macht er initial einen full scan.
Die Werte werden mit der jetzigen Definition (CSV) nicht zyklisch gepollt.
Du kannst entweder alle type Spalten mit "r" in den entsprechenden CSVs durch bspw. "r1" ersetzen, womit dann die poll priority auf 1 gesetzt wird und somit die Werte auch zyklisch abgefragt werden.
Oder Du nimmst das "read" Kommando und setzt dadurch die poll priority temporär um.

Hi,

funktioniert
--scanconfig=full

funktioniert ebenfalls
Spalten mit "r" in den entsprechenden CSVs durch bspw. "r1"


Danke und Gruß
lewej

lewej

Hi,

ich bekomme die Meldung, das er die prefixe 23 und 25 nicht finden kann. Für die 630 sind diese bereits vorhanden. Kann man die für die auromatic 560 auch erstellen?


2017-03-13 09:54:40.873 [main notice] SIGTERM received
2017-03-13 09:54:41.766 [main notice] ebusd stopped
2017-03-13 09:54:51.520 [main notice] ebusd 3.0pre.daeea20 started
2017-03-13 09:54:51.569 [mqtt notice] connection established
2017-03-13 09:54:51.576 [main notice] found messages: 11 (0 conditional on 0 conditions, 0 poll, 4 update)
2017-03-13 09:54:52.006 [bus notice] signal acquired
2017-03-13 09:55:01.569 [main notice] starting initial full scan
2017-03-13 09:55:08.952 [bus notice] new master 10, master count 2
2017-03-13 09:55:08.952 [bus notice] scan 15: ;Vaillant;SDR_P;0312;6801
2017-03-13 09:55:11.591 [main notice] read common config file /etc/ebusd-2.1.x/vaillant/broadcast.csv
2017-03-13 09:55:11.592 [main notice] read common config file /etc/ebusd-2.1.x/vaillant/general.csv
2017-03-13 09:55:11.594 [main notice] read common config file /etc/ebusd-2.1.x/vaillant/scan.csv
2017-03-13 09:55:11.615 [main notice] read scan config file /etc/ebusd-2.1.x/vaillant/15.sdr_p.csv for ID "sdr_p", SW0312, HW6801
2017-03-13 09:55:11.615 [main notice] found messages: 104 (0 conditional on 0 conditions, 2 poll, 8 update)
2017-03-13 09:55:14.726 [bus notice] scan 15: ;??;??;??;??????????;????;??????;??
2017-03-13 09:55:16.002 [bus notice] scan 23: ;Vaillant;SDR_P;0312;6801
2017-03-13 09:55:16.722 [bus notice] scan 25: ;Vaillant;SDR_P;0312;6801
2017-03-13 09:55:19.711 [bus notice] scan 23: ;??;??;??;??????????;????;??????;??
2017-03-13 09:55:19.714 [main error] unable to load scan config 23: no file from /etc/ebusd-2.1.x/vaillant with prefix 23. matches ID "sdr_p", SW0312, HW6801
2017-03-13 09:55:19.714 [main error] scan config 23: ERR: element not found
2017-03-13 09:55:24.925 [bus notice] scan 25: ;??;??;??;??????????;????;??????;??
2017-03-13 09:55:24.927 [main error] unable to load scan config 25: no file from /etc/ebusd-2.1.x/vaillant with prefix 25. matches ID "sdr_p", SW0312, HW6801
2017-03-13 09:55:24.928 [main error] scan config 25: ERR: element not found
2017-03-13 09:57:02.308 [bus notice] scan ec: ;Vaillant;SDR_P;0312;6801
2017-03-13 09:57:10.336 [bus notice] scan ec: ;??;??;??;??????????;????;??????;??
2017-03-13 09:57:10.338 [main error] unable to load scan config ec: no file from /etc/ebusd-2.1.x/vaillant with prefix ec. matches ID "sdr_p", SW0312, HW6801
2017-03-13 09:57:10.339 [main error] scan config ec: ERR: element not found




Gruß
lewej

tom37

Hallo zusammen,

ich wollte kurz eine Rückmeldung zu einem Problem geben. Ich hatte u.a. in Beitrag #2112 das Problem mit diversen Fehlermeldungen geschildert (unten nochmal eingefügt). Nach zahlreichen Tests habe ich die Ursache nun mit 99% Wahrscheinlichkeit gefunden: Es lag am Netzteil des Raspberry PI, auf dem ebusd bei mir läuft. Mir ist aufgefallen, dass ich hin und wieder "broken pipe" Fehlermeldungen in meiner ssh Session erhalten hatte, mit der ich vom PC auf den Raspberry PI zugreife. D.h. dass die Netzwerkverbindung abgebrochen war und das hat wahrscheinlich auch dazu geführt, dass die Verbindung des Raspberry PI zum eService ebus Ethernet Doppler gestört war. Das Netzteil war wohl zu schwach. Ich habe mir die Tage einen neuen Raspberry PI gekauft und das dazugehörige, neue Netzteil an den Raspberry PI angeschlossen, auf dem ebusd läuft und seitdem habe ich keinerlei Probleme mehr. Vielleicht hilft das dem einen oder anderen, der ähnliche Probleme hat ...

Viele Grüße
Tom


2017-02-28 23:00:01.201 [main notice] starting initial scan for fe
2017-02-28 23:00:06.366 [bus error] send to fe: ERR: arbitration lost, retry
2017-02-28 23:00:09.269 [bus error] send to fe: ERR: arbitration lost, retry
2017-02-28 23:00:14.916 [bus error] send to fe: ERR: arbitration lost, retry
2017-02-28 23:00:22.032 [bus error] send to fe: ERR: arbitration lost
2017-02-28 23:00:22.032 [main error] initial scan failed: ERR: arbitration lost
2017-02-28 23:00:30.563 [bus error] send to 08: ERR: arbitration lost, retry
2017-02-28 23:00:33.287 [bus error] send to 08: ERR: wrong symbol received, retry
2017-02-28 23:00:37.574 [bus error] send to 08: ERR: wrong symbol received, retry
2017-02-28 23:00:38.278 [bus error] send to 08: ERR: wrong symbol received
2017-02-28 23:00:38.278 [main error] scan config 08 message: ERR: wrong symbol received
2017-02-28 23:00:47.779 [bus error] send to 15: ERR: arbitration lost, retry
2017-02-28 23:01:00.712 [bus error] send to 15: ERR: wrong symbol received, retry
2017-02-28 23:01:10.923 [bus error] send to 15: ERR: wrong symbol received, retry
2017-02-28 23:01:11.683 [bus error] send to 15: ERR: wrong symbol received
2017-02-28 23:01:11.684 [main error] scan config 15 message: ERR: wrong symbol received

john30

Zitat von: lewej am 13 März 2017, 10:05:21
ich bekomme die Meldung, das er die prefixe 23 und 25 nicht finden kann. Für die 630 sind diese bereits vorhanden. Kann man die für die auromatic 560 auch erstellen?
kann man, aber ich hab keine Defintionen dafür und ich denke, dass da nichts anderes zu finden sein wird als für die Hauptadresse.
author of ebusd

hansg

Hallo zusammen,

Ich versuch gerade eine (ur)alte Wolf R16 Steuerung mit Ebus auszulesen.
Die ersten Werte, Temperaturen etc. hab ich schon, aber bei den Zeitprogrammen bin ich jetzt an
einem Punkt wo ich nicht mehr weiterkomme.

Im gegensatz zu neueren Heizungen die für jeden Tag mehrere Ein und Ausschaltpunkte besitzen
sind an der R16 für jedes Zeitprogramm 14 Schaltblöcke vorhanden.

Für jeden Schaltblock kann folgendes eingestellt werden.

- Die Tage, also Mo;Di;Mi;Do;Fr;Sa;So;Mo-Do;Mo-Fr;Mo-So;Sa-So
- Die Uhrzeit (in Viertelstundenschritten)
- Ein bzw Aus

Für die Blöcke werden zwei Byte verwendet

1 Byte, die Tage
2 Byte die Schaltzeiten

Allerdings wird das zweite Byte sowohl für die Einschalt, als auch für die Ausschaltzeiten verwendet
(Z.B: A2 schaltet um 08:00 Ein / 22 schaltet um 08:00 aus)

Wenn ich hier den Datentyp TTQ verwende werden auch alle Ausschaltzeiten korrekt angezeigt,
allerdings erhalte ich bei allen Einschaltzeiten eine Fehlermeldung ERR: argument value out of valid range in decode

Hier würde ich vermutlich eine angepasste TTQ benötigen.
In einem anderen Thread hab ich zwar den Aufbau der TTQ gefunden,

add(new DateTimeDataType("TTQ", 8, 0, 0, false, true, 15)); // truncated time (only multiple of 15 minutes), 00:00 - 24:00 (minutes div 15 + hour * 4 as integer)

aber da ich kein Programmierer bin weiss ich nicht wie ich das abändern könnte.
Kann mir hier jemand evtl. jemand diesbezüglich einen Tipp geben?

Gruss und Dank
Hans