Das Modul stört sich am „-“ (genauso wie an „+“, „(leer)“, UTF-8 Umlaute etc), aber nicht an „_“.
Vielleicht gelegentlich beheben oder zumindest die Erzeugung von „Unnamed Object“ abfangen und die eigentliche Fehlermeldung auf die Debug-Konsole des HTTP-Clients legen (der Decoder hat anscheinend keine).
Unicode-Kram wie Ivrit, Arabisch, Thai funktioniert und wird im Objektbaum auch dargestellt, "A\"BCD\"EF" kommt als A"BCD"EF, "A\\BCD\\EFG" wird zu A\BCD\EFG, \t\n\r\b\f werden ignoriert bzw. führen zu einem Leerzeichen, \u02AC (UTF-8) wird korrekt interpretiert.
Ein deplaziertes \ wie in A\BCD führt allerdings dazu, dass nichts aus dem JSON verarbeitet wird, alles kleiner ASCII 32 stoppt auch, ASCII > 125 läuft durch (Zeichen wird ignoriert). \u1234 macht Ärger (darf es aber auch weil UTF-16)
Es gibt dazu leider keine Fehlermeldung, das Debugfenster loggt brav die gelesenen Zeilen als wäre alles OK.
Hallo zusammen,
habe ein ähnliches Problem mit dem JSON-Decoder. Wollte gestern den E-Manager meiner PV-Anlage einbinden in IPS. Geliefertes JSON sieht aus wie folgt und wird bspw. von jsonformatter.org auch als korrekt interpretiert:
{„PowerSelfConsumption“:975,„PowerConsumption“:4611.320835347777,„PowerOut“:0,„StatesOfCharge“:{„WorkCharge“:0,„ModeConverter“:„DISCHARGING“,„StateOfCharge“:0},„PowerTotalPV“:975,„PowerPVPeak“:9880,„PowerSelfSupply“:975,„PowerIn“:3636.3208353477767,„PowerConsumptionMax“:{„2022-02-08“:7578.606996213425,„2022-02-11“:6201.404129824219,„2022-02-09“:7269.091071623297,„2022-02-05“:7095.309944975941,„2022-02-10“:7126.100412435824,„2022-02-06“:5402.768875986471,„2022-02-07“:6621.249443707236}}
Abgesehen davon dass keine sinnvollen Variablen angelegt und gefüllt werden, habe ich dann nach zwei Stunden gesehen, dass offenbar knapp 2000 Variablen „Unnamed Object“ angelegt wurden.
Habe dann die ganze neue JSON-Decoder-Instanz erstmal wieder gelöscht:
Offenbar legt sich der Decoder bei „PowerConsumptionMax“ auf die Nase. Aber auch für alle anderen Wert wurde nichts sinnvolles dekodiert.
Ist das der gleiche Fehler, der hier schon beschrieben ist? Ich sehe allerdings in meinem Fall keine Sonderzeichen im JSON.
Ansonsten ist der JSON-Decoder eine wirklich tolle Sache. Vielen Dank dafür!! Funktioniert bei meiner Sonnenbatterie ganz wunderbar. Muss da nur noch „erraten“ was in welcher Variable steckt.
Danke für die schnelle Antwort. Mir ist nur nicht ganz so klar, was das jetzt für meinen Fall bedeutet. Ich bin kein Programmierer und nutze hier den in IPS eingebauten JSON-Decoder. Und am JSON-Output des E-Managers kann ich auch nichts ändern.
Heißt das also für mich, dass ich den eingebauten JSON-Decoder für meinen Anwendungsfall nicht benutzen kann. Richtig?
Aktuell heißt es das. Ich habe mir selber ein Dummy Device angelegt und einen MQTT Server Device (welches dann den JSON String hat). Dann gibt es ein Script, welches über die Ereignisverwaltung bei Onchange ausgefürt wird.
Inhalt etwa:
<?php
$parent = 15499; // ID des Dummy Moduls
if($_IPS['SENDER']=="Execute"){
// Hier alle Variablen mit Datentyp definieren. Der IDENT mit dem durch die Replace Methode veränderten, aus den übermittelten Daten, übereinstimmen.
$values = array(
// Ident => Datentyp
'heatingActive' => 'bool',
'tapwaterActive' => 'string',
'selFlowTemp' => 'float',
'selBurnPow' => 'int'
);$i=0;
foreach($values as $key => $value){
print "'$key' => '$value',\n";
$type = array('string'=>3,'int'=>1, 'bool' => 0, 'float'=>2);
$id = IPS_CreateVariable($type[$value]);
IPS_SetParent($id, $parent);
IPS_SetIdent($id, $key);
IPS_SetName($id, $key);
IPS_SetPosition($id, $i++);
}
}elseif($_IPS['SENDER']=="Variable"){
// Ausführung mqtt Ereignis
//IPS_LogMessage($_IPS['SELF'], print_r($_IPS,true));
$data = json_decode($_IPS['VALUE'],true);
//$data = json_decode(GetValue(47430),true);
foreach($data as $key => $value){
$key = str_replace(array("ä","ö","ü","ß","-"," "), "_", $key); // Diese Zeile ersetzt das Schlüsselwort so, dass es ein gültiger IDENT sein könnte. Ggf. müssen noch weitere Zeichen eingebunden werden.
$id = IPS_GetObjectIDByIdent($key, $parent);
if($id>0){
//print $id ." ".IPS_GetName($id) ."\n";
$value = ($value=="on") ? 1 : ( ($value=="off") ? 0 : $value );
SetValue($id, $value);
}
}
}
Wenn „Unnamed Objects“ bei Parserfehlern erscheinen, ist das nicht die aktuelle Beta.
Spiel die ein, da ist das Problem weg - ich das extra mitgetestet. Das einzige was nicht geht, ist ein Sinnfreies \ in den Strings, ASCII < 32 und UTF-16 (UTF-8 geht komplett)
OK. Danke. Verstanden (hoffe ich). Bin erst seit 2 Monaten mit Symcon unterwegs… Das ist dann jetzt wohl der Punkt an dem ein Test-System her muss. Setze ich die Tage auf und teste das dann mit der Beta. Werde berichten.
Viele Grüße
Rainer
Hi. Kann jetzt bestätigen, dass der JSON-Decoder jetzt auch mit dem Solarworld-Emanager funktioniert und der Schleifenfehler mit „Unnamed Object“ in der 6.3 nicht mehr auftritt. Ich habe bislang zwei URLs gefunden die JSON-Daten liefern. Ich weiß nicht, ob es noch mehr gibt. Ich poste die hier mal die zwei, da vielleicht auch für andere E-Manager-Besitzer hilfreich: http://xxx.xxx.xxx.xxx/rest/solarworld/lpvm/powerAndBatteryData http://xxx.xxx.xxx.xxx/rest/solarworld/sgready/momentaryValues
Beide URLs liefern Daten. Allerdings habe ich mit den Daten aus der ersten URL noch ein Problemchen: Wie man im Screenshot von „sixtusfreebyte“ vom 11. Feb. sieht, wird in der Sub-Instanz „PowerConsumptionMax“ für die letzten sieben Tage jeweils eine Variable mit dem Tagesdatum als Name angelegt. Ich habe zwar noch über 500 Variablen frei, aber dennoch würde ich das gerne „optimieren“. Denn es wird ja wohl jeden Tag eine neue Variable angelegt.
Meine Vorstellung wäre es, jeden Tag einmal den Wert der Vortages-Variable in eine neue Variable mit aktivem Archiv zu schreiben und alle Sub-Variablen, die älter als 7 Tage sind zu löschen.
Wie könnte man das bewerkstelligen?
OK. Habe begonnen mich in PHP und die Variablen-Verwaltung in IPS via Script einzulesen. Denke das wird nach einem Jahr mit IPS jetzt mein erstes selbst erstelltes PHP-Script werden.