Neue Logikbausteine für den L1/X1: Formelberechnung, Statistik und mehr...

[jaydee73]

Kannst ja mal ein komplettes JSON-Beispiel posten, wenn Du nicht weiter kommst...

Ich befürchte, auf das Angebot muss ich jetzt zurückkommen. ;-)

Anbei eine pdf mit dem JSON-Request (wusste nicht, wie ich den Request mit richtiger Formatierung hier einfügen kann...).

Bevor ich überhaupt mit Formelumrechnung irgendwelche falschen Schlüssel rausfiltere, bekomme ich schon ein anderes Problem. Ich möchte den Wert P_PV auslesen, aber das "null" wird nicht an den Ausgang weitergegeben. Wenn ich aber z.B. P_Grid auslese, dann bekomme ich die Zahl ausgegeben. Der Pfad zu P_PV wurde als Text definiert. Eine Fehlermeldung gibt es nicht. Es gibt keinen Wert am Ausgang.

Ich habe statt meines umfangreicheren Parsers auch mal testweise nur diesen einen Ausdruck geparst (da kommt auch der Screenshot her), aber auch hier landet nichts am Ausgang.

Weitere Info: Tagsüber, wenn die PV produziert, ist dieser Wert eine Zahl, nur abends/nachts dann der Ausdruck "null". Daher gebe ich das hier als Text aus. Aber dazu hattest du mir ja schon mal dankenswerterweise eine weitere Formel gegeben.

Und eine Fehlermeldung wegen ungültiger Schlüssel bekomme ich (derzeit) auch nicht mehr.

Bin für jede Hilfe dankbar.

Gruß,
Stefan

Edith: Ich bin der Meinung, dass der Ausdruck "null" mit der 1.25er Version des Bausteins noch ausgegeben wurde. Kann das sein?

[hyman]

{
    "Body" : {
        "Data" : {
            "Inverters" : {
                "1" : {
                    "DT" : 232,
                    "E_Day" : 28966,
                    "E_Total" : 9476000,
                    "E_Year" : 935278,
                    "P" : 0
                }
            },
            "Site" : {
                "E_Day" : 28966,
                "E_Total" : 9476000,
                "E_Year" : 935278,
                "Meter_Location" : "grid",
                "Mode" : "meter",
                "P_Akku" : null,
                "P_Grid" : 285.47000000000003,
                "P_Load" : -285.47000000000003,
                "P_PV" : null,
                "rel_Autonomy" : 0,
                "rel_SelfConsumption" : null
            },
            "Version" : "12"
        }
    },
    "Head" : {
        "RequestArguments" : {},
        "Status" : {
            "Code" : 0,
            "Reason" : "",
            "UserMessage" : ""
        },
        "Timestamp" : "2020-03-19T18:02:25+01:00"
    }
}

Hier muss auf jeden Fall "1" durch was anderes ersetzt werden, z. B. "one".

Wenn da, wo null steht normalerweise ein Zahlenwert steht, dann darf man wohl annehmen, dass dieser Wert 0 ist. Also insgesamt folgende Textersetzung vor dem Parsen:

{text:S}.Replace("\"1\"","\"one\"").Replace("null","0.0")

Dann aber im JSON-Parser "Erster Treffer als Zahl" auswählen.

Grüße von Horst

[hyman]

PS: Am XML-/JSON-Parser habe ich mit der Version 1.28 nichts geändert. Wenn das vorher funktioniert hat, dann wahrscheinlich deshalb, weil da wirklich ein Zahlenwert und nicht null stand...

[jaydee73]

Tausend Dank! Ich werde das heute Abend (wenn also "null" ausgegeben wird) und morgen tagsüber (wenn eine Zahl ausgegeben wird) testen.

[jaydee73]

So, das funktioniert soweit. Vielen Dank nochmals, Horst!

Eine (kosmetische) Sache noch: Die Tausendertrennzeichen (Baustein Textformatierer) sind beim Datentyp "N" enthalten, richtig? Und es sind Kommas, keine Punkte, also nicht 12.345, sondern 12,345. Auch richtig?

In der Simulation sind am Ausgang allerdings Punkte als Trennzeichen:

Unbenannt.JPG

Erst in der X1-App werden dann Kommas als Trennzeichen angezeigt. Grundsätzlich ist ein Komma aber doch mathematisch gesehen nicht das richtige Tausendertrennzeichen, oder?

