Läuft: Heizung mit eBus-Schnittstelle

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

Vorheriges Thema - Nächstes Thema

vwsuser

Zitat von: vwsuser am 03 Januar 2018, 10:51:19
ich möchte gerne eine einmalige Warmwasserbereitung meiner Wärmepumpe (Vaillant VWS 83/3) über den ebusd starten. Hierzu verwende ich den Befehl "write -c quick load", der allerdings nur die Ausgabe "ERR: element not found" bewirkt. Hat jemand eine Idee, wie ich die Funktion starten kann?

Hat das wirklich keiner in Betrieb?

jkriegl

@vwuser Mache so etwas mit "einmal Speicher laden"
set P.Lad1x cmd { "w -c quick load %temp\n" }
set P.Lad1x params temp
set P.Lad1x expect "done\n"
set P.Lad1x postproc {if ($_ =~ "done") {"%temp"} else {$_}}

Du brauchst noch eine passende quick.csv. Habe leider eine veraltete Version, läuft aber bestens.
Und auch stoppen.
Rpi 3, Fhem, Cul 868, HM-CC-RT-DN, HM-Sec-Sco, HM-ES-PMSw1-Pl, ebus (Vaillant), ECMD, Telegram, HTTPMOD, Xiaomi, Shelly

Reinhart

Zitat von: aruttkamp am 07 Januar 2018, 21:41:22
Bitte steinigt mich nicht . Ich habe nicht alle 168 Seiten gelesen.
Kann ich die Hardware die benötigt wird irgendwo fertig kaufen oder gibt es nur den Selbstbau ?

Andreas

oh, das hast du übersehen, eine Sammelbestellung lief fast 2 Monate hier.
Aber jetzt sind leider alle Teile aus!

Aber fertige Adapter gibt es auch zu kaufen, einfach danach googlen, es gibt in der Zwischenzeit schon einige Anbieter.

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

hans51

Hallo zusammen,
beim Auslesen meiner Vaillant EcoCompact habe ich 2 Probleme:

1.
Der Parameter "PumpPower" (d.15) wird am Display der Steuerung mit 34% angezeigt, beim Auslesen über den Ebus bekomme ich den Wert 15.
In der "bai.0010015600.inc" steht die Zeile "r,,PumpPower,d.15 Leistung Heizungspumpe,,,,7300,,,UCH,,,,,,"

2.
Wenn ich an meiner Steuerung die Teillast (d.00) auf "Auto" stelle (die Steuerung bestimmt die Teillast selbsttätig), bekomme ich beim Auslesen des Parameters "PartloadHcKW" immer den maximalen Wert  von 20 kW angezeigt. In der "bai.0010015600.inc" steht die Zeile "r;wi,,PartloadHcKW,d.00 Heizungsteillast,,,,"6C00",,,power,,,Heizungsteillast,,,". Für mich stellt sich die Frage, ob dies der berechnete Wert der Steuerung ist oder die über den Datentyp "power" nicht abgedeckt wird.

Es freut mich wenn mir hier die Experten helfen. Danke

Reinhart

Hallo,

zu 1:
es gibt hier offensichtlich bei d.15 zwei verschiedene Anzeigen, einmal Prozent und einmal Watt, abhängig von der Hardware.

r,,WPPWMPower,d.15 Pumpendrehzahl Istwert,,,,"7300",,,percent0,,,actual PWM-Powerrate of electronic-pump

r,,PumpPower,d.15 Leistung Heizungspumpe,,,,7300,,,UCH,,,,,,


Bei mir wird ein CSV geladen, dass mit WPPWMPower definiert ist, also Prozent.
Mit deinem CSV wird PumpPower definiert, also Watt bei dieser Hardware. Ich kann das aber jetzt nur vermuten, das es so gemeint ist.

zu 2:
ja, ist bei mir auch so, es wird nur die maximale Leistung angezeigt.

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

hans51

Hallo Reinhart,
vielen Dank für die schnelle Antwort.

zu 1.
habe die Zeile mit WPPWMPower eingefügt. Dies bringt dasselbe Ergebnis. Ich habe heute die Pumpe auf 100% Drehzahl gestellt. Dann wird über den Ebus der Wert 70 angezeigt. Das ist, wenn ich die technischen Daten richtig erinnere, die Maximal-Leistungsaufnahme der Pumpe in Watt. Deine Vermutung stimmt also, die ID 7300 gibt bei meiner EcoCompact Steuerung die Leistungsaufnahme der Pumpe an. Das einzige was mich noch stutzig macht, ist, warum bei Warmwasseraufbereitung der Wert 100 angezeigt wird.

