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.

[DS_Starter]

Im Contrib liegt eine Version Test. Umgesetzt ist der Parameter barrierSoC in ctrlBatSocManagementXX:

barrierSoC    
        Optionaler Parameter zur Änderung des berechneten Limits der Ladeleistung im Bereich lowSoC <= SoC < barrierSoC.
   Das Limit kann einen festen Wert, Zu/Abschläge oder prozentuale Änderungen erhalten.
   Alle Manipulationen erfolgen nur im SoC-Bereich lowSoC <= SoC < barrierSoC.
   Die Syntax des Parameters wird gemäß des folgenden Schemas angegeben:
   barrierSoC=XX:<Aktion>:<Wert> oder
   barrierSoC=XX:<Aktion>:<Reading>:<default>
   Die Angaben bedeuten im Einzelnen:
   XX - der Wert von barrierSoC in %. Es gilt lowSoC < barrierSoC < maxSoC
   Aktion - die Angabe legt eine der möglichen Manipulationen fest:
            max - das Limit wird auf setupBatteryDevXX->pinmax festgelegt
           set - das Limit wird auf einen festen Wert oder Readingswert gesetzt
           inc - das Limit wird um einen festen Wert oder Readingswert erhöht
           dec - das Limit wird um einen festen Wert oder Readingswert verringert
           prc - das Limit wird um einen prozentualen Wert / Readingswert geändert

   Wert - der Wert (in W bzw. %) mit dem die Aktion ausgeführt wird
   Reading - Reading im SF-Device welches den Wert für die Aktion enthält
   default - der default-Wert bei Angabe eines Readings
   
        Beispiele für einen barrierSoC von 40 %:
   barrierSoC=40:max -> Limit wird auf setupBatteryDevXX->pinmax gesetzt
   barrierSoC=40:set:<Reading>:<default> -> Limit auf <Reading> setzen
   barrierSoC=40:set:1350 -> Limit wird auf 1350 W gesetzt
   barrierSoC=40:inc:<Reading>:<default> -> Limit um den Wert <Reading> erhöhen
   barrierSoC=40:inc:200 -> Limit wird um 200 W erhöht
   barrierSoC=40:dec:<Reading>:<default> -> Limit um den Wert <Reading> verringern
   barrierSoC=40:dec:100 -> Limit wird um 100 W verringert
   barrierSoC=40:prc:<Reading>:<default> -> Limit um <Reading> Prozent ändern (+ erhöhen, - verringern)
   barrierSoC=40:prc:50 -> Limit um 50% ändern (+ erhöhen, - verringern)