UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[bolliy]

@lcars sofern du den modbus-proxy einsetzt und dieser funktioniert, dann solltest du die auto-adjust Funktion aktivieren. Dann klappt es bestimmt auch mit dem angestrebten 20s Intervall. ;)

[dragst3r]

@lcars ich übergebe die Werte via MQTT an EVCC. Erscheint mir das einfachste.

[lcars]

Leider läuft der modbus-proxy bei mir nicht und bricht beim Start immer mit einer Fehlermeldung ab die auch andere berichten. Getestet mit docker und auch richtig installiert auf raspi.
Ich habe da als Alternative dies nun über einen haproxy laufen und es geht. Jedenfalls ruft der Adapter die Infos nun über diesen Proxy der max. nun eine Connection zu dem Huawei Dongle aufbaut.

Mit dem NRGkick muss ich dann mal sehen ob das parallel nun läuft, aber da scheint bei denen die Software wohl noch buggy zu sein.

[bolliy]

@lcars ich könnte mir vorstellen einen sog. modbus-read-cache in den Adapter einzubauen. Ein third-party device (z.B. eine Wallbox) könnte sich dann die Daten (virtueller Zähler) über den Adapter ziehen (all out of the box). Das würde sehr schnell und ohne timeouts funktionieren.
Wie ist die Meinung hierzu?

[lcars]

@bolliy Das wäre optimal. Im Grunde fragt die Wallbox auch nur irgendwelche Register ab (von versch. ModBus IDs wenn man mehr als einen Inverter hat). D.h. du müsstest diese Abfragen beantworten. D.h. es könnten auch Register sein die du selbst nicht abrufst. Und man müsste dann die Geschwindigkeit managen. Z.B. du fragst deine Liste der Register ab in dem Intervall, wenn von außen aber auf dem Cache neue Anfragen kommen zu ggf. Registern die du nicht hast, dann müsstest du das zeitlich managen damit es nicht zu schnell abgefragt wird weil es sonst wieder Timeouts oder der Busy Fehler kommt.
Weiterhin müsstest du dann auch einen Port aufmachen (am besten die Portnummer könnte man angeben) worüber man sich dann verbinden kann zu dem Cache.

[bolliy]

@lcars ich glaube die WB fragt nur Werte vom Dongle (modbus id 100) ab. Die Inverter interessieren die WB nicht. Ich habe den dongle auch schon über mein Treiber Model eingebunden.

Das sind die Daten, auf die die Wallbox scharf ist. Aus diesen Daten (kummullierte Werte der WR) kann der PV Überschuss und die WB die Ladeleistung berechnet werden. Ich hoffe nicht das WB Daten an den Dongle schreibt will - was ich aber nicht glaube:relieved:

Ich würde auch erstmal keine Anfragen an den Dongle durchreichen, sofern dieser nicht aus dem Cache beantworte werden können. Die ip adresse und der port würden über einen weiteren Tab konfigurierbar sein. Der modbus-read-cache (sinniger Name müsste noch gedacht werden) wird bei der Erstinstallation auch deaktiviert sein. Also der User muss diesen manuell aktivieren.
Stephan

[lcars]

@bolliy Wenn du eine Version hast kann ich es gern ausprobieren. Was ich eben gemerkt habe, der Dongle lässt eben nur eine Verbindung zu und reagiert eben mit den Busy und Timeout Meldungen wenn es "zu schnell" geht. Ich hatte erst Zugriff von der Wallbox auf den Dongle als ich den Adapter deaktiviert habe (die Instanz).
Lass es uns einfach mal testen. Dann würde ich mir den Workaround über den haproxy sparen bzw. das modbus-proxy Projekt scheint wohl nicht mehr richtig zu funktionieren.

[bolliy]

@lcars ja, modbus lässt nur eine Verbindung per Definition zu (modbus seriell)! Man darf nicht mit mehreren Clients auf eine modbus Instanz zugreifen - sonst hagelt es Fehler.
Der modbus-read-cache hätte auch den Vorteil, dass der dongle nicht unnötige Anfrage erhält, die ja bereits abgefragt worden sind. Die modbus Implementation von huawei ist wahrlich nicht gut gemacht. Sonst hätten ich nicht so einen Aufwand mit dem optimalen modbus timing gehabt. Meine wallbox (wallbe - Steuereinheit von phönix contakt) ist deutlich robuster. Da hatte ich noch nie timeouts oder sonstiger Fehlermeldungen.

