[Frage] [V4.1] Speichern eines Einzelwertes in einer Logik

[avater]

Hallo zusammen,

ich hoffe, das passt hier rein - aber vielleicht bin ich (gedanklich) auch völlig falsch.

Ziel:

Ich möchte meiner Wallbox (Hardy Barth CPµ2) beibringen, nur eine vorgegebene Energiemenge zu laden und dann abzuschalten. Das beherrschen weder die WB, noch das E-Auto (ZOE aus 2016). Ich kann aber Gesamt-kWh-Stand der WB per HTTP-Req abrufen.

Meine Idee ist nun also, auf Knopfdruck (z.B. KNX-Taster) eine bestimmte kWh-Menge als "noch zu laden" festzulegen.

• Knopfdruck: Zielenergie Z, z.B. 10 kWh
• Gesamtenergie per HTTP abrufen und den Wert X speichern
• In einem Intervall erneut Gesamtenergie E abrufen und wenn (E - X >= Z), dann Ladevorgang beenden (per REST API)

Wie kann ich nun also den Wert X speichern, sodass er nicht durch die nachfolgenden zyklischen Abrufe von E überschreiben wird?

Wie starte und beende ich das zyklische Abrufen von E, sodass ich das nur machen muss, wenn auch wirklich diese Zielladefunktion aktiv ist?

Ich bin beim Hantieren von Logiken noch ein ziemlicher Noob.

... oder gibt es eine viel einfachere Umsetzungsidee mit dem TWS?

Viele Grüße
Arne

[gbglace]

Nimm Dir ein paar fertige Custom-Logiken und schaue Da nach Latch Modulen. Damit kannst Dir über Ausführungszyklen hinweg Werte merken.

[moritzw]

Hallo Arne,

Ich stand letzte Woche vor einem ähnlichem „wenn-dann“-Problem https://forum.timberwolf.io/viewtopic.php?t=5513.
Die für mich einfachste Lösung war die Freie-Formel-Logik. https://elabnet.atlassian.net/wiki/spa ... ulbaustein

Mit der kann man nämlich Wenn-Dann-Funktionen mit Rechengrößen realisieren.
Einfach E,X und Z als Eingänge setzen und dann die Formel (X1-X2>=X3)?1:0 einsetzen. Wenn x1-x2 größer oder gleich x3 ist,dann wird eine eins an den Ausgang gesendet!sonst eine null.

Mit den U,C,A flags an den Ein- und Ausgängen kannst Du das Verhalten der Berechnung noch anpassen.

Viele Grüße
Mo

[Robert_Mini]

Hallo Arne!

Das ist ein Klassiker, der nach einer Custom-Logik schreit. Natürlich kann man das auch aus einzelnen Bausteinen zusammenbauen, ist aber nicht ganz trivial.

Gerne unterstütze ich dabei, weil es ein schöner Baustein ist, den vielleicht mehr Leute brauchen.

Ich würde mal hier die Anforderungen noch genauer ausdiskutieren und dann daraus ein Tutorial machen.

Laut gedacht:
1) Gesamtenergie E wird zyklisch von einer Triggerlogik angefordert und der http requests sendet den Wert an die Logik (Eingang auf „u“, d.h. nur mithören)
2) Du setzt Z von der Visu aus, der Wert wird persistent gespeichert (d.h. Auch über einen Reboot hinweg)
3) Per Taste triggerst du das Nachladen, der Wert X (=E zum Zeitpunkt des Nachladestarts) wird nun gespeichert und der Ausgang „Laden“ wird auf True gesetzt.
4) Ab dann wird alle 60s die Logik getriggert und die Differenz E-X ausgewertet
5) Wenn E-X > Z wird der Ausgang „Laden“ auf False gesetzt

Soweit so klar, du siehst das solch vermeintlich einfache Logik immer schon ganz schön viel Einzel-Logik beinhaltet.

6) Ich würde noch Eingang „Status Laden“ berücksichtigen. Damit könnte man dann noch einen eigenen Ausgang „Status“ umsetzen, der folgendes ausgibt:
0=Nachladen aus
1=Nachladen aktiv
2=Nachladen beendet
3=Nachladen vorzeitig beendet

