Shelly json Rückgabe Status - WaMa schalten per CCU2

[Accuracy]

Hallo,
ich habe in meine CCU2 einen ShellyPM mit Leistungsmessung über CuxD erfolgreich eingebunden. Ich kann per HM den Shelly AUS und EIN schalten und sehe auch den Status des Shellys richtig in der CCU2 reflektiert.

Wenn ich im Browser jetzt folgenden Befehl eingebe:
http://192.168.1.78/status

bekomme ich einen String mit den einzelnen Werten vom Shelly per Komma getrennt angezeigt:
...."meters":[{"power":588.04,"overpower":0.00,"is_valid":true, ...

Speziell der Wert hinter Power interessiert mich. Diesen möchte ich auslesen und in eine Variable schreiben und später in meinem WaMa Programm verwenden.

z.B. WENN Power kleiner als XYZ DANN Schalte WAMA aus.

Mein Problem:
wie bekomme ich den Wert ausgelesen und in Realtime in eine Variable gespeichert und permanent aktualisiert?

[Tyfys]

Wenn es dir nur um diesen einen Wert geht, probier es so:

Code: Alles auswählen

string JSON_daten= 'meters":[{"power":588.04,"overpower":0.00,"is_valid":true,';
JSON_daten = JSON_daten.ToLatin();
JSON_daten = JSON_daten.Replace("\n", "");  ! Zeilenumbrüche entfernen
JSON_daten = JSON_daten.Replace("\r", "");  
string wert = JSON_daten.Substr(JSON_daten.Find(suche) + suche.Length());
wert = (wert.Substr(0 ,wert.Find(',') )).ToFloat();
WriteLine(wert);

Ansonsten guck dir das von MichaelN an: viewtopic.php?f=18&t=68762

[Accuracy]

ok schaue ich mir an. Aber bekomme ich den Wert dann permanent oder nur einmal wenn das skript läuft? weil ich benötige den Wert ja ca. alle 2s damit ich sehen kann wie er sich verändert

[MichaelN]

Du musst das natürlich permanent abfragen. Bei einem HM(IP) Aktor würde es automatisch laufen, aber ein Shelly spricht ja nicht HM.
ABER: ich würde nicht dazu raten das alle 2 s zu machen. Das kann Dir deine CCU lahm legen / ausbremsen.

[Fonzo]

wie bekomme ich den Wert ausgelesen und in Realtime in eine Variable gespeichert und permanent aktualisiert?

In Realtime nur per MQTT, da musst Du Dir also MQTT nachträglich auf die CCU basteln, bei einer CCU2 ist das aber wegen der Hardware nicht empfehlenswert, bei einer CCU3 wäre das was anderes.

[Xel66]

Das kann Dir deine CCU lahm legen / ausbremsen.

Ich denke eher, das diese Ausage das Problem verniedlicht. Das wird definitv die CCU lahm legen. Da ist die mit nichts weiter beschäfitgt, als den Status der Waschmaschine zu akualisieren. Ich frage mich auch, was an einem Waschmaschinenstatus so zeitkritisch ist, dass eine Automation im Sekundenbereich reagieren muss. Ganz abgesehen von der Tatsache, dass die Firmware der CCU nicht wirklich dazu geeignet ist, externe Dienste abzufragen. Selbst ein Schreiben von extern im Takt weniger Sekunden würde ich als stabilitätsgefährdend betrachten.

... bei einer CCU3 wäre das was anderes.

An der Stelle würde ich mich fragen, warum der Hersteller bei zyklischer Taktung drauf hinweist, maximal alle 15 Minuten (IRC) zu triggern.

Gruß Xel66

[MichaelN]

würde ich mich fragen, warum der Hersteller bei zyklischer Taktung drauf hinweist, maximal alle 15 Minuten (IRC) zu triggern

Das frage ich mich auch. Für die CCU 2 war das eventuell auch noch angemessen. Die CCU 3 verträgt definitiv mehr. Aber ich würde mich an dem üblichen Zeitraster der HM Sensoren orientieren und als kleinsten Abstand 3 Minuten empfehlen. Wenn etwas zeitkritischer ist, dann ist es keine Aufgabe für eine Hausautomation.

[Fonzo]

An der Stelle würde ich mich fragen, warum der Hersteller bei zyklischer Taktung drauf hinweist, maximal alle 15 Minuten (IRC) zu triggern.

Nun der Hersteller e-Q3 unterstützt kein MQTT, daher ist dieser Hinweis ja berechtigt. Bei MQTT wird aber nicht getriggert, sondern das Gerät selber pusht den Status an die CCU bzw. den MQTT Client. Da der Hersteller aber kein MQTT anbietet, muss man das höchstens von Hand irgendwie durch basteln nachrüsten oder man nutzt gleich ein externes System was MQTT kann und lässt die CCU3 selber damit in Ruhe.
Zumindest wird bei MQTT der Status nicht aktiv abgeholt, sondern das Gerät benachrichtigt bei einer Status Änderung, das ist der wesentliche Unterschied dazu, ob man den Status aktiv zyklisch abfragen muss, das fällt nämlich bei MQTT weg. Daher ist MQTT aber auch der einzige Weg, die Daten zeitnah bzw. in Echtzeit zu aktualisieren ohne ständig aktiv den Status anfragen zu müssen.

[Samson71]

Speziell der Wert hinter Power interessiert mich.

Wenn Du den Shelly eh schon mit CUxD integriert hast, dann müsstest Du doch auch die Leistung um CUxD-Gerät mit drin haben. Ist im Shelly-Forum gut dokumentiert und braucht keine externen Server, MQTT oder andere Middleware oder Zusatzsoftware auf der CCU.

https://www.shelly-support.eu/forum/ind ... firmware/

[Xel66]

Nun der Hersteller e-Q3 unterstützt kein MQTT, daher ist dieser Hinweis ja berechtigt. Bei MQTT wird aber nicht getriggert, sondern das Gerät selber pusht den Status an die CCU bzw. den MQTT Client.

Also genau, wie es die Homematic-Messaktoren machen. Heißt, der Hersteller hat eine Funktion in seine zum Sytem gehörende Aktorik eingebaut. Wenn man diese nutzt, funktioniert es auch und dann benötigt man auch solche kurzen Aktualisierungsintervalle nicht. Die wären dem Duty Cycle auch mehr als abträglich. Für schnelle Reaktion auf sich ändernde Parameter gibt es aber die Entscheidungswerte.

Daher ist MQTT aber auch der einzige Weg, die Daten zeitnah bzw. in Echtzeit zu aktualisieren ohne ständig aktiv den Status anfragen zu müssen.

Falscher Schluss. Der korrekte Weg ist die Benutzung der zum System gehörenden Aktorik mit Messfunktion. Speziell bei "besonderen" Anforderungen. Und wer auf Biegen und Brechen Fremdaktorik implementieren will muss eben basteln. Ein entsprechende MQTT-Addon für eine CCU3&Co gäbe es durchaus. Eine CCU2 (und im die ging es doch laut Titel) dagegen zu zwingen will, mit einem Aktualiserungsinterval mit wenigen Sekunden per HTTP einen externen Status abzuholen, legt sein System vorzüglich auf die Flurplatte. Geiz ist (anscheinend) geil, Homematic auch. Homematic und Geiz zusammen in Verbindung mit Vonhintendurchdiebrustinsaugeworkarounds führt aber eher zu Frust. Just my 2ct - jeder ist seiner Systemstabilität Schmied.

Gruß Xel66