Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Android51]

@unltdnetworx
vielen Dank für deinen Blog, leider kann ich die Kommentarfunktion nicht nutzen. Beim Absenden erhalte ich immer einen Fehler.
Ich erhalte beim Starten des java-scripts "modify-objects" immer Fehlermeldungen. Kannst du mir weiterhelfen, woran es liegen könnte?
Ich habe die var modbus.instanz auf 0 geändert, weil es meine einzige ist. Kann es daran liegen, dass ich inzwischen den Modbus-Adapter in Version 5.0.11 installiert habe. Oder liegt es daran, dass ich nicht alle Modbus Adressen importiert habe, sondern nur die, die ich für mich als notwendig erachte. Heizungstyp ist mit wpm-system auch richtig gewählt.

17:34:39.222 error javascript.0 (1486) script.js.Modbus_ISG_Modified_Objects: TypeError: Cannot read property 'common' of null
17:34:39.222 error javascript.0 (1486) at modifyDP (script.js.Modbus_ISG_Modified_Objects:7:17)
17:34:39.222 error javascript.0 (1486) at script.js.Modbus_ISG_Modified_Objects:18:1
17:34:39.223 error javascript.0 (1486) at script.js.Modbus_ISG_Modified_Objects:51:3

[unltdnetworx]

@android51
Fehler in dem Skript können dadurch auftauchen, dass es manche Datenpunkte bei dir nicht gibt. Darauf deutet auch die Meldung mit "null" hin. Das Skript muss ohnehin nur einmal laufen.
Schau mal in den Datenpunkten nach, ob es dort im Objektebaum nun Dropdowns für die Werte gibt. Z.B.: bei "modbus.1.holdingRegisters.41001_Betriebsart" (bei deiner Heizung vllt. auch anders benannt). Dort sollte dann "Automatikbetrieb(11)" statt dem Wert "11" stehen.
Wenn das so ist, dann hat alles funktioniert und das Skript kann gestoppt werden.

[Android51]

@unltdnetworx
es hat jetzt offenbar funktioniert. Aber die Betriebsart wird weiterhin bei mir mit 3, anstatt Komfortbetrieb.
41520_Reset wurde auch nicht modifiziert.

[unltdnetworx]

@android51
Dieses Skript ist ja erst mal nur eine "Komfortfunktion" für besser lesbare Werte, beeinträchtigt die Funktion aber nicht. Damit kann kannst du dich im Nachgang nochmal beschäftigen. Klappt es mit dem anderen Skript? Achtung, das zweite Skript muss durchgehend laufen.

[Android51]

@unltdnetworx
ja, das andere Script funktioniert. Vielen Dank!
Theoretisch müsste ich doch die beiden fehlenden Werte (z. B. Komfortbetrieb) auch händisch in den Objektdaten ergänzen können (3 = Komfortbetrieb usw. ). Kann mir das ja von einen anderen, über das erste Script ergänzte Werte, abgucken, oder?
z. B. "states": "{"0":"UNBESCHALTET","1":"GESCHALTET"}"

[unltdnetworx]

@android51
Das kann man auch händisch im Objektbaum mit aktiviertem Expertenmodus ändern. Mittels Klick auf den Stift (Objekt bearbeiten) ganz hinten in der Zeile zum Wert, neben dem Papierkorb-Symbol.
Bei mir sieht die Zeile (common.states) für die Betriebsart im Modbusadapter (modbus.0.holdingRegisters.41001_Betriebsart) so aus:

"states": "{\"11\":\"AUTOMATIK\",\"1\":\"BEREITSCHAFT\",\"3\":\"TAGBETRIEB\",\"4\":\"ABSENKBETRIEB\",\"5\":\"WARMWASSER\",\"14\":\"HANDBETRIEB\",\"0\":\"NOTBETRIEB\"}"

[KaiLight]

Gelöst: Im Modbus-Adapter fehlte bei mir bei Verbindungsparameter der Eintrag Typ: "Master". :man-facepalming: Das war erstmal nicht aufgefallen, da ja die Kommunikation anscheinend funktionierte (Adapter war grün und es kamen Daten). Nachdem ich "Master" aktiviert habe und die Register nochmal frisch eingeladen habe, funktionierte es wieder wie gewollt. (Im Modbus Adapter V5.x erscheint dieser Eintrag eher "unauffällig", wenn nicht gefüllt.)

