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

[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;)

[hans_999]

@besimo said in Test Adapter sun2000 v0.1.x - Huawei Wechselrichter:

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).

Das kann ich nach kurzer Erfahrung mit diesem Speicher nur bestätigen.
Mir fiel nachts der hohe Eigenverbrauch (ca. 100W bis 400W in Peaks) auf. Prüfungen der üblichen Verdächtigen im Haus gaben keine Hinweise.
Dann habe ich bemerkt, dass dieser hohe Verbrauch gegen 0 geht, wenn der Speicher auf dem eingestellten Minimum (momentan 10%) ist und sich die Batterie abschaltet.
Bei momentan ca. 14 h ohne PV-Ertrag kommen da ca. 1,4kWh zusammen (bzw. gehen verloren).

Das ist schon ganz schön frustrierend.

Insofern wäre eine dynamische Steuerung des min. SOC echt eine gute Idee.

@besimo Danke auch für den Link zum Vergleich.

[besimo]

@hans_999 said in Test Adapter sun2000 v0.1.x - Huawei Wechselrichter:

Das kann ich nach kurzer Erfahrung mit diesem Speicher nur bestätigen.
Mir fiel nachts der hohe Eigenverbrauch (ca. 100W bis 400W in Peaks) auf. Prüfungen der üblichen Verdächtigen im Haus gaben keine Hinweise.
Dann habe ich bemerkt, dass dieser hohe Verbrauch gegen 0 geht, wenn der Speicher auf dem eingestellten Minimum (momentan 10%) ist und sich die Batterie abschaltet.
Bei momentan ca. 14 h ohne PV-Ertrag kommen da ca. 1,4kWh zusammen (bzw. gehen verloren).

Das ist schon ganz schön frustrierend.

So ist es mir auch ergangen. Am liebsten hätte ich die Anlage zurückgegeben / getauscht gegen einen anderen Hersteller, schließlich wurde geworben mit einem hocheffizienten WR. Ohne Batterie mag das stimmen, aber mit Batterie ist er nicht mehr so hocheffizient.
Und ich wollte eigentlich die maximal mögliche Autarkie erreichen und hatte gedacht, dass das System auch hocheffizient ist, wie beworben. Stellt man nun die Batterie auf min SOC 5 % wie von Huawei empfohlen, hat man dann statt den versprochenen 10 kWh nur 8 kWh Nettokapazität, wenn man eben den Eigenverbrauch beim Entladen dazurechnet. Man könnte es sicher auf einen Rechtsstreit anlegen, wenn man will.
Das Positive ist, dass man hier im Winter durch Steuerung über iobroker/sun2000-Adapter ein deutlich größeres Einsparpotential hat, als bei anderen Systemen, die vom Werk aus hocheffizient sind.

Insofern wäre eine dynamische Steuerung des min. SOC echt eine gute Idee.

Im ersten Schritt die einfachste Lösung. Leider ist der min SOC auf maximal 20% begrenzt. Im tiefen Winter, wenn Mal ein einziger Sonnentag ist (gemäß PV-Prognose), würde ich aber gerne das nächtliche Entladen komplett sperren und das Entladen erst ab einer gewissen Mindestlast am Tag zulassen (z.B. während WW-Bereitung mit Wärmepumpe, während den Heizzeiten mit der Wärmepumpe und abends wenn das Haus beleuchtet ist), so dass der Speicher die komplette Nacht im energiesparenden Ruhemodus ist.
Bei 150W Ausgangsleistung liegt der Umwandlungswirkungsgrad eines weniger effizienten System bei z.B. ca. 65% , bei 500 W schon bei ca. 87% und bei 800 W über 90%.

In nachfolgendem Bild 39 aus dem Speichertest 2024 der HTW Berlin sieht man, dass die Umwandlungsverluste bei System K1 den größten Anteil ausmachen. Aber auch die Bereitschaftsverluste kosten bei System K1 ca. 2,9% der Systemeffizienz. Wenn man jetzt also die Entladezeiten verkürzen würde, müssten m.E. auch die Bereitschaftsverluste reduziert werden. Man würde also mit den oben genannten Optimierungsmaßnahmen sowohl die Umwandlungsverluste, als auch die Bereitschaftsverluste reduzieren.
Im Sommer (und in großen Teilen der Übergangszeit bei mir) sind die PV-Erträge so groß, dass der Speicher die ganze Nacht ausreicht. Da kann man dann nichts optimieren, zumindest nicht, wenn man nicht die einzelnen Akkupacks (in meinem Fall 10kWh-Speicher Akkupack1 und Akkupack 2) separat steuern könnte, so dass nachts immer nur ein Akku entlädt. Damit könnte Huawei die Batterieeffizienz deutlich verbessern, aber dies liegt dann an Huawei, ein solches Firmware-Update zu entwickeln.

[hans_999]

@besimo
Die niedrige Effizienz wird auch in https://www.photovoltaikforum.com/thread/150772-eigenverbrauch-wechselrichter-huawei-sun2000-33ktl-a/?pageNo=1 im PV-Forum diskutiert

Jetzt sollten wir aber wieder zurück zum Thema des Trööts kommen.