zu 2.
Schade, dass nur die maximale Leistung angezeigt wird. Ich hätte gerne beobachtet was die Steuerung für Werte einstellt.

Nochmals danke für Deine Hilfe.

realkeule

hallo,
erstmal danke es läuft alles soweit mit der hilfe von euch.
ich habe ein paar störende meldungen im log:

2018.01.11 22:04:26 1: PERL WARNING: Argument "4.06;ok\n\n" isn't numeric in sprintf at (eval 1847) line 1.
2018.01.11 22:04:26 3: eval: { sprintf("%5.2f",$_) }

pah schrieb man soll immer mit ".*\n*" alle werte auslesen. ich glaube das problem entsteht in der darstellung.
wie muss ich den sprintf definieren das er nur 4,06 ausgibt bzw es keine warnmeldung gibt.

grüße
Somfy
Ebus

Reinhart


Das Thema hatten wir ein paar Posts weiter oben. Wie soll sprintf eine Numerische aus dem Text "ok" machen?


Also das "ok" doch gar nicht erst einlesen ist die bessere Methode! Steht auf dem Post beschrieben wie man das macht!


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

lewej

Hallo Zusammen,

damit nicht broadcast Meldungen auch kontinuierlich ausgelesen werden, hat mir john gesagt, ich könnte in den csv Dateien hinter dem r noch eine 1 anhängen und das intervall polling im ebusdaemon auch noch setzen.

Das hat bis vorkurzem immer bei mir funktioniert. Jetzt bin ich auf der aktuellsten 3er Version. Da wird es scheinbar ignoriert. Hat jemand das gleiche Problem?

Gruss
lewej


Reinhart

ich habe diese Version installiert:
version: ebusd 3.1.v3.0-37-g88e4c7e

und da funktioniert wie es wie gewohnt.

2018-01-14 16:18:59.110 [bus notice] poll 430 Hc1HeatCurve: 1.30
2018-01-14 16:19:01.717 [update notice] update bai Status01 QQ=10: 55.0;53.0;0.062;44.0;46.0;off
2018-01-14 16:19:03.715 [update notice] update bai DateTime QQ=10: nosignal;03:59:14;-.-.-;0.062
2018-01-14 16:19:03.931 [update notice] unknown BC cmd: 10feb505020400
2018-01-14 16:19:05.122 [bus notice] poll 430 Hc1HeatCurve: 1.30
2018-01-14 16:19:05.735 [update notice] update bai SetMode QQ=10: auto;54.0;-;-;0;0;1;0;0;0
2018-01-14 16:19:11.113 [bus notice] poll 430 Hc1HeatCurve: 1.30
2018-01-14 16:19:11.768 [update notice] update bai Status01 QQ=10: 51.0;51.0;0.062;44.0;46.0;off
2018-01-14 16:19:15.799 [update notice] update bai SetMode QQ=10: auto;54.0;-;-;0;0;1;0;0;0
2018-01-14 16:19:17.110 [bus notice] poll 430 Hc1HeatCurve: 1.30
2018-01-14 16:19:21.868 [update notice] update bai Status01 QQ=10: 53.0;53.0;0.062;44.0;46.0;off
2018-01-14 16:19:23.137 [bus notice] poll 430 Hc1HeatCurve: 1.30
2018-01-14 16:19:23.844 [update notice] update broadcast vdatetime QQ=10: 15:50:45;14.01.2018
2018-01-14 16:19:24.106 [update notice] unknown MS cmd: 1008b512020064 / 00
2018-01-14 16:19:25.885 [update notice] update bai SetMode QQ=10: auto;54.0;-;-;0;0;1;0;0;0
2018-01-14 16:19:29.098 [bus notice] poll 430 Hc1HeatCurve: 1.30
2018-01-14 16:19:29.932 [update notice] update bai Status01 QQ=10: 51.0;47.0;0.062;44.0;47.0;off


Dämon hast nach der Änderung neu gestartet?

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

john30

Zitat von: lewej am 14 Januar 2018, 15:39:15
damit nicht broadcast Meldungen auch kontinuierlich ausgelesen werden
wie genau soll das denn funktionieren??

