NEWS
Shellys ("Alt und Plus") über MQTT Adapter
-
@hotspot_2 Wenns beschreibbar soll musst Du writeable eintragen - kannst DU nachträglich noch unter common eintragen
-
@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 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. ;)
-
@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. :)
-
@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. ;)
-
@mickym Ah, jetzt habe ich es gesehen. Das mit dem "JSON" Node. Das probiere ich gleich mal aus.
@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:
-
@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:
-
@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. ;)Jeder Flow bzw. jedes Script, das ich hier poste implementiert jeder auf eigene Gefahr. Flows und Scripts können Fehler aufweisen und weder der Seitenbetreiber noch ich persönlich können hierfür haftbar gemacht werden. Das gleiche gilt für Empfehlungen aller Art.
-
@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. ;) -
@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. ;) -
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 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".
-
@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".
@mickym Da ich viel mit Pushover, dem Alexa Adapter (Durchsagen) mache würde ich mir gerne ein paar zusätzliche Nodes installieren. Mein iobroker Server läuft auf debian auf einem NUC i3.
Wenn ich da was nachinstalliere passt das mit der Anleitung hier (also mit dem iobroker Adapter), oder?
-
@hotspot_2 Ja - aber nichts manuell installieren sondern nur über den Paletten-Manager. Ggf. den Haken in der Adapterkonfiguration aktivieren. Also nicht mit npm rumfuhrwerken.
Bei dem Adapter macht die Installation eigener Nodes wahrscheinlich Sinn weil der Adapter im iobroker nur mit SendTo Kommandos funktioniert. Ansonsten wenn Du bereits Adapter hast, die mit einer Hardware kommunizieren - erst den versuchen den Adapter zu nutzen.Wenn die Node nicht funktioniert habe ich auch ein kleines JS geschrieben mit dem man SendTo über einen Datenpunkt schreiben kann. Quasi als Proxy. Aber machs erst mal mit der Node. ;)
Also mach das mit der NOde - das ist sicher in dem Fall die beste Wahl - hier mal der Thread wie man SendTo über einen "Proxy-Datenpunkt" simulieren kann: https://forum.iobroker.net/topic/57210/nodered-sendto-proxy-mit-js
Du gehst ja ganz schön flot voran - es scheint, dass Dir NodeRed gefällt. ;)
886
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge