Hallo,

meine Lösung für die Aufgabe "PV-Überschussladen mit Wallbox Heidelberg Energy Control über Modbus, ioBroker und Blockly" möchte ich hier vorstellen:

Anbindung über RS485
Bei Recherchen habe ich mehrere Adapter probiert. Am erfolgversprechendsten war das oft angepriesene Hösi Universalgateway.
Nach meinem Verständnis kann diese allerdings gar nicht funktionieren, da die von der Heidelberg geforderten 19200/8E1 nicht in der Hösi einstellbar sind.

Am Ende klappte es prima mit einem 2,75€ RS485-USB-Adapter in einer ZWEITEN Raspberry in der Garage.

Heidelberg und USB-Adapter werden mit zwei Adern eines geschirmten und verdrillten CATx-Netzwerkkabels verbunden. Auf dem Stick wird ein 120Ohm-Widerstand an den grünen Schraubklemmen mit eingesetzt. Die Heidelberg ist intern terminiert.

Einstellungen Heidelberg
DIP Schalter Config: Block S4/4 = On (ID1), S6/2 = On (Endwiderstand Ein). Die Wallbox ist somit Follower mit der ID1 ohne Master und intern terminiert.
Den Drehschalter S1 (Mitte unten) sollte man von 0 (max 6A) auf 5 (max 16A) stellen.

Einrichtung Modbus RTU im ioBroker
Auf der ZWEITEN Raspberry wird ganz normal ein frisches ioBroker installiert. Als Adapter dann modbus. Dem eingesteckten RS485-USB-Stick wird /dev/ttyUSB0 zugewiesen.
Einstellungen dann auf /dev/ttyUSB0,19200/8E1 und ID1

Die Eingangsregister wurden schon in anderen Postings gut beschrieben:

Die Holdingregister funktionieren bei mir (v1.0.7) nur genauso (Haken bei Abfrage) wie beschrieben:

Die Tabelle mit den Registern sollte man parat haben:
https://www.amperfied.de/wp-content/uploads/2022/06/ModBus-Register-Tabelle.pdf
https://www.amperfied.de/wp-content/uploads/2022/06/Erweiterte-ModBus-Registerbeschreibung.pdf
https://www.amperfied.de/de/service-support/downloads/
Relevant ist auch die Version der Firmware. Bei mir steht unter der Adresse 4/30005 die Decimal 263, somit habe ich die Firmware v1.0.7. Dec264 wäre v1.0.8.

Box in Betrieb nehmen
Nun Instanz neu starten. Es muss grün werden, sonst weiter suchen (siehe unter Protokolle). Am einfachsten ist es, wenn dabei ein Auto angeschlossen ist, um potentielle Probleme (die ich nicht hatte) mit Standby der Box erstmal auszuschliessen.
Auto nur anschliessen, wenn die Box nicht mehr blau blinkt.

Wenn man nun in die 40262 z.B. 100 für 10A schreibt, dann sollten die Modbus-Objekte für einphasiges Laden bei angeschlossenem Auto so aussehen (L1 lädt mit 10.1A):

• Erst wenn bis hier alles einwandfrei läuft und das Auto mit den manuell eingestellen Werten lädt, geht es weiter! Blockly ganz am Schluß!
• Wenn nun alles auf der zweiten Raspberry funktioniert, dann werden beide Raspberry mit Master/Slave verbunden. Ein klasse Feature von ioBroker!
  Wie das mit dem Master/Slave --also multihost-- funktioniert, findet man im Internet, z.B. hier:
  https://www.youtube.com/watch?v=o2AT1E0FDD0

Das Blockly zum PV-Überschussladen ist im Gegensatz zur Technik ja eine Spielwiese

Meine Gedanken dazu:

• Grafiken werden optional über InfluxdDB und Grafana/eCharts erstellt.
• der zur Verfügung stehende Überschussstrom wird bei mir über einen Sensor direkt am Zähler erfasst ==> powerfox/poweropti
  https://poweropti.powerfox.energy/. Für den powerfox gibt es sogar einen iobroker-Adapter -- sehr einfache Sache.
  Bei den meisten wird das sicherlich irgendwie über den Wechselrichter gehen.
• bei mir hat PV-Überschuss nur einphasig Sinn. Über die Werte von L1/L2/L3 könnte man sich dreiphasiges PV-Laden bauen.
• Über VIS kann ich per Smartphone PV-Laden ausschalten, er lädt dann max (siehe weiter unten im Blockly)
• Wer will kann sich analog zu openWB noch Features wie Grundladen (Min+PV), also z.B. immer min 10A leicht einbauen
• Die Debug-Meldungen sollte man operativ noch ausblenden (rechte Maustaste auf debug und "Bausteine deaktivieren").
• Zukünftig kann man so intelligent weitere Features wie Wärmepumpe oder DIY-Solarspeicher leicht integrieren.
• Ja, sogar eine Lastverteilung unter mehreren Wallboxen, auch verschiedener Firmen, ist machbar. Die Boxen müssen nur irgendwo im ioBroker Datenpunkte ablegen, egal ob über mqtt, modbus oder sonstwas.

Kurzum, eine Spielwiese :

Und so sieht dann das alles im Betrieb aus

Rot ist der Hausverbrauch. Orange ist die Heidelberg, die sich sehr feinfühlig bemüht den Hausverbrauch zu stabilisieren.

Hauptsache nichts einspeisen

@crunchip Danke!
Ja, die mobile Objekte-Ansicht ist auf dem Handy nicht wirklich brauchbar.
Wenn ich einfach nur ID+Wert auf dem Handy anschauen will, muss ich mir immer eine VIS-Seite bauen.
Oder gibt es da andere Möglichkeiten, wie spezielle Adapter für die universelle Objekte-Ansicht von ID+Wert? Früher hatte ich immer auf dem Handy die alte GUI laufen. Nicht so schön, aber machte was es sollte.

Glaube die Lösung für das Problem gefunden zu haben:

-- Ubuntu fährt heutzutage eine Auto-Update-Funktion (zu viele machen nie/zu selten Updates).
-- iobroker (evtl. nur mit dem neueren Admin-Modul?) zeigt dann an, dass es neue Betriebssystem-Updates gibt.
-- Allerdings will ich diese Funktion gar nicht, von Zeit zu Zeit mache ich schon eigenverantwortlich ein update/upgrade.
-- Ubuntu soll also gar nicht von selbst nachschauen, ob es Updates gibt. Wenn Ubuntu das nicht weiß, dann nervt auch iobroker nicht

--> abschalten kann man das in:

martin@Haus:/etc/apt/apt.conf.d$ cat 20auto-upgrades
#APT::Periodic::Update-Package-Lists "1";
#APT::Periodic::Unattended-Upgrade "1";
 
APT::Periodic::Update-Package-Lists "0";
APT::Periodic::Download-Upgradeable-Packages "0";
APT::Periodic::AutocleanInterval "0";
APT::Periodic::Unattended-Upgrade "0";

Die ersten beiden Zeilen sind das Original, die anderen mit der "0" sind neu.

Nun noch einmal von Hand ein "sudo apt update & apt upgrade" machen und dann sollte Ruhe sein.

Ich habe oben geschrieben, dass ich "glaube" die Lösung gefunden zu haben. "Wissen" werde ich das erst, wenn in nächster Zeit wirklich keine nervigen Meldungen mehr kommen

Falls das ein Admin-Entwickler liest: wenn iobroker sich jetzt auch um Betriebssystem-Updates kümmert, dann schalten viele (wie ich) diese Auto-Update-Funktion einfach aus, was den Sicherheitsvorteil in Ubuntu leider ad absurdum führt. Wenigstens sollte man aus meiner Sicht das im Admin-Modul deaktivierbar machen.

@iobrokerin sagte in Heidelberg Energy Control / PV-Laden / Modbus / Blockly:

@nitrox9 Hallo nochmal, ich verstehe nicht, warum bei deinem Screenshot alle Adressen eines höher sind, als in der Tabelle von Heidelberg.

Hat was mit dem Modbus-Protokoll, dem Offset und auch den Herstellerangaben zu tun.
Google mal nach „modbus offset +1“ oder so.

@jey-cee Danke, jetzt weiss ich wie ich das einzuordnen habe.

Habe erst vor einigen Wochen/Monaten mit ioBroker angefangen und alles Wissen aufgesogen, was verfügbar war.
Auch die Alexa-Integration war sehr wichtig. Im Zuge dessen kam der iOT-Adapter ins System. Dazu andere Dinge wie natürlich der Alexa-Adapter selbst und die Alexa-Anbindung über node-red.
Nach Abschaltung des iOT-Adapters funktioniert Alexa noch immer komplett genau so über iobroker wie gewünscht -- also alles gut.
Insofern ist meine Lernkurve noch immer steil, eine reine "Spielwiese" ist so eine umfassende Haussteuerung nicht mehr. Auch aus Security-Gründen schärft einem das das Bewusstsein, wenn Fremde Zugriff auf das Haus über auch ungeahnte Wege bekämen.

Danke für die Mühen!

