MELCloud integration (Mitsubishi Electric heat pumps)
With winter incoming and high peak energy price during some hours with dynamic energy plans, would be nice to be able to control Mitsubishi Electric heat pumps, to have them Boost power/reduce power/stop (during high energy price hours) There are a few different Melcloud integrations on github, maybe it would be possible to integrate it similarly to evcc?
What's missing to do so given we have templates and plugins?
Target - for a regular user - to find it in the "manufacturers list of devices" and to be able to simply add it.
Then please create a template! This is nothing the core team will be working on.
I do not have the skills to do that.
Ich will dieses Thema nochmal aufwärmen.
Da die Integration zwischen evcc und homeassistant in den letzten Releases nochmal deutlich verbessert wurde, kann das doch ein Weg sein. In Home Assistant ist die Einbindung von Mitsubishi Wärmepumpen über MELCloud bereits standardmäßig vorhanden, wenn auch mit recht wenig Entitäten:
-
Steuerelement
- climate
- climate
-
Sensoren
- Gesamtenergie
- Raumtemperatur
Via docker compose kann Home Assistant parallel zu evcc erstellt werden und der Aufwand für das Einbinden des MELCloud-Accounts war dann wirklich nur noch 5 Minuten:
- Primäraccount anlegen
- Mehrmals weiter klicken
- Einstellungen --> Geräte & Dienste:
- "Integration hinzufügen" --> MELCloud
- E-Mail + Passwort eingeben
Insgesamt sieht das dann so aus:
Dieses Gerät könnte man nun in evcc einbinden:
- Config in der UI --> "Wallbox oder Heizung hinzufügen", "Heizungsgerät hinzufügen"
- Titel vergeben
- Hersteller auswählen. Hier hätte ich nun erwartet, dass ich bei Wärmeerzeuger "Home Assistant" auswählen kann:
Aber das ist nicht so. Ich könnte eine "Schaltbare Steckdose" erstellen, aber das scheint mir nicht der richtige Typ zu sein.
Daher die Frage: Fehlt hier von Seiten von evcc noch die Einbindung einer Klimaanlage via Home Assistant, oder mache ich etwas falsch und habe einen Denkfehler?
Ich könnte eine "Schaltbare Steckdose" erstellen, aber das scheint mir nicht der richtige Typ zu sein.
Was kann sie denn ausser ein/aus noch das dir fehlen würde?!
Ich könnte eine "Schaltbare Steckdose" erstellen, aber das scheint mir nicht der richtige Typ zu sein.
Was kann sie denn ausser ein/aus noch das dir fehlen würde?!
Ich habe den Wer über die Schaltbare Steckdose ausprobiert, aber bei Entity ID des schaltbaren Geräts wird nichts zur Auswahl gestellt. Wenn ich manuell die climate-Entität aus Home Assistant in das Feld kopiere, dann kommt zunächst dieser Fehler:
Eine Entität für die Leistungsmessung habe ich nicht, deswegen habe ich es mit einer negativen Standby-Leistung probiert. Das lässt dich dann speichern und gibt mir nach einem Neustart von evcc diese Ansicht, die Wärmepumpe lässt sich auch anschalten:
Allerdings verbunden mit einer Menge an Fehlern:
Hier das Log: evcc-20251203-090732-trace.log
Das passt also etwas noch nicht und ich kann die Wärmepumpe über evcc auch nicht mehr ausschalten.
dann kommt zunächst dieser Fehler:
Die Fehlermeldung enthält alle notwendigen Informationen.
aber bei Entity ID des schaltbaren Geräts wird nichts zur Auswahl gestellt
Interessant. Wie heisst die denn?
dann kommt zunächst dieser Fehler:
Die Fehlermeldung enthält alle notwendigen Informationen.
Ich weiß, ich wollte nur dokumentieren, wie ich beim Konfigurieren vorgegangen bin. ;-)
aber bei Entity ID des schaltbaren Geräts wird nichts zur Auswahl gestellt
Interessant. Wie heisst die denn?
Die Entität heißt climate.gambach_wz, so wie auch im Screenshot der Fehler angegeben und im Log zu lesen.
Zu diesem Entitätstyp habe ich noch diese Doku gefunden: https://developers.home-assistant.io/docs/core/entity/climate/#hvac-modes.
Scheint für mich so, als müsste man AN/AUS von evcc auf HVACMode.OFF und HVACMode.HEAT mappen und passend übergeben.
Aus dem Trace von ha-switch kann ich noch diese Kommunikation zur Analyse beitragen:
[ha-switch] TRACE 2025/12/03 14:03:55 GET http://172.26.0.2:8123/api/states/climate.gambach_wz
[ha-switch] TRACE 2025/12/03 14:03:55 {"entity_id":"climate.gambach_wz","state":"off","attributes":{"hvac_modes":["off","heat","dry","cool","fan_only","heat_cool"],"min_temp":10.0,"max_temp":31.0,"target_temp_step":0.5,"fan_modes":["auto","1","2","3","4","5"],"swing_modes":["auto","1_up","2","3","4","5_down","swing"],"current_temperature":17.0,"temperature":24.0,"fan_mode":"2","swing_mode":"5_down","vane_horizontal":"swing","vane_horizontal_positions":["auto","1_left","2","3","4","5_right","split","swing"],"vane_vertical":"5_down","vane_vertical_positions":["auto","1_up","2","3","4","5_down","swing"],"friendly_name":"Gambach WZ","supported_features":425},"last_changed":"2025-12-03T08:11:25.547146+00:00","last_reported":"2025-12-03T08:31:53.718462+00:00","last_updated":"2025-12-03T08:31:53.718462+00:00","context":{"id":"01KBHNDRVPNW4DZ7VG3NES6VCJ","parent_id":null,"user_id":null}}
Und noch als lesbare JSON:
{
"entity_id":"climate.gambach_wz",
"state":"off",
"attributes":
{
"hvac_modes": ["off","heat","dry","cool","fan_only","heat_cool"],
"min_temp":10.0,
"max_temp":31.0,
"target_temp_step":0.5,
"fan_modes":["auto","1","2","3","4","5"],
"swing_modes":["auto","1_up","2","3","4","5_down","swing"],
"current_temperature":17.0,
"temperature":24.0,
"fan_mode":"2",
"swing_mode":"5_down",
"vane_horizontal":"swing",
"vane_horizontal_positions":["auto","1_left","2","3","4","5_right","split","swing"],
"vane_vertical":"5_down",
"vane_vertical_positions":["auto","1_up","2","3","4","5_down","swing"],
"friendly_name":"Gambach WZ",
"supported_features":425},
"last_changed":"2025-12-03T08:11:25.547146+00:00",
"last_reported":"2025-12-03T08:31:53.718462+00:00",
"last_updated":"2025-12-03T08:31:53.718462+00:00",
"context":{"id":"01KBHNDRVPNW4DZ7VG3NES6VCJ",
"parent_id":null,
"user_id":null
}
}
Ah, spannend- dann ist das Ding also kein einfacher "switch". Anstatt hier den HA Switch zu verwenden, müsstest Du Dir in dem fall einen eigenen switchsocket bauen und die Parameter mittels http Plugin konfigurieren:
Enabled plugin.Config
Enable plugin.Config
Power plugin.Config
Energy *plugin.Config
Soc *plugin.Config
StandbyPower float64
Ah, spannend- dann ist das Ding also kein einfacher "switch".
Die Alternative wäre, dass wir für enabled/enable auch noch climate zulassen- das scheint mir aber arg spezifisch.
/cc @thecem @dm82m @marq24
@andig JFYI climate ist in HA genauso ein Entity-Typ (nennt sich in HA PLATFORM) wie auch der switch
https://developers.home-assistant.io/docs/creating_platform_index/ bzw. https://developers.home-assistant.io/docs/core/entity
Und wenn das ganze "Schaltbare Object" in HA als 'climate' entity umgesetzt wurde, dann ergibt es Sinn, wenn wir das Analog zu meiner boolean_blablabla (kann mich aktuell nicht mehr daran erinnern) umsetzen
Auf der Seite von Home Assistant mit allen Integrationen gibt es auch einen Filter für Category=Climate, der 150 Integrationen ergibt. Ich habe mal stichprobenartig durchgeschaut und bei grob überschlagen 50% der Integrationen wird eine climate Entität erstellt.
Für mich hört sich das so an, als würde es sich lohnen, hier eine saubere Adaption von climate nach Wärmeerzeuger zu erstellen.
Gerne biete ich mich als geduldiger beta Tester an, ich kann z.B. einen beliebigen commit in VS Code bei mir ausführen und ein Plugin/Template testen.
... ich habe gerade mal länger in the https://developers.home-assistant.io/docs/core/entity/climate/ docu geschaut...
Also die aktuelle evcc Implementierung ist ein ON/OFF Schalter - kennt also "nur" zwei Zustände.
Eine Climate Entity muss nicht zwingend einen einfachen EIN/AUS Schalter (turn_on - turn_off) besitzen - Sondern unterstützt primär hvac-modes (und hvac-actions) - je nach dem was jetzt nun Deine Climate Entity unterstützt 'müsste* evcc jetzt entsprechende Werte (mode & action) setzen. M.E. ist das aber wirklich nicht möglich.
Wenn Du eine Climate Entity (die nicht das feature TURN_ON & TURN_OFF unterstützt) via evcc schalten möchtest (und solange evcc "nur" EIN/AUS unterstützt (das wird sicherlich noch eine Weil so bleiben))... dann geht das meiner Meinung nur darüber, das Du Dir in HA einen "Helfer Schalter" einrichtest - und dann eben in Automatisierungen die diesen Helfer Schalter verwenden, die passenden hvac-modes (& hvac-actions) setzt...
Eine Climate Entity muss nicht zwingend einen einfachen EIN/AUS Schalter (turn_on - turn_off) besitzen - Sondern unterstützt primär
hvac-modes(undhvac-actions) -
Das "nicht zwingend" verstehe ich nicht? Die Doku sagt doch eindeutig, dass es EIN/AUS NICHT gibt.
je nach dem was jetzt nun Deine Climate Entity unterstützt 'müsste* evcc jetzt entsprechende Werte (mode & action) setzen. M.E. ist das aber wirklich nicht möglich.
Ich denke, es reicht lediglich das Hauptattribute state zu setzen, und zwar auf eines der Werte, die via "attributes"."hvac_modes" angeboten werden.
Denn, wie oben berichtet, kann evcc schon jetzt die Klimaanlage einschalten, nur nicht wieder aus. Und wenn da mehr notwendig wäre als nur state zu setzen, dann hätte schon das Einschalten nicht funktioniert.
Wenn Du eine Climate Entity (die nicht das feature TURN_ON & TURN_OFF unterstützt) via evcc schalten möchtest (und solange evcc "nur" EIN/AUS unterstützt (das wird sicherlich noch eine Weil so bleiben))...
Aus meiner Sicht kann es doch wirklich nur ein kleiner Aufwand sein, dass evcc für eine climate Entität statt AN/AUS eben heat/off schickt. Und damit würden, wie oben schon aufgezählt, viele neue Gerät via Home Assistant angebunden werden können.
In den letzten Releases wurde so viel gemacht, damit evcc einfacher und komfortabler mit Home Assistant verbunden werden kann:
- mDNS
- automatische Erstellung von Tokens
- automatischer Refresh der Tokens (laut trace-log alle 30 Minuten)
- automatische Suche von passenden IDs und Erstellung von Dropdownfeldern in der UI Config
Da würde man jetzt bei 99,5 % stehen bleiben und trotzdem würden Klimaanlagen in evcc nicht eingebunden werden können.
dann geht das meiner Meinung nur darüber, das Du Dir in HA einen "Helfer Schalter" einrichtest - und dann eben in Automatisierungen die diesen Helfer Schalter verwenden, die passenden
hvac-modes(&hvac-actions) setzt...
Den Weg habe ich kurz ausprobiert und werde ich aber sicher nicht weitergehen. Der Aufwand ist immens für so einen kleinen Unterschied und wäre vermutlich auch für die breite Verwendung der Verbindung von evcc und Home Assistant ein Hindernis.
Eine Climate Entity muss nicht zwingend einen einfachen EIN/AUS Schalter (turn_on - turn_off) besitzen - Sondern unterstützt primär
hvac-modes(undhvac-actions) -Das "nicht zwingend" verstehe ich nicht? Die Doku sagt doch eindeutig, dass es EIN/AUS NICHT gibt.
Das war auch meine erste Interpretation - allerdings kann eine Climate entity eben diverse feature unterstützen https://developers.home-assistant.io/docs/core/entity/climate/#supported-features
OB jetzt eine climate nur TURN_ON oder nur TURN_OFF (oder beides) unterstützt, kann evcc so erst einmal nicht wissen.
Ganz grundsätzlich "kann" evcc etwas ein/aus schalten (und bei WB auch eben noch die Power regeln)... meinem Verständnis nach hat eine Climate Entity aber eben deutlich mehr Zustände... "AUS" ist einfach... aber EIN ist eben schon nicht mehr eindeutig. Climate bedeutet ja warm und kalt - mag sein das in Deinem Fall auch EIN eindeutig ist - also HEAT... Aber woher soll evcc das denn wissen?
Ich denke, es reicht lediglich das Hauptattribute
statezu setzen, und zwar auf eines der Werte, die via"attributes"."hvac_modes"angeboten werden. Denn, wie oben berichtet, kann evcc schon jetzt die Klimaanlage einschalten, nur nicht wieder aus. Und wenn da mehr notwendig wäre als nurstatezu setzen, dann hätte schon das Einschalten nicht funktioniert.
Wenn evcc Deine climate entity einschalten kann, dann müsste dies m.E. über "TURN ON" funktioniert haben - denn das ist der Service den evcc in HA startet...
Wenn man hier was für Climate implementieren wollte, dann wäre das AUS schalten einfach - weil man einfach HVACMode.OFFsetzen könnte... aber bei EIN fehlt mir derzeit die Phantasie, wie evcc entscheiden sollte, welches "EIN" jetzt vom User gewünscht ist...
- HVACMode.HEAT
- HVACMode.COOL
- HVACMode.HEAT_COOL
- HVACMode.AUTO
- HVACMode.DRY
- HVACMode.FAN_ONLY
Aus meiner Sicht kann es doch wirklich nur ein kleiner Aufwand sein, dass evcc für eine
climateEntität statt AN/AUS eben heat/off schickt.
Wenn es einfach statt "Turn ON/Turn OFF" ein HVACMode.HEAT/HVACMode.OFF wäre, dann hättest Du für deine Hardware recht...
Und damit würden, wie oben schon aufgezählt, viele neue Gerät via Home Assistant angebunden werden können.
Du weist aber eben nicht, welche Modes all diese neuen Geräte unterstützen/erwarten...
dann geht das meiner Meinung nur darüber, das Du Dir in HA einen "Helfer Schalter" einrichtest - und dann eben in Automatisierungen die diesen Helfer Schalter verwenden, die passenden
hvac-modes(&hvac-actions) setzt...Den Weg habe ich kurz ausprobiert und werde ich aber sicher nicht weitergehen. Der Aufwand ist immens für so einen kleinen Unterschied und wäre vermutlich auch für die breite Verwendung der Verbindung von evcc und Home Assistant ein Hindernis.
Die Cliemate Entity hat kein eindeutiges Interface - dementsprechend muss man (aka der Users) derzeit die individuellen Eigenschaften der Implementierung der Entity in eigenen Helfern in HA umsetzen.
Siehe https://github.com/evcc-io/evcc/issues/25802- es gibt auch HA WPs die das per switch machen. That said: ha-switch ist aus Sicht evcc das richtige Modell. Der spezifische "switch" hier, also die enable/enabled Funktionen müssen anderweitig implementiert werden, i.S. eines ha-climate-switch Konstruktes. Gerne PR dafür, ist kein Hexenwerk.
Workaround: in HA wrapper Switches erzeugen die sich mit dem evcc ha-switch Template verwenden lassen und das gewünschte heat/cool Szenario bedienen.
Zunächst einmal danke @marq24 für die ausführliche und geduldige Erklärung! 👍 Ich interpretiere das so, dass durchaus noch Interesse am weiteren Austausch da ist und antworte auf einige Aspekte nochmal ausführlich.
Eine Climate Entity muss nicht zwingend einen einfachen EIN/AUS Schalter (turn_on - turn_off) besitzen - Sondern unterstützt primär
hvac-modes(undhvac-actions) -Das "nicht zwingend" verstehe ich nicht? Die Doku sagt doch eindeutig, dass es EIN/AUS NICHT gibt.
Das war auch meine erste Interpretation - allerdings kann eine Climate entity eben diverse feature unterstützen https://developers.home-assistant.io/docs/core/entity/climate/#supported-features
OB jetzt eine climate nur TURN_ON oder nur TURN_OFF (oder beides) unterstützt, kann evcc so erst einmal nicht wissen.
Ich habe im Code von Home Assistant die Definition der Feature-Bits gefunden:
TARGET_TEMPERATURE = 1
TARGET_TEMPERATURE_RANGE = 2
TARGET_HUMIDITY = 4
FAN_MODE = 8
PRESET_MODE = 16
SWING_MODE = 32
TURN_OFF = 128
TURN_ON = 256
SWING_HORIZONTAL_MODE = 512
Auf mein Gerät ("supported_features":425) angewendet bedeutet das:
425 = 256 + 128 + 32 + 9 + 1
--> TURN_OFF und TURN_ON unterstützt mein konkretes Gerät.
Ganz grundsätzlich "kann" evcc etwas ein/aus schalten (und bei WB auch eben noch die Power regeln)... meinem Verständnis nach hat eine Climate Entity aber eben deutlich mehr Zustände... "AUS" ist einfach... aber EIN ist eben schon nicht mehr eindeutig. Climate bedeutet ja warm und kalt - mag sein das in Deinem Fall auch EIN eindeutig ist - also HEAT... Aber woher soll evcc das denn wissen?
Ich denke, es reicht lediglich das Hauptattribute
statezu setzen, und zwar auf eines der Werte, die via"attributes"."hvac_modes"angeboten werden. Denn, wie oben berichtet, kann evcc schon jetzt die Klimaanlage einschalten, nur nicht wieder aus. Und wenn da mehr notwendig wäre als nurstatezu setzen, dann hätte schon das Einschalten nicht funktioniert.Wenn evcc Deine climate entity einschalten kann, dann müsste dies m.E. über "TURN ON" funktioniert haben - denn das ist der Service den evcc in HA startet...
Da mein Gerät TURN_ON unterstützt, stimmte ich dir zu "müsste dies m.E. über "TURN ON" funktioniert haben". Allerdings hat "TURN OFF" nicht funktioniert, obwohl das mein Gerät auch unterstützt.
Vielleicht wegen den vielen Fehlermeldungen hat evcc gar nicht erst versucht "TURN OFF" zu schicken?
Wenn man hier was für Climate implementieren wollte, dann wäre das AUS schalten einfach - weil man einfach
HVACMode.OFFsetzen könnte... aber bei EIN fehlt mir derzeit die Phantasie, wie evcc entscheiden sollte, welches "EIN" jetzt vom User gewünscht ist...* HVACMode.HEAT * HVACMode.COOL * HVACMode.HEAT_COOL * HVACMode.AUTO * HVACMode.DRY * HVACMode.FAN_ONLYAus meiner Sicht kann es doch wirklich nur ein kleiner Aufwand sein, dass evcc für eine
climateEntität statt AN/AUS eben heat/off schickt.Wenn es einfach statt "Turn ON/Turn OFF" ein HVACMode.HEAT/HVACMode.OFF wäre, dann hättest Du für deine Hardware recht...
Und damit würden, wie oben schon aufgezählt, viele neue Gerät via Home Assistant angebunden werden können.
Du weist aber eben nicht, welche Modes all diese neuen Geräte unterstützen/erwarten...
Das lässt sich über hvac_modes auslesen, bei mir "hvac_modes": ["off","heat","dry","cool","fan_only","heat_cool"]. Diese Property ist auch gesichert immer da, weil es als Required markiert ist:
Das könnte man auslesen und dann bei der Konfiguration ein Dropdown anbieten, bei dem User auswählt, welche dieser Modi für ihn EIN sein soll. Das ließe sich dann auch noch durch den Benutzer zwischen Sommer und Wintermodus anpassen.
dann geht das meiner Meinung nur darüber, das Du Dir in HA einen "Helfer Schalter" einrichtest - und dann eben in Automatisierungen die diesen Helfer Schalter verwenden, die passenden
hvac-modes(&hvac-actions) setzt...Den Weg habe ich kurz ausprobiert und werde ich aber sicher nicht weitergehen. Der Aufwand ist immens für so einen kleinen Unterschied und wäre vermutlich auch für die breite Verwendung der Verbindung von evcc und Home Assistant ein Hindernis.
Die Cliemate Entity hat kein eindeutiges Interface - dementsprechend muss man (aka der Users) derzeit die individuellen Eigenschaften der Implementierung der Entity in eigenen Helfern in HA umsetzen.
Die Methode set_hvac_mode ist meines Erachtens nach schon eindeutig und würde, zusammen mit meinem Vorschlag zuvor, schon ein definiertes Ein- und Ausschalten ermöglichen.
Der spezifische "switch" hier, also die enable/enabled Funktionen müssen anderweitig implementiert werden, i.S. eines
ha-climate-switchKonstruktes.
Ok, dann führen wir die Diskussion zumindest in die grob richtige Richtung.
Gerne PR dafür, ist kein Hexenwerk.
Erfordert das go-code? Oder nur templates in yaml? Ich kann programmieren, habe aber keinen blassen Schimmer, wo ich ansetzen müsste.
Sowohl als auch. Es braucht eine abgewandelte Variante der homeassistant-switch.go.
Workaround: in HA wrapper Switches erzeugen die sich mit dem evcc ha-switch Template verwenden lassen und das gewünschte heat/cool Szenario bedienen.
Warum nicht einfach diesen Weg gehen?
Auf mein Gerät (
"supported_features":425) angewendet bedeutet das: 425 = 256 + 128 + 32 + 9 + 1 --> TURN_OFF und TURN_ON unterstützt mein konkretes Gerät.
Also wenn Deine climate Entity TURN_ON und TURN_OFF kann (können sollte), dann müsstest Du in Home Assistant unter http://[YOUR-IP]:8123/developer-tools/action die Aktionen climate.turn_on und climate.turn_off ausführen können...
Das ist genau die Funktionalität, die evcc in HA aufruft, wenn von evcc eine ha-entity geschaltet wird - der Service/Action [domain].turn_on bzw. [domain].turn_off wird aufgerufen (wobei [domain] eben der erste Teil der entity ID ist)...
Du weist aber eben nicht, welche Modes all diese neuen Geräte unterstützen/erwarten...
Das lässt sich über
hvac_modesauslesen, bei mir"hvac_modes": ["off","heat","dry","cool","fan_only","heat_cool"]. Diese Property ist auch gesichert immer da, weil es als Required markiert ist ... Das könnte man auslesen und dann bei der Konfiguration ein Dropdown anbieten, bei dem User auswählt, welche dieser Modi für ihn EIN sein soll. Das ließe sich dann auch noch durch den Benutzer zwischen Sommer und Wintermodus anpassen.
Das alles müsste man aber eben dann in evcc implementieren [modes auslesen, in der ConfigUI zur Anzeige bringen und dann vom Benutzer auswählen lassen und final in der config speichern... Das ist m.E. schon ein dickeres Brett was Du da in evcc bohren müsstest...
Die Methode set_hvac_mode ist meines Erachtens nach schon eindeutig...
ja die Methode die man dann aufrufen müsste ist schon klar - nur eben der Value müsse über eine (wie ich finde) Aufwendige KonfigUI erst durchgeschleift werden...
Bislang ist der aktuelle ha switch code, sehr clean und überschaubar (weil eben nur die action turn_on und turn_off aufgerufen werden müssen - und dies funktioniert dann 'out-of-the-box' dann mit allen domains/platforms, die diese Action/Service implementieren - das ist ja das coole an diesem einfachen Interface.
Wenn bei dir TURN_ON geht und TURN_OFF nicht, aber beides laut 'Features' unterstützt wird, dann ist ggf einfach nur die Implementierung der climate Entity "buggy" ? [das kannst Du ja wie zu begin dieses Post hier beschrieben, lokal in HA testen]...
Auf mein Gerät (
"supported_features":425) angewendet bedeutet das: 425 = 256 + 128 + 32 + 9 + 1 --> TURN_OFF und TURN_ON unterstützt mein konkretes Gerät.Also wenn Deine
climateEntity TURN_ON und TURN_OFF kann (können sollte), dann müsstest Du in Home Assistant unterhttp://[YOUR-IP]:8123/developer-tools/actiondie Aktionenclimate.turn_onundclimate.turn_offausführen können...
Vielen Dank für diesen Hinweis! 👍
Beides (climate.turn_on und climate.turn_off) funktioniert perfekt für mein Gerät.
Das ist genau die Funktionalität, die evcc in HA aufruft, wenn von evcc eine ha-entity geschaltet wird - der Service/Action
[domain].turn_onbzw.[domain].turn_offwird aufgerufen (wobei [domain] eben der erste Teil der entity ID ist)...
Ich habe mir den Ablauf mal mit TRACE angeschaut und dabei beobachtet, dass turn_off nicht gesendet wird, solange die Auswertung des state als Fehler interpretiert wird.
Der Ausgangspunkt ist:
- "Schnell" angeklickt
- Wärmepumpe wurde über
turn_onangeschaltet climate-Entität liefertheatzurück, was von evcc als Fehler gemeldet wird
ha-switch] TRACE 2025/12/05 21:58:32 GET http://172.26.0.2:8123/api/states/climate.gambach_wz [ha-switch] TRACE 2025/12/05 21:58:32 {"entity_id":"climate.gambach_wz","state":"heat","attributes":{"hvac_modes":["off","heat","dry","cool","fan_only","heat_cool"],[...]} [lp-2 ] ERROR 2025/12/05 21:58:32 charge power: invalid boolean state 'heat' for entity climate.gambach_wz [ha-switch] TRACE 2025/12/05 21:58:35 GET http://172.26.0.2:8123/api/states/climate.gambach_wz [ha-switch] TRACE 2025/12/05 21:58:35 {"entity_id":"climate.gambach_wz","state":"heat","attributes":{"hvac_modes":["off","heat","dry","cool","fan_only","heat_cool"],[...]} noch viel mehr gleiche Traces von [ha-switch] ich drücke in der UI auf "Aus", turn_off wird nicht gesendet, state bleibt heat [ha-switch] TRACE 2025/12/05 21:58:37 GET http://172.26.0.2:8123/api/states/climate.gambach_wz [ha-switch] TRACE 2025/12/05 21:58:37 {"entity_id":"climate.gambach_wz","state":"heat","attributes":{"hvac_modes":["off","heat","dry","cool","fan_only","heat_cool"],[...]} noch viel mehr gleiche Traces von [ha-switch] ich schalte die Wärmepumpe extern aus [ha-switch] TRACE 2025/12/05 21:58:38 GET http://172.26.0.2:8123/api/states/climate.gambach_wz [ha-switch] TRACE 2025/12/05 21:58:38 {"entity_id":"climate.gambach_wz","state":"off","attributes":{"hvac_modes":["off","heat","dry","cool","fan_only","heat_cool"],[...]} [lp-2 ] DEBUG 2025/12/05 21:58:38 charge power: 0W [lp-2 ] DEBUG 2025/12/05 21:58:38 charger status: A [ha-switch] TRACE 2025/12/05 21:58:38 GET http://172.26.0.2:8123/api/states/climate.gambach_wz [ha-switch] TRACE 2025/12/05 21:58:38 {"entity_id":"climate.gambach_wz","state":"off","attributes":{"hvac_modes":["off","heat","dry","cool","fan_only","heat_cool"],[...]} Auswertung des states ist fehlerfrei, jetzt erst wird turn_off gesendet [ha-switch] TRACE 2025/12/05 21:58:38 POST http://172.26.0.2:8123/api/services/climate/turn_off [ha-switch] TRACE 2025/12/05 21:58:40 {"entity_id":"climate.gambach_wz"}
Das volle Log, darin ist dieser Ablauf nacheinander 4 mal zu finden, das ist also reproduzierbar: evcc-20251205-215847-trace.log
Bislang ist der aktuelle ha switch code, sehr clean und überschaubar (weil eben nur die action turn_on und turn_off aufgerufen werden müssen - und dies funktioniert dann 'out-of-the-box' dann mit allen domains/platforms, die diese Action/Service implementieren - das ist ja das coole an diesem einfachen Interface.
Ich glaube, hier habe ich einen Fehler gefunden:
Ich würde erwarten, dass evcc den turn_off immer direkt schickt, egal ob state gültig ist oder nicht.
Ich glaube, hier habe ich einen Fehler gefunden: Ich würde erwarten, dass evcc den
turn_offimmer direkt schickt, egal obstategültig ist oder nicht.
ich muss Morgen nochmal in den aktuellen Code gucken... aber ich meine eine einfachere Lösung, wäre die states heat, cool und heat_cool als on gelten zu lassen... Da meine ich gibt's eine List von Values die als "ON" gelten...
Ich glaube, hier habe ich einen Fehler gefunden: Ich würde erwarten, dass evcc den
turn_offimmer direkt schickt, egal obstategültig ist oder nicht.ich muss Morgen nochmal in den aktuellen Code gucken... aber ich meine eine einfachere Lösung, wäre die states
heat,coolundheat_coolalsongelten zu lassen... Da meine ich gibt's eine List von Values die als "ON" gelten...
Meinst du diese Stelle https://github.com/evcc-io/evcc/blob/master/util/homeassistant/connection.go#L116 in GetBoolState?
Workaround: in HA wrapper Switches erzeugen die sich mit dem evcc ha-switch Template verwenden lassen und das gewünschte heat/cool Szenario bedienen.
Warum nicht einfach diesen Weg gehen?
Ein switch device lässt sich nicht als Helper device anlegen. Wenn man nach switch sucht, dann wird einem input_boolean vorgeschlagen. Diesen Entitättyp habe ich in #25906 neben climate auch noch als unterstützt im template hinzugefügt.
ich muss Morgen nochmal in den aktuellen Code gucken... aber ich meine eine einfachere Lösung, wäre die states
heat,coolundheat_coolalsongelten zu lassen... Da meine ich gibt's eine List von Values die als "ON" gelten...
Diese einfache Lösung habe ich in #25906 implementiert.
Allerdings hat das aus User-Sicht noch einen Haken:
Wenn ich nun nach Mitsubhi oder MELCloud in der Doku suchen, dann habe ich dort keinen Hinweis darauf, dass ich das über Home Assistant integrieren könnte. Ich glaube, dass man das in homeassistant-switch.yaml durch die drei letzte Zeilen ergänzen könnte:
template: homeassistant-switch
products:
- brand: Home Assistant
- brand: Mitsubishi
description:
generic: MELCloud
Zumindest wird mit make docs eine Datei mitsubishi-melcloud.yaml unter templates\docs\de\charger angelegt mit group: Schaltbare Steckdosen.
Aber ich bin mir nicht sicher, ob das der richtige Weg ist und habe das deswegen nicht in den MR eingebunden. Auch weil es für die Mitsubishi ja eigentlich besser unter "Wärmepumpen" passen würde.
Ein
switchdevice lässt sich nicht als Helper device anlegen. Wenn man nachswitchsucht, dann wird eineminput_booleanvorgeschlagen. Diesen Entitättyp habe ich in #25906 nebenclimateauch noch als unterstützt im template hinzugefügt.
JFYI: Ein boolean_input funktioniert schon seit einiger Zeit... [das hatte ich seiner Zeit umgesetzt] - der State passte schon aber eben die domain musste seiner Zeit dynamisch werden...
PR seems clear. Only downside I see is that it makes a simple switch the same mess as the vehicle status.
Ein boolean_input funktioniert schon seit einiger Zeit... [das hatte ich seiner Zeit umgesetzt] - der State passte schon aber eben die domain musste seiner Zeit dynamisch werden...
@marq24 ...und die hatte ich anscheinend beim Templateservice vergessen?
Bitte Abstimmung zum PR ja/nein per Daumenmeldung hier.
Die Verlinkung von #25303 scheint mir nicht passend zu sein.
PR seems clear. Only downside I see is that it makes a simple switch the same mess as the vehicle status.
Was meinst du mit "the same mess as"?
https://github.com/evcc-io/evcc/blob/master/util/homeassistant/connection.go#L126