76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Ok. Dann aber so:

Code Auswählen Erweitern

barrierSoC=40:max                  -> Wert auf pinmax setzen
barrierSoC=40:set:ReadingA:<def>   -> Wert auf SF Reading "ReadingA" setzen (mit default)
barrierSoC=40:set:1350             -> Wert auf 1350 W setzen
barrierSoC=40:inc:ReadingB:<def>   -> Wert um den Wert in Reading "ReadingB" erhöhen (mit default)
barrierSoC=40:inc:200              -> Wert um 200 W erhöhen
barrierSoC=40:dec:ReadingC:<def>   -> Wert um den Wert in Reading "ReadingC" erniedrigen (mit default)
barrierSoC=40:dec:100              -> Wert um 100 W erniedrigen
barrierSoC=40:prc:ReadingD:<def>   -> Wert um Prozentwert in Reading "ReadingD" ändern (+ erhöhen, - erniedrigen)
barrierSoC=40:prc:50               -> Wert um 50% ändern (+ erhöhen, - erniedrigen)

Das ist verständlich und auch stringent zu parsen.

[Parallix]

Code Auswählen Erweitern

[quote author=DS_Starter link=msg=1351148 date=1762333109]
Ok. Dann aber so:
...
[/quote]

Geht natürlich auch. Wenn der Rückfallwert vor dem Reading steht, vereinfacht sich aus meiner Sicht aber das Parsen.

[DS_Starter]

Wenn der Rückfallwert vor dem Reading steht, vereinfacht sich aus meiner Sicht aber das Parsen.

Könnte man denken...da aber <def> ein optionaler Syntax-Wert ist der nur bei Readings relevant ist, vereinfacht diese Form das Parsen und ist nebenbei für den Anwender einfacher. Z.B. entfällt der Platzhalter :: und der Default kommt nach dem Reading was auch verständlich ist. Und wenn dort kein def angegeben ist, wäre das auch kein Problem.

[Parallix]

Wenn der Rückfallwert vor dem Reading steht, vereinfacht sich aus meiner Sicht aber das Parsen.

Könnte man denken...da aber <def> ein optionaler Syntax-Wert ist der nur bei Readings relevant ist, vereinfacht diese Form das Parsen und ist nebenbei für den Anwender einfacher. Z.B. entfällt der Platzhalter :: und der Default kommt nach dem Reading was auch verständlich ist. Und wenn dort kein def angegeben ist, wäre das auch kein Problem.

Verstehe! Bin gedanklich von einer anderen Seite gekommen: Ohne angegebenes Reading stellt die ansonsten als Rückfallwert dienende Zahl den via set, inc, oder dec zu setzendenden Wert dar. Wird noch ein Reading angefügt, so ist dies ein SF internes Reading. Kommt irgendwer auf die Idee, auch SF-externe Readings mal zuzulassen, dann folgendem Wert zwei mit einem Doppelpunkt getrennten Angaben.

Bsp.:

Code Auswählen Erweitern

barrierSoC=40:inc:200                     -> Wert um 200 W erhöhen
barrierSoC=40:inc:200:<SFReading>         -> Wert um den im SF internen Reading angegebenen Wert erhöhen, falls dieser nicht vorliegt um 200 W
barrierSoC=40:inc:200:<Device>:<Reading>  -> Wert um den im (externen) Device-Reading angegebenen Wert erhöhen, falls dieser nicht vorliegt um 200 W


[DS_Starter]

Kommt irgendwer auf die Idee, auch SF-externe Readings mal zuzulassen ...

Das wäre dann ohnehin von mir zu implementieren, geht nicht einfach so.
Die erweiterte Syntax wäre dann:

Code Auswählen Erweitern

barrierSoC=40:set:ReadingA@<Dev>:<def>   -> Wert auf SF Reading "ReadingA" aus Device <Dev> setzen (mit default)

Aber das lassen wir erstmal, nicht gleich übertreiben. 

[grappa24]

Angepasste Version liegt im Contrib.

anbei meine Ladekurve (smartPower) mit dieser Version

[DS_Starter]

Kann man erstmal nicht meckern meinerseits.
Wichtig für eine gedankliche Einordnung ist immer der Erreichbarkeitsstatus des Ziels was man im Reading Battery_TargetAchievable_XX verfolgen kann.
Bei mir ist heute endlich wieder Überschuß angesagt. Dadurch erreiche ich lt. Ladungsprognose 100% gegen 16:00.
smartPower regelt auch schon herunter, d.h. die Kurve kommt in einen geregelten Bereich hinein.
Heute Abend kann man sich das Ergebnis mal anschauen.