Nach etwas rumprobieren: CardChart verkraftet keine Werte > 211 und die Ticks müssen ebenfalls mit Faktor 10 skaliert angegeben werden. Gleichzeitig rundet es dummerweise nur auf eine Nachkommastelle, sodass ich bei Strompreisen weder Cent (27 Ct -> 270 -> Anzeigefehler) noch Euro (wird auf volle 10 Cent gerundet --> zu ungenau) angeben kann. Man könnte es ja skalieren, aber dann stimmen die Werte natürlich hinten und vorne nicht mehr.

Die Frage ist da sicherlich, ob die Klimaanlagen keine Zukaufteile aus Fernost sind. Bei Bosch/Buderus scheint das bei einigen (oder allen?) Brauchwasserwärmepumpen der Fall zu sein. Die haben den hauseigenen EMS Bus dort auch nicht implementiert....

@lukesmart hast du deinen Esphome code noch am laufen? ich würde ihn gerne auch einsetzen. allerdings brauch ich noch ein wenig schützen hilfe zu HA. hast du zufällig einen screenshot wie das dann in HA aussieht? Danke und Grüße Robert

Betreff: Ventilumschaltung WW→Heizen nicht an Pumpennachlauf gekoppelt – Parameter gesucht Hallo zusammen, ich habe ein M-TEC WPS-W618 mit KEBA/KeEnergy-Steuerung und bin bei der Optimierung über Folgendes gestolpert: Nach Ende der WW-Erzeugung schaltet das 3-Wege-Ventil sofort von WW-Puffer auf FBH-Puffer um. Die Umwälzpumpe (WP↔Puffer) läuft aber noch 60–120 s nach (von mir bewusst eingestellt, um die Restwärme aus dem Kompressor besser abzuführen und auch schneller abkühlen zu lassen). Das Problem: Die Ventilumschaltung scheint nicht an den Pumpennachlauf gekoppelt zu sein. Dadurch wandert die Restwärme aus dem Nachlauf nicht in den WW-Puffer (wo sie eigentlich hingehört), sondern direkt in den FBH-Puffer – was im Sommer (passive Kühlung) sogar leicht gegenläufig wirkt. Bei anderen Herstellern (Vaillant, Viessmann) ist das offenbar ein eigener, separat einstellbarer Parameter (z. B. Vaillant D.72 – Nachlaufzeit vor Ventilumschaltung, 0–600 s, Default 80 s), bei dem die Ventilumschaltung explizit erst nach Ablauf der Nachlaufzeit erfolgt. Hat jemand von euch einen entsprechenden Parameter in der APPL.CtrlAppl.sParam-Struktur gefunden oder weiß, ob sich das Ventil zeitlich von der Pumpe entkoppeln/koppeln lässt? Ich vermute es könnte irgendwo im Umfeld von bufferTank oder einer Mischer-/Ventil-Sektion sitzen, analog zu den heatCircuitMixer-Parametern, die hier schon mal gepostet wurden. Über die Modbus-Liste habe ich bisher nichts Eindeutiges gefunden – falls da jemand ein Register kennt, das in Frage kommt, wäre ich für einen Hinweis sehr dankbar. Danke und Grüße

Die Register sind bei iobroker 40000 +1.

Naja jedenfalls hab ich mir ein paar günstige WiFi Thermostaten jetzt besorgt die Smart Life und Tuya kompatibel sind. Einen für's Büro, und drei als Gruppe für's Wohnzimmer. Mal sehen wie die Zuverlässigkeit und der Batterieverbrauch ist. Einen oder zwei Raum oder Wandthermostaten werde ich mir noch raussuchen und bestellen. Zum Testen, gruppieren und spielen reicht das dann bis der richtige Einsatz im Winter kommt. Das einrichten war ein Kinderspiel, bei mir mit der Tuya App gemacht weil ich schon ein paar Geräte im Womo habe. Danke für die Infos, sollte sich etwas abzeichnen gebe ich bescheid. Schöne Grüße Florian

Hallo, habe das nur mit beigefügt, weil ich vermutet hatte, dass der Datenpunkt unter Notification abgelegt sein müsste… Habe alles einmal per MQTT abgefragt. Da bekomme ich einen Unknown Claas 111 Datenpunkte. Hier kann man etwas heraus ableiten. Aber das wäre für die Abfrage wirklich kompliziert….. habe jetzt einmal ein Issue bei ZWave JS UI angelegt. [image: 1781880917491-img_5992.jpeg]

@dimaiv Danke für den Hinweis. Habe ich mit schon gedacht und mittlerweile auch erledigt, da ich das vorrätig hatte.

An was könnte das liegen, kann ich etwas testen?

Zum Abschluss hier nochmal die Lösung zusammengefasst: function ZigbeePowerPluginReset(sDevice) { sendTo('zigbee.0', 'sendToZigbee', { "id": sDevice, "ep": "1", "cid": "genBasic", "cmd": "resetFactDefault", "cmdType": "functional", "zclData": { "null": {} }, "cfg": null }); setTimeout(function () { setState(sDevice+'.power_outage_memory', 'on', false); }, 5000); } ZigbeePowerPluginReset('zigbee.0.XXXXXXXXXXXXXXX'); Das ganze gelöst via JS-Script. ALLE XXXXXXXXXXXXXXX durch den korrekten Wert ersetzen. Ro75.

Ich und GPT haben das skript nochmal was geupdatet das hiermit nun auch mein Wechselrichter sauber erstellt und geupdatet wird. https://gist.github.com/9Mad-Max5/ea29c3bcc109ef485cbecb89415fb365 @wusa Über den Weg kommen im prinzip alle Daten von den Marstek-Geräten aus der cloud auf dein ioBroker instanz. Leider ist es ein wenig Mühsam aber grundsätzlich klappt es. Auch der SoC wird damit normalerweise korrekt übertragen. Dreh und angelpunkt aus meiner Sicht ist das eine docker container Instanz vorhanden ist und ein MQTT broker am besten den Mosquitto und nicht den internen von ioBroker. Der lief bei mir unzuverlässig was sehr viel Mühe verursachen kann.

Das ist unter bestimmten Umständen normal. Dafür gibt es diese Anleitung (Github link). Nach der hättest du das eigentlich auch ohne Neustart der Instanz machen können bis das Netz läuft.

Die Wetterstation sendet nur im 10sek- Takt und je nach Windrichtung ist das für meine Markise fast vollkommen unkritisch. Die Windrichtungen könnte ich zwar noch mit auswerten, aber ich erhoffe mir mit einem Sensor, der vorne an der Markise montiert wird, sicherere Werte

Ok. Sieht dann wohl so aus als AutoUpdate da weiterhin aktiv ist. Muss ich wohl mal mit SMA Kontakt aufnehmen. Meine bisherigen Versuche (waren schon 2-3) mit denen aber irgendwie in Kontakt zu treten oder besser von Ihnen Antworten zu erhalten waren aber nicht wirklich erfolgreich. Aber ich versuche es einfach nochmal. Vielen Dank mal soweit, das hat schon sehr geholfen zur Einordnung.

Da Messwerte im Growatt WR alle mit einer Stelle hinterm Komma als Integer angezeigt werden, müssen die Werte für die Weiterverarbeitung noch durch 10 geteilt werden. Damit die Einheit irgendwie korrekt ist, habe ich ein kleines d für "Dezi" - also ein zehntel - vorgestellt...