[hyman]

Ja, richtig, "N" ist mit Gruppentrennzeichen. Welches Gruppentrennzeichen verwendet wird, hängt vom Kulturkreis ab. Ich verwende zur Formatierung von Fließkommazahlen CultureInfo.CurrentCulture, was offenbar beim X1 anders als auf (Deinem und meinem) PC funktioniert.

Bei uns ist üblich, Punkte als Gruppentrennzeichen zu nehmen (und Komma als Dezimaltrennzeichen). So macht es der PC hierzulande beim Testen und in der Simulation. In den USA ist es z. B. grad andersrum: Komma als Gruppentrennzeichen und Punkt als Dezimaltrennzeichen. So macht es wohl der X1.

Wahrscheinlich sollte ich einfach eine deutsche CultureInfo nehmen (de-de), die stimmt für unsere Zwecke mit dem EU-Standard überein. Und seit dem Brexit auch mit der EU-weiten Praxis. Ist dann zwar etwas egozentrisch, aber wenigstens auf dem X1 und in der Simulation gleich. Oder mach's irgendwie konfigurierbar (dann aber auch mit de-de als Default)...

[hyman]

Muss mich grad mal selber zitieren:

Wahrscheinlich sollte ich einfach eine deutsche CultureInfo nehmen (de-de), die stimmt für unsere Zwecke mit dem EU-Standard überein

... aber leider nicht damit, wie Gira in seinen Visu-Elementen numerische Werte anzeigt -- da wird nämlich der Punkt als Dezimaltrennzeichen (und kein Gruppentrennzeichen) verwendet. Dazu sollte der Textformatierer konsistent sein.

Bleibt also nur, auch dort Punkt als Dezimaltrennzeichen zu verwenden und das Tausender-/Gruppentrennzeichen -- für das ja aus Verwechselbarkeitsgründen meist kein Komma verwendet werden soll -- evtl. konfigurierbar zu machen. Folgende Auswahl sollte für alle Wechselfälle des Lebens reichen:

• Prime, Hochstrich, ASCII-Code 39, Unicode U+0027,
  Beispiel: 12'345'678
• Gravis, Akzent, ASCII-Code 96, Unicode: U+0060
  Beispiel: 12`345`678
• Leerzeichen, ASCII-Code 32, Unicode U+0020,
  Beispiel: 12 345 678
• geschütztes Leerzeichen, ISO-8859-1- (erweiterter ASCII-) Code 160, Unicode U+00A0
  Beispiel: 12 345 678
• schmales geschütztes Leerzeichen, Unicode U+202F,
  Beispiel: 12 345 678
• Sechstelgeviert, Unicode U+2006,
  Beispiel: 12 345 678
• Haarspatium, Unicode U+200A,
  Beispiel: 12 345 678
• Apostroph, einfaches Hochkomma, Unicode U+2019,
  Beispiel: 12’345’678
• Komma, ASCII-Code 44, Unicode U+002C,
  Beispiel: 12,345,678

Als Default würde ich den Hochstrich nehmen, weil der das (in üblichen Propotionalzeichensätzen) schmalste der in Frage kommenden ASCII-Zeichen ist (also wirklich überall funktioniert) und keine Verwechslungsgefahr birgt.

Kommentare?

Grüße von Horst

[hyman]

Wirklich keine Meinungen? Dann kann ich ja die Darstellung mit Gruppentrennzeichen auch ganz ausbauen.

OK, Scherz. Aber konfigurierbar mach' ich das nur, wenn darin ein Mehrwert gesehen wird. Das ist nämlich durchaus Aufwand. Sonst entscheide ich, was ich möchte und mach das erst mal fest...

[jaydee73]

Also ich finde die Varianten alle irgendwie nicht so prickelnd, wofür du natürlich nichts kannst. Ich bin daher dazu übergegangen, dass gemäß "Gira-Vorgaben" zu nutzen. Also gar kein Gruppentrennzeichen.

Beim Hochstrich (und allen Derivaten) finde ich, besteht Verwechslungsgefahr mit Längen- und Breitengraden.

[Brainbug]

Hallo,
wenn ich das richtig sehe, kommt die Trennung doch nur bei "N" und nicht bei "n", oder?
Dann fände ich Trennzeichen schon sehr nett und würde für ein schmales geschütztes Trennzeichen plädieren

Viele Grüße

[hyman]

Hallo,

wenn ich das richtig sehe, kommt die Trennung doch nur bei "N" und nicht bei "n", oder?

Nicht ganz. Fließkommazahlen können auf drei Arten formatiert werden (Auszug aus der Hilfedatei):

• F – Fließkommazahl (Number), ohne Tausendertrennzeichen formatiert
  • Ohne Formatparameter wird die Zahl gerundet auf zwei Nachkommastellen dargestellt.
  • Mit einer Ziffer als Formatparameter (z. B. F1) wird die Zahl gerundet auf die angegebene Zahl von Nachkommastellen dargestellt (im Beispiel mit einer Nachkommastelle).
• N – Fließkommazahl (Number), mit Tausendertrennzeichen formatiert. Ansonsten wie F.
• G – Fließkommazahl, formatiert ähnlich wie F, jedoch mit zwei Abweichungen:
  • Die Format-Ziffer gibt nicht die Zahl der Nachkommastellen, sondern die Zahl der geltenden Ziffern an.
  • Exponentialschreibweise (wissenschaftliche Notation) wird benutzt, wenn dies zu einer kompakteren Darstellung führt.
  Beispiel: Die Zahl 12.345.678,9 wird mit G4 als 1,235E+07 dargestellt.

Groß- und Kleinbuchstaben bewirken im Format immer das Gleiche.

schmales geschütztes Trennzeichen

Für alles, was kein ASCII sein muss (weil es nur im X1 weiter verarbeitet wird), ist das sicher ein sehr sinnvolles Trennzeichen. Da es Unicode ist, funktioniert es leider nicht auf allen Endgeräten und schon gar nicht auf Gruppenadress-Datenpunkten der Typen DPT 16.000 (bis zu 14 ASCII-Zeichen) oder 16.001 (bis zu 14 ISO-8859-1-Zeichen). Als Default wollte ich deshalb gern ein ASCII-Zeichen, finde aber das normale Leerzeichen zu breit.

gar kein Gruppentrennzeichen.

Kein Problem, einfach F oder f am Anfang des Formats schreiben. Was bei N oder n passiert, interessiert Dich dann gar nicht.

Beim Hochstrich (und allen Derivaten) finde ich, besteht Verwechslungsgefahr mit Längen- und Breitengraden.

Ja, aber immer noch viel besser als Komma.

Weitere Stimmen?

[hyman]

Mal wieder ein neues Anwendungsbeispiel. Für einige Vorgänge (z. B. die Müllerinnerung) brauche ich zu bestimmten Zeiten ein Trigger-Telegramm. Weil ich dafür keine Zeitschaltuhr verwenden möchte, erzeuge ich das wie folgt:

image_96015.png

Der Datenpunkt "Local-Time" findet sich unter Geräte-Datenpunkte → ... → Ortszeit.

[crettig]

Hallo Hyman,

vielen Dank für die tollen X1 Bausteine! Ich habe eine Frage: Kann man mit dem Textformatierer irgendwie auch Datum Uhrzeit verarbeiten?

Hintergrund: Ich möchte in einer X1 Kachel die letzte detektierte Bewegung/Präsenz im Haus mit Angabe Raumname + Uhrzeit anzeigen. Problem ist halt die Uhrzeit ...

Vorab vielen Dank
und viele Grüße
Carsten

[hyman]

Hallo Carsten,

mit dem Textformatierer irgendwie auch Datum Uhrzeit verarbeiten?

Nein.

letzte detektierte Bewegung/Präsenz im Haus mit ... Uhrzeit anzeigen

Schau Dir dafür mal den Baustein "Formelberechnung" an. Der kann auch Texte ausgeben und intern mit C#-Formeln wie z. B. DateTime.Now.ToString umgehen. Das Beispiel "Feiertage" in der zugehörigen Dokumentation zeigt, wie man einen Triggereingang dazu benutzen kann, so eine Formel im richtigen Moment auszuwerten. Damit sollte sich Dein Problem lösen lassen.

Grüße von Horst

[crettig]

... ok, dann versuche ich es mal mit dem Baustein "Formelberechnung".

Vielen Dank und viele Grüße
Carsten