AC Charger über SMART PLUG via HTTP get einschalten

[Snoopy-HSS]

Steuert ein X beliebiges Ladegerät über einen Shelly Plug ein, wenn die Schwellenwerte erreicht sind.

[schlimmchen]

Hm, das sieht interessant aus. Danke! Schön, das du den HttpGetter verwendet hast, damit hast du mich positiv überrascht. Ich sehe auch, dass du dieses Feature in den AC Charger in der Web UI unterbringst, was ich sonst verlangt hätte.

Allerdings hab ich natürlich, ganz meiner Art entsprechend, auch zu meckern:

• Coding Style, Einrückungen.
• Richtig wäre ja, wenn man auswählen kann: Huawei AC charger oder Shelly, korrekt? Oder ist das komplementär? Wenn es exklusiv sein sollte, dann müsste man eigentlich erstmal eine AC charger Abstraktion einführen, wie bei der Batterie auch, wo man dann auswählen kann, mit welchem "Provider" man hantieren will (Huawei AC charger oder "Shelly").
• Mir gefällt die Konkretisierung nicht. Was du eigentlich anbietest, ist ein Interface, um ein Ladegerät per HTTP zu steuern. Ob das ein Shelly ist, oder wie ich mir das wünschen würde, ein mit Tasmota ausgestatteter Shelly oder ein No-Name-Board mit Tasmota, oder was ganz anders, soll erstmal dahingestellt sein. Aber das können wir auch nachziehen, das muss nicht sofort sein. Aber verstehst du, was ich meine?

[Snoopy-HSS]

Code Style schaue ich mir an, dachte dass passt schon. Nehme hier gerne Tips an.

Es war Absicht beide Charger parallel zuzulassen. So kann man das Huawei Überschuss orientiert und on TOP noch via Shelly ein statisches Netzteil als Booster und um auch mehrere Phasen zu belasten. Bei meiner 25kwp Anlage aufm Dach komme ich regelmäßig über die 2500W vom Huawei. Werde auch evtl. das Huawai mit 75A testen... Wobei ich einphasig >16A eigentlich nicht so mag...

Das ganze dann noch Erweitern, dass man die URIs zum senden und JSON Werte zum auslesen spezifizieren kann, liefere ich gerne in einem späteren Update...

[spcqike]

Ich fände eine mehrstufige Regelung auch super interessant.

So könnte man ggf. auch einfache kleinere Verbraucher kaskadiert starten und stoppen. ZB heizstäbe, Pumpen, Wärmepumpen,….

[Snoopy-HSS]

Hm, das sieht interessant aus. Danke! Schön, das du den HttpGetter verwendet hast, damit hast du mich positiv überrascht. Ich sehe auch, dass du dieses Feature in den AC Charger in der Web UI unterbringst, was ich sonst verlangt hätte.
Allerdings hab ich natürlich, ganz meiner Art entsprechend, auch zu meckern:

• Coding Style, Einrückungen.
• Richtig wäre ja, wenn man auswählen kann: Huawei AC charger oder Shelly, korrekt? Oder ist das komplementär? Wenn es exklusiv sein sollte, dann müsste man eigentlich erstmal eine AC charger Abstraktion einführen, wie bei der Batterie auch, wo man dann auswählen kann, mit welchem "Provider" man hantieren will (Huawei AC charger oder "Shelly").
• Mir gefällt die Konkretisierung nicht. Was du eigentlich anbietest, ist ein Interface, um ein Ladegerät per HTTP zu steuern. Ob das ein Shelly ist, oder wie ich mir das wünschen würde, ein mit Tasmota ausgestatteter Shelly oder ein No-Name-Board mit Tasmota, oder was ganz anders, soll erstmal dahingestellt sein. Aber das können wir auch nachziehen, das muss nicht sofort sein. Aber verstehst du, was ich meine?

kannst du mir einen Tipp geben, wie ich deine AC-Charger Admin Änderungen in meinen Fork gemerged bekomme. wir haben nun jetzt ja beide die gleichen Files geändert....

Ok habs gefunden...

Bitte um review

[stefan123t]

Danke @Snoopy-HSS für Deinen PR!

Das Review sollte @schlimmchen / hoylabs machen. Vielleicht abstrahiert er den PR auch so, wie er sich das vorstellt und es mit dem Dynamic Power Limit zusammen passt ?

Richtig wäre ja, wenn man auswählen kann: Huawei AC charger oder Shelly, korrekt? Oder ist das komplementär? Wenn es exklusiv sein sollte, dann müsste man eigentlich erstmal eine AC charger Abstraktion einführen, wie bei der Batterie auch, wo man dann auswählen kann, mit welchem "Provider" man hantieren will (Huawei AC charger oder "Shelly").

Die Idee einer AC Charger Abstraktion macht aus meiner Sicht auf jeden Fall Sinn. Schon alleine weil man ja mehrere dieser Geräte auf der gleichen / unterschiedlichen Phasen haben kann. Siehe die Beispiele von @spcqike

Ich fände eine mehrstufige Regelung auch super interessant.
So könnte man ggf. auch einfache kleinere Verbraucher kaskadiert starten und stoppen. ZB heizstäbe, Pumpen, Wärmepumpen,….

Dafür bräuchte man dann eine Prio-Liste pro Phase. Evtl noch einen Zeitplan für die Wochentage und/oder eine (temperatur-abhängige) Sommer-/Winterumschaltung.

Oder eine vorwählbare Dauer zB von 3 Stunden für die Waschmaschine / den Trockner ?

Dann sind wir aber schon bei OpenDTU-OnWärmePumpe oder OpenDTU-OnXYZ

Mir gefällt die Konkretisierung nicht. Was du eigentlich anbietest, ist ein Interface, um ein Ladegerät per HTTP zu steuern. Ob das ein Shelly ist, oder wie ich mir das wünschen würde, ein mit Tasmota ausgestatteter Shelly oder ein No-Name-Board mit Tasmota, oder was ganz anders, soll erstmal dahingestellt sein. Aber das können wir auch nachziehen, das muss nicht sofort sein. Aber verstehst du, was ich meine?

Das ganze dann noch Erweitern, dass man die URIs zum senden und JSON Werte zum auslesen spezifizieren kann, liefere ich gerne in einem späteren Update...

Das wäre auch mein einziger Kritikpunkt gewesen, aktuell wird nur ein ausgesprochen flexibler Shelly Plug S unterstützt.
Viele andere Shelly’s haben auch einen Schalt-/Relaisausgang: Shelly Plus 1 PM, Shelly Pro 3EM, etc. bei denen sich die URLs jeweils unterscheiden.

Aber vor allem wie sieht es mit OpenSource/Hardware wie Tasmota/Sonoff Geräten bzw closed Source Tuya aus ?

[spcqike]

closed Source Tuya

kann man, und würde ich immer, per localtuya local mit MQTT ansprechen.
Kann man Tuyageräte per HTTP requests steuern?

[Snoopy-HSS]

Unterstützung aller per http Request Steuerbaren devices reiche ich nach...

OPENdtu-Hausautomation wird es sicherlich nicht werden...

[stefan123t]

<offtopic>

closed Source Tuya

kann man, und würde ich immer, per localtuya local mit MQTT ansprechen. Kann man Tuyageräte per HTTP requests steuern?

Ich hatte irgendwann mal das Tasmota Unterprojekt Tuya-Convert gesehen aber noch nicht ausprobiert.
https://tasmota.github.io/docs/Tuya-Convert/

Und es sollte m.W. auch ein SDK für die Tuya Chips / MCUs von Beken BK7231T MCU geben.
Nur das Flashen ist immer ein bisschen aufwendig, weil man die Steckergeräte eben aufbekommen muß.
Siehe https://github.com/FlorianSoler/OpenBeken-Action-lsc-smartplug-with-monitoring-guide
</offtopic>

[wusel42]

Moin,

wie geht's denn hier weiter? Ich habe ein 60V20A-Netzteil an einem MPPT 100|20, über den ich ggf. die Batterie aus dem Netz nachlade (Netzteil hängt an Shelly Plus 1PM), würde den Part also gerne "internalisieren" in OpenDTU-on-Battery und automatisieren.