Wenn es etwas zu testen gibt, melde ich mich gerne...

Stephan

[lcars]

@bolliy Ich denke ich konnte mein "NRGKick Problem" anders lösen. Es ist möglich eine Custom API bereit zu stellen. D.h. man kann der Wallbox eine URL geben wo sie nachfragt und die Daten abruft. D.h. ich habe mir einen Server in ioBroker gebaut der die Daten des Adapters nutzt und in JSON aufbereitet so, dass die Wallbox das verarbeiten kann. Damit umgehe ich den zweiten Abruf über den ModBus und kann auch viel schneller antworten als ModBus es könnte.
Somit bleibt der Adapter als einziges mit dem ModBus verbunden.

[bolliy]

@lcars für deine Wallbox eine super Idee! Für den Huawei SCharger geht das aber nicht, da dieser nur einen physischen Zähler oder einen virtuellen Zähler per modbus einbinden kann. Würdest du dennoch beim Testen der nächsten Version (mit modbus-server) unterstützen?

[lcars]

@bolliy Ja klar gern.

[Edde]

Hallo zusammen.

Erstmal vorweg: der Adapter klappt hervorragend.

Ich bräuchte allerdings einmal eure Hilfe bei der Unterscheidung der vielen teilweise gleich klingenden Werte. In speziellen suche ich die folgenden Objekte:
1.: Aktueller Netzbezug bzw aktuelle Einspeisung
2.: Aktueller Gesamt Vernrauch im Haus

Vielen Dank

[bolliy]

@edde danke :grinning:

Netzbezug: sun2000.0.meter.activePower
Hausverbrauch : sun2000.0.collected.houseConsumption

Das ist vielleicht auch noch interessant:
https://forum.iobroker.net/post/1118425
https://forum.iobroker.net/post/1127961
https://forum.iobroker.net/post/1128936

Da ich noch mit der Funktionserweiterung des Adapters beschäftigt bin, habe ich momentan keine Zeit die States zu dokumentieren.

Stephan

[lcars]

Generelle Frage zu dem SmartLogger. Ist der deutlich schneller als das Huawei WLAN Dongle oder reagiert das gleich? Die Abfrage des Dongles ist zwar soweit jetzt relativ stabil und es werden die Daten im Intervall von ca. 20s - 25s abgefragt. Aber was würde der SmartLogger theoretisch mehr bieten?

[bolliy]

Ich habe gerade einen neue Test-Version des Adapters sun2000 hier https://github.com/bolliy/ioBroker.sun2000 veröffentlicht. Dieser Stand wird zukünftig die Nebenversionsnummer 0.4.x erhalten.
Die Installation erfolgt über den Expertenmodus. Danach auf die „Krakenkatze“ klicken und dann „von GitHub“ den Adapter installieren.

Viele von euch kennen sicherlich das Dilemma, dass nur ein modbus Client (früher als master bezeichnet) an den Wechselrichter (Server früher Slave bezeichnet) gleichzeitig Anfragen stellen kann. Die modbus-Schnittstelle des Huawei Inverters ist leider nicht multi-client fähig!
In die Entwicklung habe ich nun ein modbus-proxy implementiert. So können nun mehrere Clients über das modbus-proxy lesend auf den Wechselrichter samt SDongle zugreifen. Eigentlich greifen die Clients auf die vom Adapter bereits gelesenen Registerdaten (read-cache) zu. Dieses geht deutlich schneller und robuster als der direkte Zugriff über den SDongle zum Wechselrichter.
So könnt ihr ganz konkret zum Beispiel eure Wallbox von Huawei (SCharger) über den Proxy gleichzeitig mit dem Adapter und weiteren third-party Geräten wie Energy Manager (smartfox usw.) an den Wechselrichter anbinden. Für den SCharger muss dann als virtueller Zähler die ip-Adresse der ioBroker Instance angegeben werden auf dem der sun2000 Adapter mit aktivierten modbus-proxy läuft.

