Läuft: Heizung mit eBus-Schnittstelle

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

Vorheriges Thema - Nächstes Thema

Prof. Dr. Peter Henning

#3420
 ;D

Er versteht es immer noch nicht...

pah

m8haben

#3421
Moin, bitte keinen Streit. Erstmal zu mir, ich bin kein Informatiker oder sonst irgendwie Software-Experte. Ich konnte und durfte in früheren Jahren Computer reparieren. Und das auch recht gut. ;-))
Ich habe es tatsächlich geschafft vor Jahren FHEM auf meinem Rechner bzw. Raspi 2 zu installieren und komme auch recht gut mit meiner Heizung zu recht.
Dann kam mein Problem! Ich habe ein update gemacht. Mit ein paar Anlaufproblemen läuft alles wieder recht gut. Wenn ich mal meine gewünschte Temperatur ändern möchte klappt alles gut. Oder mal die Einschalttemperatur meiner der Pumpe für meinen Kaminofen mit Wassertasche geht alles. Aber die Teillasteinstellung an meinem Vaillantkessel ecoVit geht nicht mehr. Der Grund warum ich das mit FHEM zwischendurch mal ändere ist der, dass ich immer noch unser Erdgeschoss hauptsächlich mit der Kaminofen beheize. In der Regel läuft der Gaskessel mit der kleinsten Einstellung, aber wenn die Temperaturen weit unter 0°C fallen, braucht der Kessel recht lange bis die Temperatur im Pufferspeicher erreicht wird. Die Vaillant-Steuerung will dann unten im Speicher mindestens 2°C mehr als die geforderte Vorlauftemperatur erreichen. Somit erhöhe ich gerne mal die Teillast auf 10 oder auch 12Kw. Das ganze bequem mit FHEM. Aber das läuft nicht mehr. Auch das Lesen der Einstellung PartloadHcKw klappt nicht. z.B Ich stelle per hand am Kessel 12Kw ein und lesen dann aus lese ich 6Kw. Anderes Beispiel: Mit FHEM setze ich die Leistung auf 10Kw am Kessel passiert nichts. Mit einem read PartloadHcKw lese ich dann aber 10Kw.

Ich versuche jetzt noch zwei .log- Dateien hier hoch zu bekommen und vielleicht kann der "eine" oder auch der "andere" mir helfen.

  version: ebusd 23.3.23.3
update check: version 24.1 available
device: /dev/ttyUSB0, serial
signal: acquired
symbol rate: 42
max symbol rate: 186
min arbitration micros: 3
max arbitration micros: 431
min symbol latency: 0
max symbol latency: 22
scan: finished
reconnects: 0
masters: 7
messages: 883
conditional: 24
poll: 1
update: 12
address 01: master #6
address 03: master #11
address 06: slave #6, scanned "MF=Vaillant;ID=PMS00;SW=0107;HW=4302", loaded "vaillant/06.pms.csv"
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0703;HW=7401", loaded "vaillant/bai.0010006101.inc" ([PROD='']), "vaillant/08.bai.csv"
address 0a: slave, scanned "MF=Vaillant;ID=PMW00;SW=0117;HW=4402", loaded "vaillant/0a.pmw.hwc.csv"
address 10: master #2
address 12: slave, scanned "MF=Vaillant;ID=PMW00;SW=0117;HW=4402"
address 15: slave #2, scanned "MF=Vaillant;ID=UI   ;SW=0501;HW=6201", loaded "vaillant/15.ui.csv"
address 23: slave
address 25: slave
address 26: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/26.solsy.hc.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 3f: master #23
address 50: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/50.solsy.mc.csv"
address 7f: master #24
address ec: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/ec.solsy.sc.csv"
address ed: slave, scanned "MF=Vaillant;ID=PMS00;SW=0107;HW=4302", loaded "vaillant/ed.pms.sc.csv"
address f7: master #20
address fc: slave #20, scanned "MF=Vaillant;ID=PMW00;SW=0117;HW=4402"
Rpi 2, Fhem, ebus (Vaillant), ECMD

Prof. Dr. Peter Henning