@thomas-braun
Glaube die Lösung für das Problem gefunden zu haben:
-- Ubuntu fährt heutzutage eine Auto-Update-Funktion (zu viele machen nie/zu selten Updates).
-- iobroker (evtl. nur mit dem neueren Admin-Modul?) zeigt dann an, dass es neue Betriebssystem-Updates gibt.
-- Allerdings will ich diese Funktion gar nicht, von Zeit zu Zeit mache ich schon eigenverantwortlich ein update/upgrade.
-- Ubuntu soll also gar nicht von selbst nachschauen, ob es Updates gibt. Wenn Ubuntu das nicht weiß, dann nervt auch iobroker nicht

--> abschalten kann man das in:

martin@Haus:/etc/apt/apt.conf.d$ cat 20auto-upgrades
#APT::Periodic::Update-Package-Lists "1";
#APT::Periodic::Unattended-Upgrade "1";

APT::Periodic::Update-Package-Lists "0";
APT::Periodic::Download-Upgradeable-Packages "0";
APT::Periodic::AutocleanInterval "0";
APT::Periodic::Unattended-Upgrade "0";

Die ersten beiden Zeilen sind das Original, die anderen mit der "0" sind neu.

Nun noch einmal von Hand ein "sudo apt update & apt upgrade" machen und dann sollte Ruhe sein.

Ich habe oben geschrieben, dass ich "glaube" die Lösung gefunden zu haben. "Wissen" werde ich das erst, wenn in nächster Zeit wirklich keine nervigen Meldungen mehr kommen

Achja, einige Autos wie die ZOE brauchen min 8 A, um überhaupt zu starten (auf 7 zu springen).

@adri525 Wie die Doku schon sagt:
— 2: kein Kabel eingesteckt
— 4: Kabel eingesteckt, aber kein Strom
— 5: Strom, aber Auto will nicht laden
— 7: Auto lädt

Bei 5 liegt es am Auto. Also z. B.
— Auto ist voll
— Auto ist für späteres Laden programmiert
— eingestellter SOC im Auto erreicht

An Wallbox oder iobroker liegt es bei 5 nicht.

Grüße

Achja, einige Autos wie die ZOE brauchen min 8 A, um überhaupt zu starten (auf 7 zu springen).

@adri525 Wie die Doku schon sagt:
— 2: kein Kabel eingesteckt
— 4: Kabel eingesteckt, aber kein Strom
— 5: Strom, aber Auto will nicht laden
— 7: Auto lädt

Bei 5 liegt es am Auto. Also z. B.
— Auto ist voll
— Auto ist für späteres Laden programmiert
— eingestellter SOC im Auto erreicht

An Wallbox oder iobroker liegt es bei 5 nicht.

Grüße

@iobrokerin Super! Schon interessant, dass man Gemini und Co bei sowas schon gut gebrauchen kann.

Der Raspi ist seit Jahren bei jeder Temperatur und Luftfeuchtigkeit in der Blechgarage. Alles gut, keine Probleme. Lasse das Ding da ruhig auf Dauer laufen. Die paar Watt (gerade bei den alten Raspis) sind nicht wirklich relevant.
Viel Spaß!

Am Rande: das oben aufgeführte Blockly ist sehr rudimentär und dient eher zum Lernen.
Heute puffere ich den Strom im Hausakku und schalte die Wallbox erst aus, wenn der Puffer (z.B. 10%) im Hausakku aufgebraucht ist -- aber das soll jeder machen, wie er will.

@iobrokerin Solche Meldungen habe ich noch nie gesehen.

Als Tipp: bei sowas hat mir chatgpt.com schon richtig helfen können.
==> Einfach schreiben was du hast. z.B. "Ich möchte eine Heidelberg Wallbox per modbus an iobroker betreiben."
dann
"folgende Fehlermeldung bekomme ich: ......"

==> einfach mal probieren, bin selbst erstaunt, was heutzutage geht.

Glaube die Lösung für das Problem gefunden zu haben:

-- Ubuntu fährt heutzutage eine Auto-Update-Funktion (zu viele machen nie/zu selten Updates).
-- iobroker (evtl. nur mit dem neueren Admin-Modul?) zeigt dann an, dass es neue Betriebssystem-Updates gibt.
-- Allerdings will ich diese Funktion gar nicht, von Zeit zu Zeit mache ich schon eigenverantwortlich ein update/upgrade.
-- Ubuntu soll also gar nicht von selbst nachschauen, ob es Updates gibt. Wenn Ubuntu das nicht weiß, dann nervt auch iobroker nicht

--> abschalten kann man das in:

martin@Haus:/etc/apt/apt.conf.d$ cat 20auto-upgrades
#APT::Periodic::Update-Package-Lists "1";
#APT::Periodic::Unattended-Upgrade "1";
 
APT::Periodic::Update-Package-Lists "0";
APT::Periodic::Download-Upgradeable-Packages "0";
APT::Periodic::AutocleanInterval "0";
APT::Periodic::Unattended-Upgrade "0";