Im Konfigurationsfenster gibt es einen neuen Reiter „MODBUS PROXY“. Dort muss der Proxy aktiviert werden. Die voreingestellte ip „0.0.0.0“ bedeutet, dass der Proxy an allen Netzwerk-Interfaces lauscht.

Über Tests und euer Feedback freue mich sehr.

[TrackerTheCode]

@bolliy richtig stark! Werde ich gleich erstmal testen. Habe gestern den SCharger installiert ;-)

[meloneA]

@bolliy arbeitet der Proxy auch als "Cache" für einzelne Register oder werden alle Anfragen 1:1 an den Dongle weitergeleitet?

[bolliy]

@melonea zur Zeit ein reiner read cache. Sonst wäre der proxy nicht so fix. ;)

[besimo]

@bolliy
Ich muss kurz ausholen. Leider ist der Luna2000 sehr ineffizient
(sinkende-ertragswerte-bei-huawei-wr-nach-sonnenuntergang , evtl. entspricht das Huawei-System dem System K1 (zumindest die Lade-/Entladeleistung und Speicherkapazität stimmen überein) in der HTW-Stromspeicher-Inspektion-2024 .
Ich habe nachts bei geringem Hausverbrauch ca. 150 bis 250W ca. 110 bis 130 W Eigenverbrauch der 10kWh-Batterie (über den sinkenden Tages-PV-Ertrag berechnet).
Diese hohen Effizienzverluste sind gerade in den Wintermonaten prozentual sehr groß und hier geht es um einen zu großen, teuren Netzbezug (gegenüber zu geringerer Netzeinspeisung im Sommer).
Deswegen möchte ich sie durch eine bessere automatisierte Steuerung mit dem ioBroker/javascript/Adapter sun2000 optimieren. Dazu fallen mir theoretisch drei Möglichkeiten ein:

1. Steuerung des min SOC
   abends um ca. 22:00 Uhr den SOC z.B. auf 20% setzen, so dass bei geringem Hausverbrauch nicht mehr entladen wird und das System in den Ruhemodus geht.
   Morgens um ca. 06:30, wenn wir aufstehen, min SOC auf 5% runter, so dass die Batterie bei etwas höherem Hausverbrauch effizienter entlädt, als das nachts der Fall wäre.
2. Steuerung über Arbeitsmodus (Adresse 47086)
   Tagsüber: Max Eigenverbrauch (also Laden- und Entladen) bzw. zu Zeiten mit hohem Hausverbrauch Max. Eigenverbrauch und in den Abwesenheitszeiten (morgens), wo die Wärmepumpe aus ist, TOU-Modus (Zeitperioden Adresse 47083 ?) nur Laden
   Abends nach Sonnenuntergang und morgens beim Frühstück bis vor Sonnenaufgang: TOU-Modus Entladen
   Nachts: TOU-Modus ohne Zeitintervall (ich hoffe die Anlage geht dann auch in den Ruhemodus ?)
3. Steuerung über maximale Lade-/Entladeleistung
   Hat schon Mal jemand ausprobiert, ob der Wechselrichtung z.B. bei SOC 50 % und Entladeleistung = 0 nachts in den Ruhemodus geht ?

Es wäre also schön, wenn man neben dem min SOC auch noch den Arbeitsmodus (Adresse 47086) (max. Eigenverbrauch oder TOU) und für den Modus TOU die Zeitperioden mit Festlegung von Zeiten von-bis und Laden/Entladen (Adresse 47083 ?) lesen und schreiben könnte. Dann wäre man wirklich flexibel.

VG
Besimo

[bolliy]

@besimo Sofern der modbus-proxy ausreichend getestet wurde, würde ich gern mit der Implementierung von Services beginnen.
Die Services werden dann sehr abstrahiert von den eigentlichen Registerwerten funktionieren. Da ich das Lesen und Schreiben serialisieren muss, wird das etwas Aufwand bedeuten. Der Prozess muss dann asynchron die Aufträge im Intervall des Lesevorgangs abarbeiten.
Kannst du bitte deine Anforderungen als issue hier https://github.com/bolliy/ioBroker.sun2000/issues eintragen. So kann ich nichts vergessen;)