Hi,
doch 5050 ist beschreibbar. Ich meinte, es ist komisch, dass sich 5006 nohc immer nicht beschreiben lässt (auch nicht kurzzeitig)
Hi,
doch 5050 ist beschreibbar. Ich meinte, es ist komisch, dass sich 5006 nohc immer nicht beschreiben lässt (auch nicht kurzzeitig)
dann schaue ich es mir die Woche nochmal an, bis dahin kannst du das was du erreichen willst ja auch über den Offset steuern, ggf. auch noch eine Automation drauf hängen, wenn aTemp über x°, dann setze Offset zu y°. Takte bei aTemp zwischen 2-7° wirst du nicht groß vermeiden können, wäre dann sinnvoller die Leistungsabgabe etwas weiter zu begrenzen bei 0°
Ich habe es noch einmal durch gespielt, alles funktioniert so wie es soll. Modus kann ohne Probleme gesetzt werden, siehe Link:
wow, krass dass du ein Video für mich gemacht hast, danke dafür!!
Du hast mein Problem damit gelöst. Ich hate nicht auf die Symbole geachtet, sondern war der Meinung die Drop-Down-Option würde sich von Automatik Heizen auf etwas anderes umstellen.
Es funktioniert jetzt auch bei mir ![]()
Eine letzte Frage. Du sagtest, dass es evtl nicht besonders “gesund” für die WP ist, das Register auf diese Weise zu setzen und hast alternativ das Beschreiben des Offsets vorgeschlagen. Weißt du, ob das technisch einen Unterschied bei der Lambda macht und daher zu bevorzugen ist? Eine Automation für den Offset habe ich bereits geschrieben.
Ich tendiere und bin beim Offset setzen, ggf auch noch per Automation dieses mit der Wettervorhersage zu koppeln, gar nicht so sehr wegen den Aussentemperaturen, dafür kann man ja bereits direkt in der Steuerung der Lambda das Wettersegment nutzen und der beispielsweise den Einflusswert der 24h Vorhersage einfach erhöhen und die anderen runter setzen.
Ich dachte aber eher daran, wirds nächsten Tag Sonnig oder nicht, denn diese Fremdwärme durch Sonne kann man gut nutzen um mit dem Offset die Vorlauftemp wenigstens 0,5° runter zu nehmen.
Alles im allem kann man sagen, wenn man die WP zu einer Bestimmten Zeit erst gar nicht anlaufen zu lassen ist Mode setzen vielleicht ganz in Ordnung, aber nicht um die mitten im Betrieb abzuwürgen, dann ist der Takt ja schon da und den soll Sie dann auch zu Ende fahren.
Hallo ich bin auch gerade dabei die Lamda Wärmepumpe in Home Assistant zu integrieren. Dafür nutze ich diese Integration GitHub - GuidoJeuken-6512/lambda_heat_pumps: Lambda Wärmepumpe Integration für Home Assistant / Lambda Heat Pump Integration for Home Assistant · GitHub
Soweit passen die Daten im großen und ganzen auch. Allerdings habe ich beim Heizkreis das Problem, dass sowohl der Betriebsmodus (hc1_operating_mode) als auch der Heizkreis (hc1_heating_circuit) den Status “Unknown” bzw. “Nicht verfügbar” haben. Was auch noch merkwürdig ist. Es gibt für die Soll Vorlauftemperatur des HK zwei Entitäten (“hc1_target_temp_flow_line” und “hc1_flow_line_temperature_setpoint”). Diese beiden Entitäten sind abwechselnd verfügbar und unbekannt, z.B. nachdem Home Assistant neu gestartet wurde. Ich muss dann immer am Dashboard die Entität für die Anzeige wechseln. Das hält dann bis zum nächsten Neustar von Home Assistant.
Hat irgend jemand eine Idee wie ich hier vorgehen kann? Vor allem wegen dem Betriebsmodus und dem Heizkreis? Die wären für mich wichtig.
Vielen Dank
Ja, der Betriebsmodus ist unknown. Das ist ein Fehler in der Integration.
Ich habe den mir direkt über ModBus ausgelesen, da kommt der direkte Wert in ZAHLEN.
Für den Text musst du eine Umsetzung in eine Template Entität oder Template Helfer umsetzen.
Du kannst aber auch in Git-Hab einen Fehler dazu aufmachen auf machen, wenn er nicht schon existiert.
In Sachen Raumtemperatur (hc1_heating_circuit) muss von Außen eine Raumtemperatur gesendet werden durch ein Raumthermostat was Modbus spricht oder halt über HA senden (ich habe eine Berechnung dafür über alles Räume gemacht und habe den Soll von 21 °C gelassen als Bezugswert). Bei solchen Werten darauf achten, sie müssen regelmäßig geschrieben werden, dass macht aber die Integration schon für dich.
Zu der Heizkreisvorlauf, bei mir sind die beiden Entitäten bei mir unkown.
Ich nutze derzeit den Soll Vorlauf nicht, man müsste mal per Modbus schauen, ob da überhaupt von Lambda was geschrieben wird.
Modbus Integration installieren
Zeile in der configuration.yaml
modbus: !include modbus.yaml
modbus.yaml
- name: "lambda"
type: tcp
host: 192.168.xx.xx
port: 502
sensors:
- name: "Lambda HK Betriebsmodus"
unique_id: lambda_hc_operating_state
slave: 1
address: 5001 # war 5001
input_type: holding
data_type: uint16
scan_interval: 10
Hallo Achim,
danke für deine Antwort. die Adresse 5001 bezieht sich aber laut Lamda-Doku auf den Betriebsstatus (Operating state). Den Wert bekomme ich auch angezeigt. Ich versuche auf den Modus (Operating mode) Adresse 5004 mit Recht RW zugreifen können. Die wird mir aber über die Integration nicht angeboten.
Das Raumthermostat ist an der Lamda-Steuerung (Room device temp.) Adresse 5004 angeschlossen und wird leider derzeit nicht über die Integration angeboten.
Das Thema mit der “springenden” Soll-Vorlauftemperatur zwischen “hc1_target_temp_flow_line” und “hc1_flow_line_temperature_setpoint” habe ich jetzt für mich so gelöst, dass ich ein Helfertemplate erstellt hab bei dem immer der Wert von “hc1_flow_line_temperature_setpoint” angezeigt wird, wenn “hc1_target_temp_flow_line” zu “Nicht verfügbar” wechselt. Ist zwar nicht elegant, sollte aber funktionieren.
Wenn ich es richtig verstanden habe müsste ich doch in deiner modbus.yaml für den HK Betriebsmodus unter “sensors” folgendes beispielhaft eintragen:
- name: EU13L_Hc1_Operating_mode
address: 5006
input_type: holding
state_class: total
scale: 1
precision: 0
data_type: int16
Für die Raumtemperatur-Einstellung:
`- name: EU13L_Hc1_Set_heating_mode_room_temperature
address: 5051
input_type: holding
unit_of_measurement: "°C"
state_class: measurement
device_class: temperature
scale: 0.1
precision: 1
data_type: int16`
Und für das Raumthermostat:
`- name: EU13L_Hc1_Room_device_temperature
address: 5004
input_type: holding
unit_of_measurement: "°C"
state_class: measurement
device_class: temperature
scale: 0.1
precision: 1
data_type: int16`
Oder liege ich da falsch?
Wo genau muss ich denn die modbus.yaml platzieren? Ich vermute im File editor direkt unter homeassistant/, also auf der gleichen Ebene auf der auch die configuration.yaml liegt?
Vielen Dank im Voraus.
Ich habe jetzt etwas experimentiert und scheinbar liefern die Adressen 5004 (HC room device temp) und 5006 (HC operating mode) keine brauchbaren Werte. Schade, vor allem mit der Adresse 5006 hätte ich über Automationen gut auf den Heizkreis einwirken können.
Hallo Fons11,
erst einmal die 5004. Diese ist in der Integration vorhanden, aber solange nichts geschrieben wird steht da immer -32768 drin. Dies steht in den meisten Registern, wo nichts drinsteht, z.B. 0102. Hier wird der Sonnenüberschuss eingetragen, damit die Lambda weiß, wie viel sie maximal zusätzlich benutzen darf.
Das Problem ist für beide (von den Weiß ich jetzt so aus dem Kopf) auch in der Steuerung für Modbus freigeschaltet sein bzw. überhaupt freigeschaltet sein, dafür wird mindestens der Level 3 Zugang gebraucht, den hat dein Installateur auf jeden Fall. Wenn es bei dir freigeschaltet wäre und du es nicht mindesten im 5 Minutentakt beschreibst, tauchen die Register im Fehlerprotokoll auf.
Da du sie noch nicht beschreibst, würden, wenn sie in der Lambda freigeschaltet sind, die besagten Fehler im Fehlerprotokoll schmeißen.
Wenn du sie dann freigeschaltet bekommen hast, kannst du dir 2 Helfer Template Typ Sensor bauen und dort das gewünschte berechnen.
z.B. meine Berechnung des Sonnenüberschuss:
sensor.warmepumpe_pv_uberschuss
{% set se_ex = states('sensor.einspeisung_solaredge_power') %}
{% set lb_con = states('sensor.warmepumpe_leistung_gesamt') %}
{% if is_number(se_ex) and is_number(lb_con) %}
{% set se_ex_val = (se_ex | float(0) * 1000 ) |round(0) %}
{% set lb_con_val = (lb_con | float(0) * 1000 ) |round(0) %}
{% if se_ex_val > lb_con_val and se_ex_val > 0.5 %}
{{ se_ex_val }}
{% else %}
0
{% endif %}
{% else %}
0
{% endif %}
Diese Entität stelle ich der Integration zur Verfügung und die kümmert sich um das regelmäßige Schreiben.
Integration/Zahnrad Schalter fürs jeweilig benötigte Einschalten und weiter
Bekomme hier immer die Meldung, dass das eigentliche Problem des Threads schon gelöst sei.
Wir missbrauchen den Thread schon einwenig, aber genaugenommen geht es ums schreiben in Modbus Registern bei der Lambda.
Meine modbus.yaml steht im Verzeichnis homeassistant. Dann musst du aber in der configaration.yaml diesen Eintrag machen :modbus: !include modbus.yaml
dies aber da bitte, wo z.B. die automation: !include automations.yaml steht.
Wichtig! Du kannst damit nur Register lesen, nicht schreiben.
Schreiben kannst du sie in einer Automation:
alias: Test Modbus
description: ""
triggers: []
conditions: []
actions:
- action: lambda_heat_pumps.write_modbus_register
data:
register_address: 5006
value: 2
- action: lambda_heat_pumps.write_modbus_register
data:
register_address: 3006
value: 450
mode: single
Die 450 steht für 45,0, bitte die Register Notation beachten.
Hiermit du ja selbst mal testen, ob du die 5006 schreiben kannst und das lesen im Prinzip auch über die Modbus.yaml.
Ich habe die 5006 mal gerade gelesen, da kommt derzeit 65535 raus.
Wichtig ist aber zu verstehen, dass die die Register für uns extra geschrieben und bei Bedarf auch gelesen werden. Die Anwendung nutzt die nicht, sondern eigene.
Warum? Um sehen zu können, wo Einstellungen herkommen, ob ein Fremdsystem die erzeugt hat oder die eigene Anwendung.
Ach so,nochwas, ich hatte keinen Zeit mehr auf Rechtschreibfehler und kauderwelsch zu prüfen.
Nur ein kurzer Hinweis warum sich die 5006 nach kurzer Zeit wieder zurücksetzt:
Auszug aus der Doku.
3.3 Number
Die Number ist dem spezifischen Datenpunkt der ausgelesen oder beschrieben werden soll zugeordnet
(siehe Modbusprotokoll). Wenn Datenpunkte zwischen 00-49 die beschrieben werden sollen, muss der
Wert regelmäßig aktualisiert werden (Timeout nach 5min). Ansonsten wird der Wert als ungültig
betrachtet und eine Defaultwert wird zugewiesen. Datenpunkte über 50 können einmalig beschrieben
werden. Der Wert wird dauerhaft gespeichert.
Hallo Achim,
danke dir für die Hinweise. Beim 5006 habe ich es inzwischen geschafft, dass er geschrieben wird. Allerdings immer nur für ein paar Minuten. Das Symbol springt dann bei einem Wert 6 in der Anzeige auf “Sommerbetrieb” (Sonnenschirm-Symbol), obwohl in der Lamda Oberfläche als Betriebsart weiterhin “Automatik Heizen” steht. Nach ein paar Minuten stellt sich das ganze auch wieder auf “Automatik Heizen” um und das Value ändert sich von 6 wieder auf 65535. Das ist wahrscheinlich der Effekt, den du oben mit den Datenpunkten 00-49 beschrieben hast. Gibt es hier die Möglichkeit den Wert dauerhaft über eine Automation umzustellen oder muss ich ihn alle 5 Minuten neu setzen?
Du kannst doch die Automation alle 3 Minuten starten lassen und deinen Wert schreiben lassen.
Du musst ihn spätestens alle 5 Minuten schreiben, danach wird das Register zurückgesetzt.
So habe ich es jetzt auch umgesetzt. Als Intervall habe ich 4 Minuten genommen. Das scheint soweit zu funktionieren. Was im Moment noch etwas Probleme macht ist das Verhalten wenn die Bedingungen der Automation nicht mehr erfüllt sind und damit der Wert nicht mehr geschrieben wird. Ich hätte erwartet, dass die Lamda dann nach 5 Minuten wieder auf “Automatik Heizen” zurück springt. Das scheint aber nicht zu erfolgen, sie bleibt auf “Sommerbetrieb” stehen. Das muss ich noch genauer beobachten.
Jetzt scheint alles zu funktionieren. Ich hatte die Automation erst so erstellt, dass sie wenn die Bedingungen für “Sommerbetrieb” nicht mehr erfüllt sind, einmalig wieder den Wert 2 für Automatisches Heizen sendet. Jetzt habe ich das raus genommen und seid dem passt alles.
Mir erschliesst sich der Sinn immer noch nicht ganz, die WP extern in den Sommerbetrieb zu zwingen? Es gibt etliche Wege das Verhalten der WP automatisiert zu beeinflussen. Selbst den Stand der Sonne kann man der Wärmepumpe vermitteln, mehr Fremdwärme, Offset runter und wieder rauf. Aber alles fängt erstmal da an wo die WP vor steht, im Haus. Man kann mit HA die WP besser auf das eigene Bedürfniss einpendeln und dann brauchts auch keiner Zwang Automation ![]()
Hallo Yanee,
ein klares Jain. Es ist richtig, man kann bei der Lamda viel einstellen, manches ist Sinnvoll anderes weniger. Ich habe die Konstellation, dass zusätzlich noch Solarthermie als Wärmequelle existiert. Mit den “Bordmitteln” der Lamda führt das aber regelmäßig dazu, dass der Heizkreis auch nach überschreiten der Soll-Rumtemperatur die Zirkulationspumpe des HK weiter laufen lässt. Das hat zur Folge, dass der Puffer (ist ein Kombispeicher) über den Tag kontinuierlich ohne Sinn abgekühlt wird. Gerade in der Übergangszeit hilft hier auch die Sommerschaltung der Lamda nichts, da sie nicht auf die tatsächliche Außentemperatur sondern die berechnete reagiert und die zeigt auch bei Außentemperaturen deutlich Über der Sommertemperatur noch eine zu niedrige Temperatur an. Beim Raumthermostat könnte ich bei Lamda auch ein ”Raumtemperaturabweichung Ein-/ Ausschalkthysterese” aktivieren. Das würde die HK-Zirkulationspumpe bei Überschreitung der Raumtemperatur auch abschalten. Leider wirkt sich die eingestellte Hysterese in beide Richtungen aus und die Pumpe würde erst bei entsprechender Unterschreitung der Raumtemperatur wider angesteuert werden. Mit der Automation habe ich einen vergleichbaren Effekt, aber nur für Überschreitung der Raumteperatur und kann die Pumpe gezielt bei Unterschreitung einer bestimmten Raumtemperatur wieder einschalten bzw. den Sommerbetrieb aufheben. Als Nebeneffekt habe ich die Automation so gestalte, dass sie nur auslöst, wenn die Lamda gerade nicht läuft. Das würden die Bordmittel auch nicht machen. Sie würden die WP einfach abwürgen.
Ich hoffe das war jetzt nicht zu unverständlich. In meiner Konstellation funktioniert es auf jeden Fall sehr gut und die Lamda hat derzeit keine Grund anzuspringen.