Erst einmal würde ich hier den ebusd auf die vorhandene neue Version 24.1 updaten - das steht ja in der 2.Zeile.
Zweitens muss man berücksichtigen, dass hier drei Systeme involviert sind. Die Vaillant-Systeme werden vom ebusd gesteuert, und erst der durch FHEM. Wenn solche Dinge wie "es geht nicht mehr" auftreten, muss also überprüft werden, an welchem Teilsystem das liegt.
Tipp: Per ssh auf der Kiste anmelden, die den ebusd enthält. Und den (in der neuen Version natürlich!) per Kommandozeile ansteuern. Wenn dann die Umschaltung funktioniert, kann man bei FHEM weiter nachsehen.

LG

pah

m8haben

#3423
Vielen Dank für die Reaktion.
Weiter mit meinem Problem. Ich habe mal mit try and error versucht ebusd upzudaten.Ob es richtig war was ich gemacht habe weiß ich nicht genau.

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
ebusd is already the newest version (23.3).
0 upgraded, 0 newly installed, 0 to remove and 12 not upgraded.
ebus@ebuspi:~ $ sudo apt-get update ebusd
E: The update command takes no arguments
ebus@ebuspi:~ $ sudo apt-get upgrade ebusd
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
ebusd is already the newest version (23.3).
Calculating upgrade... Done
The following packages have been kept back:
  libcamera-ipa linux-headers-rpi-v6 linux-headers-rpi-v7 linux-headers-rpi-v7l linux-image-rpi-v6 linux-image-rpi-v7 linux-image-rpi-v7l linux-image-rpi-v8:arm64 raspi-config raspi-utils rpi-eeprom rpicam-apps-lite
0 upgraded, 0 newly installed, 0 to remove and 12 not upgraded.
ebus@ebuspi:~ $ ebusctl
localhost: i
version: ebusd 23.3.23.3
update check: version 24.1 available
device: /dev/ttyUSB0, serial
signal: acquired
symbol rate: 36
max symbol rate: 176
min arbitration micros: 3......

Es bleibt die Version 23.3 und die Meldung   ebusd is already the newest version (23.3).

Komme so nicht weiter. Per Kommandozeile w -c bai PartloadHcKW kann ich 20 schreiben und auch anschließend 20 lesen, aber am Kessel passiert nichts. Wie mache ich weiter?

Gruß Roland
Rpi 2, Fhem, ebus (Vaillant), ECMD

Prof. Dr. Peter Henning

Zitat von: m8haben am 07 Januar 2025, 13:37:55w -c bai PartloadHcKW kann ich 20 schreiben und auch anschließend 20 lesen, aber am Kessel passiert nichts.
Vlt. mal ein paar Minuten warten.

LG

pah

m8haben

Nein auch Minuten oder Stunden ändert nichts daran. Ich habe das Gefühl, dass der Befehl irgendwo in einem falschen Register in der Kesselsteuerung landet und ich auch aus diesem Register lese, weil ein Lesen des geänderten Wertes auch mit dem geänderten Wert antwortet. Aber eben nicht in dem Register in dem der Wert für PartloadHcKW steht.

Gruß Roland
Rpi 2, Fhem, ebus (Vaillant), ECMD

cs-online

...das dauert bei mir auch immer teilweise mehrere Tage, bis die Therme das übernimmt, manchmal geht es auch schneller,hab noch nicht rausgefunden, woran das liegt... Vielleicht muss die Therme sozusagen neu gestartet werden um das zu übernehmen
FHEM auf DELL Thinclient, HM-WLAN-Gateway, einige HM-Aktoren,2x EBUSD an Heizung+Solar, ESP8266/32 am Strom-,Gas-,Wasserzähler, in WLAN-Steckdosen und Relaisleisten, Sonoff S20+S26,Shelly1/2/2.5, Lacrosse-Gateway+Sensoren,Sduino,Alexa-Fhem,Huawei PV+Speicher, alles auf einem TC und da geht noch mehr

Prof. Dr. Peter Henning

Eigentlich wäre das ja eine Aufgabe für das "ebusd-Team", da würde ich mal auf der Webseite fragen.

Als Idee spukt mir noch etwas im Kopf herum: Die Therme kann ja in den Wartungsmodus gestellt werden. Dann kann man jedes Register am Display abfragen. Damit wäre überprüfbar, ob das richtige Register mit dem richtigen Wert geschrieben wird.

LG

pah

m8haben

