ElabNET Technik Forum

Moin,

ich versuche seit einigen Tagen ohne Erfolg einen Wert aus den MQTT-Daten eines Shelly BLU H&T auszuwerten.
Kann mir vielleicht jemand auf die Sprünge helfen, wie ich den markierten Wert unten erhalten kann?
Den ersten ts-Eintrag bekomme ich ohne Probleme ausgelesen.

{
"src": "shellyhtg3-80b54e3565f8",
"dst": "shellies/shellyhtg3-80b54e3565f8/events",
"method": "NotifyEvent",
"params": {
"ts": 1768733580.46,
"events": [
{
"component": "sys",
"event": "sleep",
"ts": 1768733580.46
}
]
}
}

Hi Mirko,

params.events[component="sys"].event



Viele Grüße,
Matthias

Auch hier empfehle ich MQTT Explorer. Da kannst drauf klicken su fden Wert und erzeugt Dir den Pfad dahin.

Anson3gjbt es auch diverse webseiten die das als Servcie biegen und dir dann den Selektor rückliefern.

So jetzt am Handy.

Sollte sein.

Hallo Matthias und Göran,

beide Hinweise führen zum korrekten Ergebnis.

Vielen Dank für die schnelle Hilfe.

Ich habe jetzt ein weiteres Problem mit dem Shelly.

Ich erhalte das folgende JSON.
Wie stelle ich das hier am Besten ein, dass die Formatierung bestmöglich erhalten bleibt und ich trotzdem farbige Markierungen vornehmen kann?

{
"src": "shellyhtg3-80b54e3565f8",
"dst": "shellies/shellyhtg3-80b54e3565f8/events",
"params": {
"ht_ui": {},
"wifi": {
"status": "got ip",
"ssid": "XXXX",
"bssid": "XX:XX:XX:XX:XX:XX",
"rssi": -77,
"sta_ip": "XXX.XXX.XXX.XXX",
"sta_ip6": null
},
"ts": 1768767541.54,
"temperature:0": {
"tF": 71.6,
"id": 0,
"tC": 22.0
},
"sys": {
"ram_free": 161744,
"uptime": 0,
"last_sync_ts": null,
"fs_size": 1048576,
"unixtime": null,
"webhook_rev": 0,
"time": null,
"ram_size": 262152,
"utc_offset": 3600,
"ram_min_free": 158936,
"kvs_rev": 0,
"reset_reason": 8,
"mac": "80B54E3565F8",
"cfg_rev": 12,
"restart_required": false,
"wakeup_period": 7200,
"fs_free": 712704,
"wakeup_reason": {
"boot": "deepsleep_wake",
"cause": "periodic"
},
"available_updates": {}
},
"mqtt": {
"connected": true
},
"ws": {
"connected": false
},
"devicepower:0": {
"battery": {
"percent": 59,
"V": 5.2
},
"id": 0,
"external": {
"present": false
}
},
"humidity:0": {
"rh": 37.5,
"id": 0
},
"ble": {},
"cloud": {
"connected": false
}
},
"method": "NotifyFullStatus"
}


Für die markierten Werte liefert mir https://jsonselector.com die folgenden Selectoren, die so aber nicht 1zu1 funktionieren.

['params']['temperature:0']['tC']
['params']['devicepower:0']['battery']['percent']
['params']['devicepower:0']['battery']['V']
['params']['devicepower:0']['external']['present']
['params']['humidity:0']['rh']

Muss ich diese Ausgaben für den TWS noch anpassen und wie hat dies zu erfolgen?
Ich habe es auch schon erfolglos ohne die eckigen Klammern und ohne die Hochkommata versucht.

Irgendwie stehe ich noch auf dem Schlauch und bräuchte weitere Hilfe.

Da gibt die Webseite eine Art des Selektros raus den der TWS nicht verwendet. Es gibt da wohl mehrere Dialekte in der weiten Welt der IT.

Im TWS funktioniert es ganz gut wenn man alle Elemente die im Original JSON per {} gestaffelt werden per Punkt . Trennt, alles was in einer solchen Stufe per , getrennt im Original daher kommt ist das Keywords was Du dann nach dem Punkt angibst.

Das sind dann einfache verschachtelte Hierarchien die stets zu genau einem Einzelwert oder weiteren "Ordnern" führen.

Hast im Original [ ] diese eckigen Klammern dann ist diese Wertsammlung oder Hierarchieebene ein Array. Die ruft man im Selektor auch mit den eckigen Klammern auf [ ] ohne Punkt davor.
In dem eckigen Klammern sucht man entweder per spezifischen Platzhalter wie es Matthias gemacht hat. Oder man nimmt die Positionsnummer des Objektwertes im Array. 0 wenn es das erste Element ist, oder 1 wenn es das 2. Element ist.

Das mit den Positionsnummern ist gut, wenn die Menge an Elementen im Array konstant ist von Nachricht zu Nachricht und auch die Positionen untereinander. Wenn es beweglich ist im Array dann besser den Spezifischen Bezeichner suchen.

params.humidity:0.rh

Wäre es rein von der Struktur her. Müsstest nur noch schauen ob das mit dem :0 so direkt funktioniert oder der Begriff humidity:0 maskiert werden muss. Ggf in doppelte Anführungsstriche.

Da gab es mal einen Threads wo es um diese Shelly Outputs mit den Wort:Zahl Objekten ging. Da würde dann glaube noch was nachgezogen im TWS, um das auch selektieren zu können.

mir gibt der JSON Path Finder für die Temperatur folgendes zurück

x.params["temperature:0"].tC dann sollte es beim Wolf mit params["temperature:0"].tC gehen.


Wenn Dein Shelly ein /event/rpc bringt, bekommst du die Daten sich auch alle über /status

So, ich bin jetzt ein Stück weiter gekommen.

params."temperature:0".tC ist die korrekte Schreibweise, bei der die Daten erkannt werden. Allerdings kommen zwischendurch immer Daten, die keine Treffer liefern.

Über /status bekomme ich die Daten auch. Ich wollte jetzt aber mal schauen, welche Daten öfter gesendet werden oder es es keinen Unterschied macht.
Ich schreibe die Daten beider Verfahren jetzt jeweils in eine Zeitreihe und dann entscheide ich weiter.

Ja das kann passieren wenn die Quelle nicht alle Werte immer mit schickt. Das stört dem TWS aber nicht so sehr, da er nur einen gültig empfangenen Wert auch nach hinten ins Objektsystem weiter reicht.

Weil bei beiden Methoden die selbe Anzahl von Datenpunkten geschrieben wird, kann man ohne Nachteile die "status"-Werte nutzen.
Bei denen ist die JSON-Struktur viel einfacher und das Senden der RPC-Daten kann entfallen. Die ganzen technischen Daten bei RPC sind in der Regel überflüssig.