Wie kann ich zwei SV (Typ Zeichenkette) addieren und in neue SV (Typ Zeichenkette) schreiben.

[Black]

korrekt.

wobei ich trotzdem zu korrekten Typisieren der Variablen rate, Editoren können am Scriptende einen Typwechsel erkennen und dies auch entsprechend am Scriptende ausgeben, so hat man Ansatz zu entscheiden, ja, der Typwechsel ist ok und gewollt, oder ähm, da stimmt was nicht

Black

[Baxxy]

Für mich gäbe es da im gezeigten Script nur einen "richtigen" Typ... object

[Xel66]

Weil es durch die dynamische Typendeklaration völlig egal ist, was du hinschreibst.

Ja, kenne ich. Aber ich sehe es pragmatisch. Wenn ich mit Werten rechnen will, deklariere ich sie im Vorfeld mit einem geeigneten Typ. Nenne mich altmodisch, aber ich erachte das als zielführend.

Ich halte es auch für wenig zielführend, solche Werte überhaupt als String (mit Einheit) in der CCU vorzuhalten. Damit schießt man sich schon für solche Tools wie Historian von vornherein ins Aus. Strings kann man nicht in Diagrammen anzeigen und auswerten. Die Werte kann man auch als Zahl definieren und in den Einstellungen eine Einheit zuweisen. Benötigt man unbedingt in einer Visu eine Maßeinheit, muss diese eben in der Bildschirmausgabe anhängen. Meiner unmaßgeblichen Meinung nach ergibt es nur so einen wirklich brauchbaren Sinn. Vor allem spart man sich irgendwelche nachträglichen Extraktionen von Werten für die Weiterverarbeitung. Das Problem beginnt also schon mit dem Auslesen der Werte und dem Schreiben in die CCU.

Gruß Xel66

[Matsch]

Ich bin auch sehr dafür, die Objekttypen klar zu benennen statt var. Eine solche Deklaration macht es später viel einfacher, die ehemalige Absicht nachvollziehen zu können. Auch wenn die Typkonvertierung trotzdem macht, was sie will.

Im übrigen braucht man manchmal halt Variablenfelder, die es nicht gibt. Die bilde ich auch auf Strings ab.

[MichaelN]

Ich halte es auch für wenig zielführend, solche Werte überhaupt als String (mit Einheit) in der CCU vorzuhalten.

Bester Tipp bisher.

[Roland M.]

Hallo!

Ja, kenne ich. Aber ich sehe es pragmatisch. Wenn ich mit Werten rechnen will, deklariere ich sie im Vorfeld mit einem geeigneten Typ. Nenne mich altmodisch, aber ich erachte das als zielführend.

Ja, ich widerspreche dir gar nicht. Ich wollte nur hinweisen, dass eine Deklaration als var auch nicht falsch ist.

Persönlich verwende ich meist das var, weil in Verbindung mit einer gleichzeitigen Zuweisung (var x = domGetObject(...)) der Typ ohnehin deutlich ersichtlich ist.
Auch ist mir die Typenkonvertierung noch von COBOL (mit dem ich mir meine ersten eigenen Brötchen verdiente ) in guter Erinnerung.
Mit einem VAR X PIC 999999 REDEFINE VAR Y PIC 'AAAAAA' (oder so ähnlich ) konnte man auch so manches Problem einfach und speichersparend lösen!

Ich halte es auch für wenig zielführend, solche Werte überhaupt als String (mit Einheit) in der CCU vorzuhalten. Damit schießt man sich schon für solche Tools wie Historian von vornherein ins Aus.

Da kann ich dir auch nur voll und ganz zustimmen!


Roland

[be.pe]

Hey,
euch allen Danke.
Das mit Float funktioniert einbahnfrei.

[Matsch]

Doch doch, das funktioniert damit nur in die eine Richtung.

[Henke]

Wie wäre es mit ++? Zumindest würde die Scriptdoku das raten. Und warum deklariert Du als var und nicht als real?

Inkrement bei einem CCU Script? Das ist mir neu und in der Doku finde ich nichts. Lerne gerne und bitte um genaueren Bezug.

Da hier viel über wie sollte ein CCU Script aussehen, auch mal meinen Senf dazu.
Gegeben, so schön klein aber doch der eine oder andere suboptimale Ansatz:

Code: Alles auswählen

!Skript zur Berechnung Gesamterzeugung Solar

var solar1 = dom.GetObject("StromVorTageserzeugung PV");
var solar2 = dom.GetObject("Stromerzeugung SoBa gestern");
var gsolar = dom.GetObject("Gesamtsolarerzeugung");
gsolar.State((solar1.State() + solar2.State()).Round(2));

Die erste Zeile "!Script ...." ist sehr gut. Bei einen Runtime Fehler kommt das im Log und man muss nicht lange suchen um welches Script es sich handelt.

"var solar1 = dom.GetObject("StromVorTageserzeugung PV");"
Nope.
1. Nicht als String. Zahl mit einer angegebenen Maßeinheit ist besser. Einfacher bei der Berechnung und durch die Maßeinheit der Systemvariable bleibt auch die Darstellung gleich.
2. Da es eine Systemvariable ist, sollte mit "dom.GetObject(ID_SYSTEM_VARIABLES);" darauf zugegriffen werden.
3. Typenbezeichnung ist nicht object. Das hat zwar nur Auswirkungen wenn etwas wie Blacks genialer Editor verwendet wird, aber schadet auch nicht. Es hat also nur Vorteile.
4. Name der Variable "solar1" enthält nicht den Typ. Das ist bei größeren Scripten durchaus nützlich. bSchlagMichTot z.B. ist bei mir boolean, iBitteNicht integer und ratet mal, rDochStirb ist...
5. Name der Systemvariablen "StromVorTageserzeugung PV". Nun ja, es gibt einen Unterschied zwischen Strom (A) und Arbeit (kWh), aber noch mehr würde ich auf Leerzeichen, die Dinger sind unsichtbar, verzichten und mehr Struktur da rein bringen. Angelegt an andere objektorientierte Sprachen/Datendefinitionen sieht das eher so aus: "PV.VorTageserzeugung". Damit sind selbst bei der WebUI die Einträge gruppiert und können später in anderen Sprachen schnell in eine Struktur umgewandelt werden.

"gsolar.State((solar1.State() + solar2.State()).Round(2));"
Würde jetzt mit der Umwandlung als Sysvariable Zahl laufen. Schreibt man Scripts, die die Systemvariablen nicht automatisch anlegen, würde ich es wie folgt erledigen:
"gsolar.State(( 0.0 + solar1.State() + solar2.State()).Round(2));"
Das läuft auf einer CCU2 wenn die Systemvariable Zahl ist (Zahl.ToFloat() knallt wohl auf der CCU2) und auch beim Systemvariablen Typ String.

Klammern reduzieren, um es leserlicher zu gestalten. Debugmöglichkeit einbauen und...
Ergebnis:

Code: Alles auswählen

!Skript zur Berechnung Gesamterzeugung Solar

object oSysVar = dom.GetObject(ID_SYSTEM_VARIABLES);
object oPvVorTag = oSysVar.Get("Pv.VorTageserzeugung");
object oPvGestern = oSysVar.Get("Pv.SoBaGestern");
real rGes = 0.0 + oPvVorTag.State() + oPvGestern.State();
! WriteLine ( rGes );
oSysVar.Get("Pv.Gesamt").State(rGes.Round(2));

[MichaelN]

oSchlagMichTot z.B. ist bei mir boolean,

Wegen dem b im Namen? SCNR