Moin, an dem Kessel kann ich die eingestellte Leistung ablesen und auch ändern. Wenn ich mit ebusctl die Leistung abfrage, zeigt er nicht die Leistung von dem Kessel an, sondern den Wert den ich vorher mit einem write gesetzt habe. 
Ich sehe langsam den Fehler in den csv`en. Habe das Gefühl, dass die falsche csv für den ecoVIT geladen wird.
Frage: Wie lade ich die alten csv´en (    ebusd-configuration/ebusd-2.1.x/de/vaillant   )
auf meinen Raspi, damit ich den Pfad dann zu meinen lokalen csv´en ändern kann. (nicht lachen. Kenne kaum Linux Befehle auf der Kommandozeile)
Ich möchte einfach die csv´en in /etc/ebusd/vaillant auf meinem Raspi laden. Anschließen alle nicht benötigten csv´en löschen.

Die bai.0010006101.inc wird geladen und ich meine ich brauche die bai.308523.inc.
So sieht meine info aus:
device: /dev/ttyUSB0, serial
signal: acquired
symbol rate: 57
max symbol rate: 181
min arbitration micros: 3
max arbitration micros: 290
min symbol latency: 0
max symbol latency: 19
scan: finished
reconnects: 0
masters: 7
messages: 875
conditional: 24
poll: 1
update: 12
address 01: master #6
address 03: master #11
address 06: slave #6, scanned "MF=Vaillant;ID=PMS00;SW=0107;HW=4302", loaded "vaillant/06.pms.csv"
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0703;HW=7401", loaded "vaillant/bai.0010006101.inc" ([PROD='']), "vaillant/08.bai.csv"
address 0a: slave, scanned "MF=Vaillant;ID=PMW00;SW=0117;HW=4402", loaded "vaillant/0a.pmw.hwc.csv"
address 10: master #2
address 12: slave, scanned "MF=Vaillant;ID=PMW00;SW=0117;HW=4402"
address 15: slave #2, scanned "MF=Vaillant;ID=UI   ;SW=0501;HW=6201", loaded "vaillant/15.ui.csv"
address 23: slave
address 25: slave
address 26: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/26.solsy.hc.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 3f: master #23
address 44: slave #23, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301"
address 50: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/50.solsy.mc.csv"
address 7f: master #24
address ec: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/ec.solsy.sc.csv"
address ed: slave, scanned "MF=Vaillant;ID=PMS00;SW=0107;HW=4302", loaded "vaillant/ed.pms.sc.csv"
address f7: master #20
address fc: slave #20, scanned "MF=Vaillant;ID=PMW00;SW=0117;HW=4402"

In der bai.0010006101.inc steht für den PartloadHcKW

r;w,,PartloadHcKW,d.00 Heizungsteillast,,,,"0704",,,power,,,Heizungsteillast

In der bai.308523.inc steht für den PartloadHcKW

r;wi,,PartloadHcKW,d.00 Heizungsteillast,,,,"0704",,,power,,,Heizungsteillast

Dort sehe ich das Problem, oder?

Gruß Roland
Rpi 2, Fhem, ebus (Vaillant), ECMD

Prof. Dr. Peter Henning

Vor mehr als 10 Jahren, am 29. November 2014 habe ich hier den ersten Post zur erfolgreichen Ankopplung von EBUS an FHEM gesetzt.

Seitdem läuft mein erster und originaler eBus-Adapter auf einer Lochrasterplatine, und ist an einen Raspberry Pi 1 angeschlossen. Die Software des ebusd hat, ich wage es kaum zu schreiben, den Versionsstand 2.0. Es handelt sich auch noch um die erste und originale SD-Karte.

In der gesamten Zeit: Keine Fehler, keine Macken.

Ich denke dennoch, dass es Zeit ist, diese Hard- und Software aufs Altenteil zu schieben und einen neuen eBus Adapter via MQTT anzubinden.

Zwar habe ich derzeit parallel schon ebusd 24.1 mit einem neuen Adapter laufen. Dabei stolpere ich darüber, dass zwar Hardware und Software besser geworden sind - aber die Dokumentation nicht.

Kann mir irgendjemand sagen, ob ich meine alten Konfigurationsdateien (CSV-Format) auch mit einem "neuen" ebusd nutzen kann, und wo die zu liegen haben?

LG

pah


TomLee

Hier steht das man alternativ zum default (https://ebus.github.io/), den Pfad zu den Dateien in configpath angeben kann.

m8haben

#3431
Zitat von: TomLee am 01 Februar 2025, 15:50:10Hier steht das man alternativ zum default (https://ebus.github.io/), den Pfad zu den Dateien in configpath angeben kann.

Moin, bei mir läuft das nicht. Ich gebe den Pfad zu den Config-Dateien (csv) an, aber er lädt dann keine Config-Dateien. Ich habe zur Zeit das Problem, dass eine falsche csv zu meinem Gaskessel geladen wird. Siehe meinen Beitrag vorher. Wenn ich mit configpath= https://cfg.ebus.eu in der default ebusd starte holt er die csv alle, aber eben eine falsche für meinen Kessel. Wenn ich alle csv´en in /etc/default/ ablege und auch so im configpath eintrage holt er die csv´en aber nicht. Wo werden die csv´en, die ich über https:// cfg.ebus.eu hole, dann im meinem System abgelegt?
Gruß Roland
Rpi 2, Fhem, ebus (Vaillant), ECMD

Prof. Dr. Peter Henning

Natürlich will ich da nicht übermäßig meckern, schließlich ist da viel Arbeit anderer Leute hineingeflossen.

Dennoch: Ich halte es auch für einen Irrweg, Konfigurationsdateien ziemlich intransparent über das Netz zu holen. Nach meinem Verständnis werden die auch nicht lokal abgelegt, sondern stehen nur im Speicher.

Ebensowenig kann ich mit dem Format anfangen. Da soll man erst komplizierte DevSpec-Dateien erzeugen, die dann doch wieder in eine CSV_Datei umgewandelt werden???
Da war ich vor 10 Jahren weiter, indem ich einfach mit einem Spreadsheet + Makros gearbeitet habe. Das klartextlesbare Spreadsheet hat auf Knopfdruck die Konfigurationsdatei ausgespuckt.

Außerdem habe ich bemerkt, dass meine 10 Jahre alten Konfigurationsdateien mehr dekodierte Nachrichten enthalten, als die "offiziellen" - sehr seltsam.

Bevor ich dazu ein Fass aufmache, muss ich aber erst auf die allerneueste Version des ebus-Adapters warten, die kommt aus China und wird noch ein paar Tage brauchen.

LG

pah


m8haben

#3433
Moin,
mache mal ein ebusctl find id und vorher vielleicht noch ein ebusctl iSchicke mir mal beide Anzeigen.
Ich kämpfe auch schon lange mit falschen oder aber nicht mehr so funktionieren csv´en
Gruß Roland

P.S. Wo hast du die Config-Datei?
loacal oder vom Server.
Rpi 2, Fhem, ebus (Vaillant), ECMD

Prof. Dr. Peter Henning

So, der allerneueste ebus-Adapter ist da und funktioniert bestens.

Und jetzt stolpere ich über die offenbar nicht mehr funktionierenden Konfigurationsdateien - sehr schön erkennbar, weil mein 10 Jahre alter Raspberry Pi mit ebenso altem ebusd-Adapter parallel läuft

Hier mal die Ausgabe von

ebusctl find | grep -v 'no data stored'

- also alle gefundenen nicht-trivialen Daten

ebusd Version 2, Konfigurationsdateien lokal von 2014, ebus-Adapter von 2014 auf Lochrasterplatine
ZitatBC BCDateTime2 = 12:19:01;21.02.2025
broadcast BCDateTime = 12:19:01;21.02.2025
broadcast BCOutsideTemp = 11.875
bai00 FillPressure = 1.939;ok
bai00 FlowTemp = 37.00;ok
bai00 ID = b5;BAI00;7;30;74;1
bai00 Mode = standby
bai00 Status01 = 35.0;35.0;-;-;-;off
bai00 StorageLoadPumpStatus = off
hc currenterror = -;-;-;-;-
hc DCFStatus = valid;12:19:55;21.02.2025;11.875
hc Mode = 21;auto
hc Param = 21;20;140;0;133;17;0;15;75;0
hc Status1 = 51.12;0;1;0;40
hc Status2 = 39;0;37.50;21
hc SumFlowSensor = 36.75;ok
hwc isHWCService = yes
hwc Mode = 55;auto;02;off
hwc Status1 = 0;0;57.12;55
mc Mode = 20;auto
sc Mode = 0;auto;02;off
sc Status0 = 57.12;32.25;37.69
sc Status1 = 38.69;1;8726;-;0;0
sc Status2 = 6255;180;0
sc Status3 = 19.0;1;31.5;14.0
scan.26 ident = Vaillant;SOLSY;0500;6301
scan.50 ident = Vaillant;SOLSY;0500;6301
vrs620 HcName1 = HC         
vrs620 SolarYield = 6253
vrs620 SolarYieldApr = 0
vrs620 SolarYieldAug = 0
vrs620 SolarYieldDec = 0
vrs620 SolarYieldFeb = 28
vrs620 SolarYieldJan = 19
vrs620 SolarYieldJul = 0
vrs620 SolarYieldJun = 0
vrs620 SolarYieldMar = 0
vrs620 SolarYieldMay = 0
vrs620 SolarYieldNov = 0
vrs620 SolarYieldOct = 0
vrs620 SolarYieldSep = 0

ebusd Version 24.1, Konfigurationsdateien auf dem Server, eBUS Adapter Shield C6 von 2025
Zitatbai FlowTemp = 37.00;ok
bai SetMode = auto;50.0;-;-;0;0;0;0;0;0
bai Status01 = 35.0;34.0;-;-;-;off
bai WaterPressure = 1.559;ok
Broadcast Datetime = 11.875;12:24:05;21.02.2025
Broadcast Outsidetemp = 11.875
Broadcast Signoflife =  (empty for 7ffe07ff00 / )
Broadcast Vdatetime = 12:24:05;21.02.2025
hc Currenterror = -;-;-;-;-
hc DateTime = valid;12:24:22;21.02.2025;11.875
hc SumFlowSensor = 35.44;ok
hwc Mode = 55;auto;off;hwc;00;day
hwc Status = 0;off;56.12;55
mc Mode = 20;auto;0;0;low;inactive;day
scan.08  = Vaillant;BAI00;0730;7401
Scan.08 Id = ;;;;;;
scan.15  = Vaillant;UI   ;0508;6201
Scan.15 Id = 21;14;22;0020080465;0907;005736;N9
scan.23  = Vaillant;SOLSY;0500;6301
Scan.23 Id = 21;14;21;0020080463;0907;005476;N9
scan.25  = Vaillant;SOLSY;0500;6301
Scan.25 Id = 21;14;21;0020080463;0907;005476;N9
scan.26  = Vaillant;SOLSY;0500;6301
Scan.26 Id = 21;14;21;0020080463;0907;005476;N9
scan.50  = Vaillant;SOLSY;0500;6301
Scan.50 Id = 21;14;21;0020080463;0907;005476;N9
scan.ec  = Vaillant;SOLSY;0500;6301
Scan.ec Id = 21;14;21;0020080463;0907;005476;N9
ui YieldThisYear = 19;28;0;0;0;0;0;0;0;0;0;0

Natürlich gibt es da ein paar Abweichungen, weil die ebusd-Maintainer die Bezeichnungen geändert haben.

Es ist aber erstens ärgerlich, dass mit den gegenwärtigen Konfigurationsdateien nicht einmal die Hardware (Vaillant vrs620) richtig identifiziert wird.

Zweitens ist auch gar nicht klar, welche Daten noch abgefragt werden können. Beispielsweise kann ich mit meinen alten Konfigurationsdateien problemlos auch solche Sachen abfragen wie die Steuerung der Nachtabsenkung für Donnerstag:

ebusctl read -c hc Timer.Thursday

mit der Antwort

Zitathc Timer.Thursday = 05:30;22:00;22:00;22:00;22:00;22:00;selected

Das wird in der Folge auch gecached, prima - aber ich habe keinen Schimmer, wie ich mit den neuen serverbasierten Dateien da dran kommen kann.

Im nächsten Schritt wird mir nichts anderes übrig bleiben, als die Dateien vom Server mit meinen alten zu vergleichen.

Übrigens: Meine alten Dateien, und zwar auch als klartextlesbares Spreadsheet, stehen immer noch im contrib-Ordner von FHEM zur Verfügung.

LG

pah