Zitat von: lewej am 14 Januar 2018, 15:39:15
, hat mir john gesagt, ich könnte in den csv Dateien hinter dem r noch eine 1 anhängen
das hast Du glaube ich missverstanden. Eine 1 hinter dem r bewirkt, dass eine nachricht mit ins Polling aufgenommen wird, sprich regelmäßig aktiv von ebusd abgerufen wird.
Mit broadcast hat das zunächst mal rein gar nichts zu tun und für broadcast Messages kann das auch gar nicht funktionieren, weil die ja immer vom Sender als broadcast kommen und somit nicht aktiv abgefragt werden können.

Zitat von: lewej am 14 Januar 2018, 15:39:15
Das hat bis vorkurzem immer bei mir funktioniert. Jetzt bin ich auf der aktuellsten 3er Version. Da wird es scheinbar ignoriert. Hat jemand das gleiche Problem?
das sollten wir erstmal klären, was du eigentlich erreichen willst
author of ebusd

Reinhart

wenn lewej hier mit einer "1" arbeitet und das vielleicht bei mehreren Messwerten, dann kommt der eBus ordentlich ins schwitzen weil das sehr schnell ist und die Kommunikation ordentlich zustopft. Außer für Testzwecke würde ich das so nicht verwenden.

Broadcast ist ja egal, da wird der Bus ja nur einseitig belastet, aber ständig auch Tx senden ist etwas zu heftig. Ich habe das aber schon öfters gelesen, dass möglichst viele Messwerte in sehr kleinen Abständen für Steuerungen etc. scheinbar gebraucht werden. Ich finde das nicht, denn eine Heizung ist sehr träge und 10 Minuten sind in den meisten Fällen völlig ausreichend. Wer mehr braucht sollte sich eine andere Steuerungsmöglichkeit überlegen. Mann sollte dem Bus noch Zeit lassen seine interne Kommunikation zwischen den Geräten zu erledigen, für das wurde er ja schließlich gebaut.

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

lewej

#2502
Hallo Reinhart,
Hallo John,

es funktioniert so wie es auch beschrieben ist, ich hätte einfach nur in logs schauen sollen. Wir hatten einfach seit dem 4.1 keine einzige längere Sonnenstunde, wo die Pumpe anspringen hätte können.

Gruss und Danke für eure Mühe

lewej

Reinhart

wenn du die Pollingtime auch mit hochschraubst passt es schon.

Aber zurück zu deiner ursprünglichen Frage, du hast doch Daten von heute in deinem Post. Was funktioniert denn jetzt deiner Ansicht nicht?
Oder war das noch vor dem ebusd Update auf 3.1 ?

PS: habe gerade gesehen du hast es schon korrigiert.

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

lewej

Hallo Reinhart,
Hallo John,

also wie oben geschrieben wird doch richtig gepollt, jetzt schreibt Reinhart, das wäre nicht so wirklich toll für den bus.

Mein Problem ist, das meine Solarsteuerung gar keine broadcast Meldungen versendet, das heisst ich muss alle Readings Manuell mit get oder halt mit r1 ins polling aufnehmen.
Oder habt ihr eine bessere Idee, wie ich das machen kann.

In der testphase lasse ich alle Readings pollen, später wären es ca. 6-10, die anderen ändern sich ja nicht.

Gruss
lewej

Zitat von: Reinhart am 14 Januar 2018, 16:48:36
wenn lewej hier mit einer "1" arbeitet und das vielleicht bei mehreren Messwerten, dann kommt der eBus ordentlich ins schwitzen weil das sehr schnell ist und die Kommunikation ordentlich zustopft. Außer für Testzwecke würde ich das so nicht verwenden.

Broadcast ist ja egal, da wird der Bus ja nur einseitig belastet, aber ständig auch Tx senden ist etwas zu heftig. Ich habe das aber schon öfters gelesen, dass möglichst viele Messwerte in sehr kleinen Abständen für Steuerungen etc. scheinbar gebraucht werden. Ich finde das nicht, denn eine Heizung ist sehr träge und 10 Minuten sind in den meisten Fällen völlig ausreichend. Wer mehr braucht sollte sich eine andere Steuerungsmöglichkeit überlegen. Mann sollte dem Bus noch Zeit lassen seine interne Kommunikation zwischen den Geräten zu erledigen, für das wurde er ja schließlich gebaut.

LG