Die ersten beiden Zeilen sind das Original, die anderen mit der "0" sind neu.

Nun noch einmal von Hand ein "sudo apt update & apt upgrade" machen und dann sollte Ruhe sein.

Ich habe oben geschrieben, dass ich "glaube" die Lösung gefunden zu haben. "Wissen" werde ich das erst, wenn in nächster Zeit wirklich keine nervigen Meldungen mehr kommen

Falls das ein Admin-Entwickler liest: wenn iobroker sich jetzt auch um Betriebssystem-Updates kümmert, dann schalten viele (wie ich) diese Auto-Update-Funktion einfach aus, was den Sicherheitsvorteil in Ubuntu leider ad absurdum führt. Wenigstens sollte man aus meiner Sicht das im Admin-Modul deaktivierbar machen.

@thomas-braun
Glaube die Lösung für das Problem gefunden zu haben:
-- Ubuntu fährt heutzutage eine Auto-Update-Funktion (zu viele machen nie/zu selten Updates).
-- iobroker (evtl. nur mit dem neueren Admin-Modul?) zeigt dann an, dass es neue Betriebssystem-Updates gibt.
-- Allerdings will ich diese Funktion gar nicht, von Zeit zu Zeit mache ich schon eigenverantwortlich ein update/upgrade.
-- Ubuntu soll also gar nicht von selbst nachschauen, ob es Updates gibt. Wenn Ubuntu das nicht weiß, dann nervt auch iobroker nicht

--> abschalten kann man das in:

martin@Haus:/etc/apt/apt.conf.d$ cat 20auto-upgrades
#APT::Periodic::Update-Package-Lists "1";
#APT::Periodic::Unattended-Upgrade "1";

APT::Periodic::Update-Package-Lists "0";
APT::Periodic::Download-Upgradeable-Packages "0";
APT::Periodic::AutocleanInterval "0";
APT::Periodic::Unattended-Upgrade "0";

Die ersten beiden Zeilen sind das Original, die anderen mit der "0" sind neu.

Nun noch einmal von Hand ein "sudo apt update & apt upgrade" machen und dann sollte Ruhe sein.

Ich habe oben geschrieben, dass ich "glaube" die Lösung gefunden zu haben. "Wissen" werde ich das erst, wenn in nächster Zeit wirklich keine nervigen Meldungen mehr kommen

@thomas-braun sagte in Betriebssystem-Paket-Updates verfügbar trotz De-Installation:

@est58

Im Admin werden jetzt auch anders als 'früher' auch Betriebssystem-Updates angezeigt.

Bei mir laufen 4x iobroker auf 3x Raspi und 1x PC (Master/Slave). Alles ist soweit identisch und up-to-date (stable).
Nach Neuinstallation auf dem PC (Ubuntu) kommen jetzt auch diese nervigen Betriebssystem-Updates auf diesem PC (Master). Auf den 3x Raspi nicht.
Das muss man doch irgendwo abschalten können?! In Admin finde ich das nicht.
Eine Idee? Danke im voraus!

@paul53 sagte in "Wurde aktualisiert"-Erkennung dauert zu lange:

@homoran sagte: durch debug Bausteine klären

... z.B. so:

Erstmal vielen Dank euch beiden. Diese Art von "Falls Objekt" habe ich noch nie benutzt, ist aber hier eindeutig die bessere Wahl.
Ich lasse das damit mal laufen, in den ersten Tests macht es was es soll und schaltet sofort die Lampe ein

die leuchtende Lampe in der vis beweist ja, dass der steuere Befehl sofort abgesetzt wird und im Objekt umgeschaltet wird.

Sorry, da habe ich mich falsch ausgedrückt: auf meiner vis-Zigbee-Seite zeige ich den Offen-Zustand ebenfalls mit einer Lampe an (könnte ich mal ändern):

Das VIS-Icon für das Licht bleibt wie beschrieben natürlich aus -- bis sie wirklich leuchtet.

Hallo,

eigentlich Standard: Zigbee-Türkontakt öffnet, iobroker erkennt eine "wurde aktualisiert" und schaltet bei "open" das Licht an.

Das klappt auch, aber manchmal dauert es mindestens 5 sec (oder noch viel länger) bis die Lampe eingeschaltet wird.
Entgegen meiner ersten Vermutung liegt es nicht an Zigbee, der Eintrag "open" ist sofort da und VIS zeigt sofort eine leuchtende Lampe.
Also dauert es manchmal ewig, bis offenbar das "wurde aktualisiert" erkannt wurde und das Blockly losrennt. "wurde geändert" geht genauso schlecht.

Eine Idee? An IO-Problemen glaube ich nicht. iobroker läuft auf einem potenten i5 unter proxmox und ist auch sonst eher gelangweilt.

Danke vorab.