~~@tippy88 Hast Du das mit dem Eingang 1 lösen können? Ich beobachte bei mir auch, dass wenn ich den Eingang 1 schalte, dieser nach ca 2 sec wieder zurück schaltet.
Prinzipiell reagiert das ISG dann auch und schaltet in Modus 3. Aber der Status ist nicht eindeutig steuerbar und fällt wieder zurück. (Skripte laufen keine, außer das lueftungsintegralgeraet.js )

Damit verbunden die Frage in die Runde: Ist es richtig, dass der angezeigte Status im Modbus-Adapter (null) angezeigt wird? Generell habe ich das Problem, dass die Holding-Register (trotz Abarbeiten der Anleitung von @unltdnetworx (Vielen Dank Dir), nachdem ich das System leider neu aufsetzen musste, nicht mehr "grün" angezeigt werden und die Temperaturwerte z.B. alle auf "0" sind. Die Input-Register funktionieren wie erwartet.

Ich hatte im November schonmal "geübt" (die PV-Anlage war noch nicht fertig) und da hat dann alles nach Anleitung funktioniert, und ich konnte dann per VIS den Eingang manuell schalten und die WP hat den Status entsprechend geändert.
Jetzt wo die PV-Anlage endlich produktiv ist, war nach einem Update des Systems der iobroker kaputt und ich musste nach einigen Reparaturversuchen alles neu aufsetzen. Seitdem versuche ich seit Stunden den SG_Ready_Eingang1 (4002) wieder wie gewohnt nutzen zu können. Hat noch jemand Tipps?
(Setup: Tecalor THZ404, ISG Web mit V12.2.1, Modbus-Adapter, iobroker auf MX Linux Wildflower, Holding register kopiert aus stiebel-modbus/lueftungsintegralgeraet/modbus-adapter-version-3/)

Vielen Dank im Voraus
Kai~~

[Android51]

@unltdnetworx
ich setze mich nunmehr mit deinem Script "Heizung bei PV-Überschuss..." auseinander. Ich verstehe nicht so ganz, was es mit dem Wert "Heizstufe" aus dem ISG-Adapter auf sich hat.
Zitat: "Der Wert, ob die Heizung momentan läuft wird mittels der Heizstufe ermittelt. Da ich bisher keine Möglichkeit entdeckt habe diesen Wert mit Modbus zu ermitteln, ist zusätzlich auch der Stiebel-ISG-Adapter installiert."
Unter welcher Rubrik im ISG-Web finde ich diesen Wert? finde ihn nämlich bei mir nicht. Gibt es weiterhin keine modbus-Möglichkeit, den Betrieb der Heizung zu ermitteln?
Was genau ist damit gemeint, "ob die Heizung momentan läuft". WW-Ladepumpe oder Pufferladepumpe ließe sich ermitteln.
Sorry, für die vielleicht blöden Fragen ;-)

[Android51]

Gibt es inzwischen einen Lösungsansatz, warum der SG Ready Eingang1 sobald er aktiviert bzw. verändert wird, auf (null) springt?

[Android51]

Ich habe das Problem anscheinend gelöst, für diejenigen, die es interessiert:
im Modbus-Adapter fehlte hinten das Häkchen bei "Abfrage"

Nachdem dieses gesetzt wurde, lässt sich der Wert schalten und bleibt dann auf 1 bzw. geschaltet. Falls dies andere, negative Auswirkungen hat, bitte ich um Mitteilung.

Ich habe aber noch eine andere Beobachtung gemacht. Wenn ich den SG Ready Eingang 1 schalte, dann werden die von mir im ISG Web hochgesetzten Werte forciert (Warmwasser z. B. 54 °). Ich stelle aber bei jedem Schaltvorgang fest, dass die Warmwasserproduktion bei ca. 46 ° aufhört und ein paar Minuten lang steigt die Temperatur dann noch auf 47 oder 48 °. Warum heizt der nicht bis auf 54 °?

[Schimi]

@android51 WW Lernfunktion vielleicht an?.... Das würde so ein verhalten zumindest erklären...

[Android51]