Dazu müsste man aber noch ein Timeout ergänzen, aber der dann der Status 2/3 wieder auf 0 wechselt.

Was meinst du zu diesen Überlegungen?

Lg
Robert

[avater]

Danke euch für die Ideen und Buzzwords. Damit habe ich Lesestoff!

Was meinst du zu diesen Überlegungen?

Hallo Robert,

deine Überlegungen decken meine Anforderungen ab (soweit sie mir heute bewusst sind ). Einzig bei Punkt 1 die Rückfrage, ob das zyklische Anfordern von E nur passieren soll, während der Ladevorgang aktiv ist oder immer? Immer wäre halt unnötig - aber vermutlich meintest du das so auch nicht.

Für das Setzen der Größe Z hatte ich noch die Idee (neben dem offensichtlichen Weg über die Visu) sowas zu machen, wie ich es von der Treppenlichtfunktion der MDT-KNX-Aktoren kenne, nämlich bei jedem Tastendruck (also boolschem Eingang) den Zielwert um einen festen Wert zu erhöhen (z.B. 5 kWh). Dann kann man sowohl zu Beginn (Taster in Wallbox-Nähe) gleich mehrfach drücken, oder während es noch lädt, zusätzliche 5 kWh draufpacken. Wobei diese Funktionalität vermutlich nicht mit in die "Hauptlogik" müsste.

Mein Use-Case ist tatsächlich, eine selbst-geschätzte Menge zu laden, mit der das Auto dann auf so ca. 70-80 % SOC kommt (wie gesagt, das Auto ist zu dumm dafür ). D.h., dass die Energiemenge jedes mal anders sein kann und eine Ein-Knopf-Bedienung einfacher sein kann, als über die Visu zu gehen.

Soweit so klar, du siehst das solch vermeintlich einfache Logik immer schon ganz schön viel Einzel-Logik beinhaltet.

Oh ja. Ich bin eher in der objektorientierten Programmierung (vorzugsweise der Einfachheit halber in nicht-typisierten Skriptsprachen) zuhause!

(Die Erkenntnis, eine Zeitschaltuhr im TWS mit einem OR-Baustein zu implementieren war ... unerwartet!)

Status ist auch eine gute Idee! Noch weiter gedacht:

• Fortschritt in % und/oder kWh
• geschätzte Restdauer (eher eine Spielerei)
• Ob Status 2 und 3 überhaupt nötig sind? Vorzeitige Beendigung kann doch eigentlich nur durch aktiven Eingriff passieren, oder? Und dann weiß man es ja eh. Und "beendet" vs. "aus"? Was macht man mit der Info?

Noch eine Idee: PV-Überschussladen ja/nein

Ich kann per HTTP zwischen den beiden Modi der WB umschalten. Der Unterschied in der Nutzung ist im Wesentlichen: Muss das schnell fertig werden, oder nicht? Wobei diese Funktionalität eigentliche völlig unabhängig von der Logik hier ist, bzw. einfach vorgeschaltet werden kann (und nachgeschaltet: Wenn fertig, dann zurück auf Überschussladen).
(Zu speziell!)

Wir könnte noch generische Anwendungsfälle sammeln/suchen, die vielleicht mitbedient werden könnten:

• Hausakku nachladen/einspeisen
• Gartenbewässerung für Z Minuten (oder Z Liter) starten
• Intensivlüften KWL (gut, können die vermutlich selber steuern)
• Treppenhauslicht!

(Hm, wenn ich die Liste selber so lese merke ich: Die Krux für mich ist, dass meine WB die Energiemenge des aktuellen Ladevorgangs nicht ausspuckt. Nur deswegen bin ich ja bei der Frage nach "Wert speichern" gelandet.)


Viele Grüße
Arne

[Robert_Mini]

Deine Beispiele zeigen, dass vieles per Zeitsteuerung passiert (zB. Bewässerung), weil Durchfluss/Zeit/Menge austauschbar sind.

In deinem Fall frage ich mich (in Kombination mit dem Hinweis auf schritteweise die Menge einstellen), ob du nicht eigentlich eine Logik möchtest, die fix auf 90% lädt. Man könnte das auch so implementieren, dass je nach Start-Trigger die Menge Z oder eben auf xx% geladen wird.

Status 2/3: Was passiert, wenn gar kein Auto angesteckt ist oder das Auto während dem Nachladen abgesteckt wird?
Fortschritt in kWh ist natürlich eine gute Idee!

lg
Robert

[avater]

... ob du nicht eigentlich eine Logik möchtest, die fix auf 90% lädt.

Ja, tatsächlich will ich das "Zielladen auf XX%" damit nachbilden. Nur bekomme ich aus meinem Auto leider keinen SOC ausgelesen (also ich bekomme grundsätzlich gar keine Daten vom Auto und dieses Zielladen lässt sich auch im Auto selber nicht einstellen). Das ist überhaupt die Ursache meiner Überlegungen.

Ich stelle das Auto ab, überlege, wie viel Energie nachgeladen werden muss. Entweder nur soviel, dass es für die nächste geplante Fahrt reicht, oder aber auch auf ca. 80% (Akku schonen). Letzteres in der Regel nur dann, wenn auch die Sonne scheint. Oder 100%, falls wirklich voller Akku nötig ist.

Das Abschätzen anhand der Restreichweite, wie viel Energie nötig ist, ergibt sich aus der Erfahrung, es braucht rund 5 kWh für 30 km.

Für modernere Autos hast du natürlich recht - nur das die das dann normalerweise sowieso (via App) beherrschen und der TWS sich nicht einmischen muss. Oder vielleicht nur, um die App nicht nutzen zu müssen, aber da kann man dann sicherlich direkt die API des Autos ansteuern - sofern das überhaupt geht (Sicherhheitsrisiken fürs Auto).

Status 2/3: Was passiert, wenn gar kein Auto angesteckt ist oder das Auto während dem Nachladen abgesteckt wird?
Fortschritt in kWh ist natürlich eine gute Idee!

Wenn kein Auto angesteckt (aus Sicht der Logik):
Entweder passiert gar nix: Laden nicht möglich, also Zielladen auch nicht.
Oder aber, das Zielladen wird geplant und automatisch begonnen, wenn das nächste Auto angesteckt wird. Da man aber bis dahin die Einstellung ggf. vergessen hat, oder aber auch ein anderes Auto ansteckt (ich persönlich hab aber nur eins), wäre ich eher für: nix passiert.

Wenn vorher abgesteckt, ist der Ladevorgang physikalisch beendet. Und man wird wohl das Auto bewegen, die vorherigen Zielladeparameter sind also beim Wiederanstecken veraltet. Daher würde ich da einfach zurück auf Status 0 gehen. Wer aus Spaß ab- und gleich wieder anstöpselt, ist selbst schuld.

Viele Grüße
Arne

[Robert_Mini]

Deine Überlegungen sind absolut richtig und bestätigen mir, dass die Rückmeldung ob tatsächlich geladen wird berücksichtigt werden muss.

Das ist immer der Irrglaube bei Logiken: man denkt sich, Aktion x löst y aus, dann das und so weiter.
In Wahrheit muss man aber fast immer die Rückmeldungen berücksichtigen, die zeitverzögert kommen, was das ganze deutlich verkompliziert.

In deinem Fall würde die Logik endlos laufen, wenn keine Auto angeschlossen ist, weil E-X sich nicht ändert…

Lg Robert

[avater]

Ich dachte an die notwendige Bedingung, dass ein Auto da ist. Also Logik läuft, solange Auto angeschlossen UND E-X < Z.

Damit läuft sie aber auch, wenn das Auto voll ist, noch bevor Z geladen wurde. Wäre das aus Logik-Sicht problematisch?

Gruß
Arne

[Robert_Mini]

Ok. Heißt zusätzlicher Eingang „Auto angeschlossen“.
Der 2. Fall ist kein Problem, aber unschön. Man könnte dafür vorsehen, dass der Ladevorgang beendet wird, wenn E-E_last < dE_min ist.

Hat die Wallbox gar keine Rückmeldung am TWS verfügbar, ob geladen wird (Status)?

Lg
Robert