Shellys ("Alt und Plus") über MQTT Adapter
-
@mickym Jupp, das war es.
-
@mickym Ok, hier der Vergleich wenn kein Update verfügbar ist.
``
{"mac":"441793CFA490","restart_required":false,"time":"20:38","unixtime":1680201504,"uptime":172817,"ram_size":234796,"ram_free":161160,"fs_size":458752,"fs_free":102400,"cfg_rev":13,"kvs_rev":0,"schedule_rev":0,"webhook_rev":0,"available_updates":{}} -
@hotspot_2 Wenns beschreibbar soll musst Du writeable eintragen - kannst DU nachträglich noch unter common eintragen
-
@hotspot_2 sagte in Shellys ("Alt und Plus") über MQTT Adapter:
@mickym Ok, hier der Vergleich.
{"mac":"441793CFA490","restart_required":false,"time":"20:38","unixtime":1680201504,"uptime":172817,"ram_size":234796,"ram_free":161160,"fs_size":458752,"fs_free":102400,"cfg_rev":13,"kvs_rev":0,"schedule_rev":0,"webhook_rev":0,"available_updates":{}}Sag ich doch leeres Objekt.
-
@mickym Ja, aber wenn nur eine Beta da ist steht oben dann steht statt stable beta drin. Und ich würde gerne nur ein true auf meinem Objekt haben wollen wenn es eine neue stable version gibt.
-
@hotspot_2 sagte in Shellys ("Alt und Plus") über MQTT Adapter:
@mickym Ja, aber wenn nur eine Beta da ist steht oben dann steht statt stable beta drin. Und ich würde gerne nur ein true auf meinem Objekt haben wollen wenn es eine neue stable version gibt.
Dann prüfst Du halt nur auf stable. Du hast doch Inject Nodes mit dem Du alles ausprobieren kannst.
Ich versuch mal ein Video zu machen, damit Du lernst sowas selbst zu simulieren. Das Video ist zu groß.
-
-
@hotspot_2 Du kannst das nur ziemlich verkürzen, wenn Du Dich an das Vorgehen hälst.
Man kann es zwar auch so wie Du machen - in dem Du auf Existenz des Schlüssel prüfst. 
-
@mickym Ah, jetzt habe ich es gesehen. Das mit dem "JSON" Node. Das probiere ich gleich mal aus.
-
@hotspot_2 NEIN. Die JSON Node ist für was anders da.
-
@hotspot_2 Du sollst das Objekt als Debug Node darstellen:
Dann kopierst Du den Pfad zu der Eigenschaft den Du untersuchen willst . Diesen kopierst Du in der Switch Node DORT rein, welche Eigenschaft des Nachrichtenobjektes untersucht werden soll.
Also
payload.available_updates.stableist die Eigenschaft die Du untersuchen willst:
mit den Inject Nodes testest Du.
Ok der Switch war falsch - weil Du auf Existenz prüfst und das ist null oder nicht null:
Fazit: Also ganz verkehrt war die Existenz des Schlüssels nicht, aber man kann ohne die Change Node davor auskommen.
Also in deinem alten Flow - hätte man sich die Change Node wie folgt sparen können:
-
@mickym Ist es richtig das wenn kein Inhalt in available_updates steht das dann available_updates.stable undefinded ist?
-
@hotspot_2 richtig
Da ist ja nichts drin. in dem Objekt. Ja und wenn etwas nicht definiert ist - also das Objekt leer ist, dann ist es undefined. Und undefined = null Wie gesagt Deine ursprünglicher Switch war auch nicht schlecht:
-
-
Zeig Dir gleich noch eine Möglichkeit - wie Du das mit einer ChangeNode hinbekommst. Wenn Du Dich etwas mit JS auskennst, dann kennst Du diese Methode über JSONATA
In der Change Node prüfst Du also ebenfalls ab ob
diese Eigenschaft true ist . wenn ja gib true aus, sonst false:
-
@hotspot_2 sagte in Shellys ("Alt und Plus") über MQTT Adapter:
@mickym Das ist jetzt komisch.
Warum in diesem Fall hast Du die payload auf das Objekt available_updates gesetzt. Diese 1. Change NOde muss raus. -
@mickym Ok. Passt!
-
@mickym Das schöne ist in NodeRed - Du hast JEDERZEIT auf alle Eigenschaften eines Objektes Zugriff.
-
@mickym Die ist natürlich richtig chic!
-
@hotspot_2 Du siehst die Möglichkeiten sind mannigfaltig.
Für das setzen eines Wertes in Abhängigkeit eines anderen, ist die Change NOde ausreichend. Wenn aber unterschiedliches Vorgehen in der Folge gewünscht sind, dann nimmst Du den Switch. Das ist dann Blockly "falls" und "sonst".