@schimi
Ja, die Funktion habe ich tatsächlich aktiviert. Ich habe nur angenommen, dass das Schalten des SG Ready Eingang 1 sich darüber hinwegsetzt und die forcierten Werte trotzdem erreicht.
Werde es mal ausprobieren... Danke

[Android51]

Es hat funktioniert. Die Warmwassertemperatur ist nach der Änderung der Einstellungen bis zu meinem forcierten Wert angestiegen.
Ich habe nur beobachtet, dass sich ab ca. 48 Grad Wassertemperatur der Heizstab eingeschaltet hat. Ist das üblich? Hätte eher so ab > 55 Grad damit gerechnet.
Durch den Heizstab geht der Strombedarf nochmal richtig in die Höhe! Da bleibt fast zu überlegen, den forcierten Wert niedriger zu lassen, damit der Verdichter das ohne Unterstützung schafft.

[Schimi]

@android51 Ich habe die Sicherung für den Heizstab Aus... so bricht er mit der WW Lernfunktion die aufbereitung ab... bei mir klappt das ganz gut...

[JB_Mystery]

@android51
Noch als Hinweis: Je nach Heizung kannst du in den Einstellungen/Warmwasser/Grundeinstellung eine Zeitsperre NE einstellen. Damit kann man das Zuschalten der Heizstäbe verzögern. Aber viel mehr als 50°C geht nicht ohne Heizstäbe.

[Android51]

@schimi
Wenn du die Sicherung für den Heizstab ausgeschaltet hast, was passiert denn dann, wenn du die Warmwasser Lernfunktion deaktiviert? Welche Warmwasser-Temperatur erreicht dann der Verdichter?

[unltdnetworx]

@android51
Bei meiner Wärmepumpe ist das einstellbare Maximum 55°C plus Hysterese Wert. Das hatte ich lange Zeit zum Überheizen. Damit wurde das Warmwasser auf 57,1°C aufgeheizt.

Allerdings hat mit der Servicemitarbeiter vom Maximum abgeraten. Der Verdichter bzw. das Öl würde wohl zu heiß werden und das wäre auf Dauer schlecht.

Jetzt habe ich 53°C eingestellt plus 2 Grad Hysterese. Dann schaltet der Verdichter bei 55,1°C ab.

[Schimi]

@android51

ich kann WW auf 60 stellen (so steht es auch wenn ich überheitzen will)

ohne Lernfunktion; habe ich beobachtet das er versucht "ewig" die 60 zu erreichen (sehr selten schafft er es auch, halte das aber nicht für "so gesund" für den Verdichter).... gibt dann irgendwann (ohne Fehler) auf... was er erreicht schwankt

mit Lernfunktion; er hört früher auf mit der erhitzung... manchmal schon bei um 54-55 (oft im winter) manchmal bei um die 58...

Habe eine SoleWP

edit
mit Lernfunktion hört es sich so an,a ls ob das verfolgt wird was @unltdnetworx schrieb

[Android51]

@schimi
OK, dann liegt es an der Sole WP. Ich habe eine Luft-Wärmepumpe, da geht der Verdichter eher in die Knie und schafft meistens ca. 48 Grad Warmwasser ohne Unterstützung.

[MarkusL]

Hallo zusammen,
ersteinmal danke für die vielen Infos!
Ich habe einen WPM4 mit einer sehr alten Wärmepumpe (WPL23E) und versuche es mit dem aktuellen Modbusadapter (5.0.11) die Daten zu holen. Als Vorlage habe ich die Dateien für WPs und Version 3 genommen und es kommen auch Daten rein und der Adapter bleibt grün.

Ich habe aber leider noch ein Problem mit den Scripten. Die Änderung der DPs für Katalogwerte scheint nicht zu klappen. Ich bekomme immer für jeden DP den Fehler

Object modbus.1.holdingRegisters.41501_Betriebsart is invalid: obj.common.states has an invalid type! Expected "object", received "string"

In dem Datenpunkt steht zB eine 3 drinnen, sie wird nicht ersetzt. Der Modbusadapter ist der 2.Instanz, läuft also auch unter 1, wie im ursprünglichen Script.
Wisst Ihr wie ich das korrigieren kann?
Danke!
Markus