(Ja, das impliziert weitere Wandlungsverluste (AC-DC-MPPT-DC), erscheint mir aber als Sorgloslösung, ich gehe so mit einer Spannung auf den Akku (Victron SmartNetwork) und nicht ggf. mit untrschiedlichen. Oder wäre ein R4850G2 viel vorteilhafter?)

[AndreasBoehm]

Für mich ist der erste Schritt eine Abstraktion des AC Ladegrätes zu schaffen, dann kann man zwischen Huawei und Shelly auswählen. Im zweiten Schritt sollte man dann 2, 3, 4, viele AC Ladegeräte gleichzeitig konfigurieren können.

An der Abstraktion bin ich aktuell dran.

[Snoopy-HSS]

Hi,

ist es wirklich notwendig/sinnvoll ein entweder oder zu machen.
Ich finde es charmant den Hauptteil über das Huawei zu machen aber über den Shelly Stecker bei absoluten Überschuss vom Dach noch was dazu zu "boosten"...

[github-actions]

Build Artifacts

Firmware built from this pull request's code:

• opendtu-onbattery-generic_esp32_4mb_no_ota.zip
• opendtu-onbattery-generic_esp32s3.zip
• opendtu-onbattery-generic_esp32_8mb.zip
• opendtu-onbattery-generic_esp32s3_usb.zip

Notice

• These artifacts are ZIP files containing the factory update binary as well as the OTA update binary.
  Extract the binaries from the ZIP files first. Do not use the ZIP files themselves to perform an update.
• These links point to artifacts of the latest successful build run.
• The linked artifacts were built from 331ccaf.

[AndreasBoehm]

Ich denke du hast mich falsch verstanden.

Schritt 1: Abstraktion für AC Ladegeräte schaffen und diese für Huawei, Truck T2HG/T2MG, Shelly implementieren
Schritt 2: "Beliebig" viele AC Ladegeräte, verschiedener Typen gemeinsam nutzbar machen

Schritt 2 ist ohne die vorheriger Abstraktion ziemlich unschön und auch wenig flexibel.

[Snoopy-HSS]

ja dann, Super.
Hatte den Satz "dann kann man zwischen Huawei und Shelly auswählen." anders interpretiert.
Wenn ich was beisteuern kann, sag bescheid.

[Snoopy-HSS]

Wie sind die Pläne, dies hier zu integrieren.
Bin mit den letzen commits von Bernhard angehängt.
Hier die Konflikte zu lösen ust "to much"

[AndreasBoehm]

Ich bin aktuell noch mit Schritt 1 beschäftigt.

Warte lieber bis das durch ist, erst dann macht es Sinn das du deinen PR dann wieder anpasst.

[Snoopy-HSS]

OK ...

[Snoopy-HSS]

siehe #2125

[Snoopy-HSS]

Ich bin aktuell noch mit Schritt 1 beschäftigt.

Warte lieber bis das durch ist, erst dann macht es Sinn das du deinen PR dann wieder anpasst.

@AndreasBoehm

Wie kommt du hier voran?
Hast du zufällig schon einen zeitlichen Rahmen?
Gegen Winter brauche ich die Funktion und hänge noch auf einer alten Release mit diesen Änderungen hier fest. Würde es dann auf die neuen Funktionen mit Controller etc. anpassen.

[AndreasBoehm]

Schleppend, ich habs noch nicht geschafft den Huawei code komplett aus der generischen implementierung zu entfernen.

ich denke du kannst meinen branch aber trotzdem als basis für einen shelly provider nutzen: #2182

[AndreasBoehm]

Aber nicht vergessen: Bisher ist die Auswahl des Providers exklusiv, es gibt bisher keinen support mehrere Ladegeräte gleichzeitig zu nutzen.

[Snoopy-HSS]

Schleppend, ich habs noch nicht geschafft den Huawei code komplett aus der generischen implementierung zu entfernen.

ich denke du kannst meinen branch aber trotzdem als basis für einen shelly provider nutzen: #2182

@AndreasBoehm

wie bekomme ich deinen Branch in meinen Fork?

[AndreasBoehm]

So sollte das klappen

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork#syncing-a-fork-branch-from-the-command-line

[Snoopy-HSS]

Wird mit #2347 weiter behandelt

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion or issue for related concerns.