MAX! Cube Blockly Abwesenheit
-
@mickym said in MAX! Cube Blockly Abwesenheit:
@marko1974 sagte in MAX! Cube Blockly Abwesenheit:
Wenn ich das nicht hätte selbst machen wollen, wäre ich nicht jeden und jeden Tag dran es zu perfektionieren.
Dann hätte ich mir auch homekit fertige Dinge kaufen können und hätte keinen Stress. Die Möglichkeiten sind immens und so schön individualisierbar.
Waschmaschine....ein ganz schlechtes ThemaVielleicht machen wir es bei den nächsten Flows - der Telegrammausgabe so, dass ich Dir sage, wie man es implementiert - ggf. auch mit Screenshots - aber ich exportiere keine Flows mehr, sondern schau mir nur an, was Du gemacht hast.
Also bitte ergänze bitte die beiden Objekte aus den beiden Change Nodes mit den zugehörigen Thermostaten und stelle mir hier die JSON Strings zur Verfügung - das wäre mal ein guter Anfang.
Ich mache das morgen....jetzt ist wieder Bettzeit.
Bin schon wieder arg drüber. -
@marko1974 Ok dann schlaf gut - ich werde versuchen den restlichen Flow zu erläutern. Bin auch morgen abend erst so wieder zwischen 21 und 22 Uhr wieder da.
Ansonsten am Nachmittag falls was ist. -
@mickym said in MAX! Cube Blockly Abwesenheit:
@marko1974 Ok dann schlaf gut - ich werde versuchen den restlichen Flow zu erläutern. Bin auch morgen abend erst so wieder zwischen 21 und 22 Uhr wieder da.
Ansonsten am Nachmittag falls was ist.
-
@marko1974 So also die Heizung Switch Node verteilt die Nachrichten auf die einzelnen Heizungen, in dem
die room Eigenschaft des msg. Objektes analysieren.
In den einzelnen Heizungen switch Nodes wird nun der aktuelle Modus analysiert:
Je nachdem was für ein Modus aktiv ist wird das Nachrichtenobjekt an die verschiedenen Ausgänge geleitet und ausser der AUTO Modus Node. Dieser AUTO Mode hat zu den manuellen Modi 2 zustätzliche Aufgaben:
- Die Temperatur soll nach einem Zeitschema geändert werden
- Der Auto-Mode soll aktiv übernehmen, auch wenn aus einem anderen Mode nach AUTO gewechselt wurde.
Punkt 2 hat gestern nicht funktioniert, da die AUTO Node (also die Subflow Node) überhaupt nicht mitbekommen hat, wenn wieder auf AUTO gewechselt wurde. Das erste Mal hat der AUTO Node funktioniert, dann wurde auf OFF umgestellt, hat auch funktioniert dann wieder auf AUTO zurückgestellt und es kam nichts mehr raus.
- Nun war mir zwar klar warum, aber am Anfang war die Lösung, wie die AUTO Node den Modewechsel mitbekommt trotzdem nicht so einfach.
Im Prinzip hätte AUTO erst wieder übernommen, wenn eine neue Zeitperiode aktiv wird. Sprich wenn man von OFF auf AUTO gewechselt hat und die aktuelle Zeitperiode von 9-22 Uhr anhält, wäre nach Anwesenheit von OFF auf AUTO erst um 22 Uhr wieder ein Wechsel stattgefunden. Da am Anfang nur jede Node, die Nachrichten empfing für dessen Mode sie bestimmt war hat die AUTO Node nie mitbekommen, dass zwischenzeitlich ein anderen Mode eingestellt war und deshalb kein Temperatur verschickt, weil sich ja nichts geändert hat und generell ja nur Änderungen verschickt werden.Stellt man hingegen einen der anderen 3 Modes ein - ist das weniger tragisch. Hier wird nur dann weitergeleitet, wenn sich eine andere Temperatur ergibt. Wenn aber HEAT und ECO beispielsweise die gleiche Temperatur aufweist ist das egal, weil nichts geschickt werden muss, weil wenn nichts gesendet wird es auch egal ist, wenn sich der Modus geändert hat - in beiden Fällen wird nichts gesendet. Es wird also keine Temperatur verschickt, wenn sich diese durch den Modus nicht ändert. Also wenn man den Modus von HEAT auf ECO und umgekehrt wechselt und beide auf die gleiche Temperatur eingestellt sind, wird keine Nachricht an den setpoint des Thermostats verschickt.
Die Auto Node hat aber nicht die unterschiedliche Temperatur als Kriterium für das Versenden von Nachrichten, sondern nur ein Wechsel der Zeitperiode.
Deswegen stand ich gestern vor der Herausforderung, wie ich es bewerkstellige, dass die AUTO Nodes ein Wechsel des Modus mitbekommen. Da das aber in einem Subflow ist - funktioniert das auch mit den Kontextvariablen nicht so einfach. Nach einer Stunde hatte ich dann den Geistesblitz erst mal alle Nachrichten - nicht nur die mit der Eigenschaft mode=AUTO an die Subflow Node also an die AUTO Node weiterzureichen.
Das heisst auch alle Nachrichten im mode=HEAT,ECO oder OFF gehen auch an die AUTO node. Deswegen wird beim ersten Ausgang der Heizungsnode einfach nur gepüft, ob das Nachrichtenobjekt nicht leer ist und das trifft ja auf alle Nachrichten zu. (Vorher stand eben für den ersten Ausgang für den mode = AUTO drin analog zu den anderen Modi).
So nun schauen wir erst mal die Subflows - also die AUTO Nodes an - und war erst mal im Hinblick auf die Behandlung des Moduswechsels.
Hier nochmal in der Subflow in ganzer Ansicht:
Wichtig sind die beiden switch Nodes - die als Filter dienen und die parallel angeordnet sind und somit wie bei einem Schaltplan (deswegen wieder eine Stärke dieses Tools) auch grafisch einer ODER Verknüpfung gleich zu setzen ist.
Die payload wird über die Temperatur gesetzt - ansonsten bleibt das originale Nachrichten aber erhalten.
und das ist in diesem Fall genial .Eine rbe Node scheidet auf, weil hier nur auf Werteänderung der payload geprüft wird.
Schauen wir uns also als nächstes das Nachrichtenobjekt an, dass aus so einer Temperaturnode herauskommt, die ja wie folgt definiert ist:
Sie definiert ein payload Objekt mit der zur jeweiligen Periode zugrhörigen Temperatur:
WIchtig ist also - wie das Nachrichtenobjekt der Temperatur-Nodes aussieht:
Unten sieht man das payload object, die als Zahl die aktuelle Periode enthält.
Ursprünglich war also nur die switch Node da - die geprüft hat, ob sich die Periode geändert hat, das hätte auch eine rbe Node gekonnt. Nun musste ich einen Umgehungsweg finde, wie trotzdem eine Nachricht weitergeleitet wenn sich der modus geändert hat.
Deshalb werden 2 unterschiedliche Bereiche des Nachrichtenobjektes untersucht und das konnte mit 2 parallel geschalteten Switch Node erreicht werden, die auf Werteänderung einmal der Periode
und einmal des modes prüfen:
Wird eine der beiden Bedingungen erfüllt - wird nun die Nachricht weitergeleitet. Nun da ja alle Nachrichten dort ankommen, werden nun ja auch Nachrichten durchgelassen, die beim Moduswechsel zwischen 2 anderen mode's
erfolgen (also ECO und OFF). Um diese Nachrichten nicht durchzulassen, werden diese dann am Ende ausgefiltert, sodass die AUTO Nodes nichts ausspuken:
Dieses Mal muss die 2. switch Node in Serie geschaltet werden - um eine UND Verknüpfung zu implementieren. Es muss also ein Moduswechsel stattgefunden haben und die mode Eigenschaft AUTO aufweisen, damit der untere Weg die Nachricht durchlässt.
So zum Schluss noch eine kurze Erklärung der restlichen Nodes damit die Nachricht bzw. das msg.Objekt an der richtigen Temperaturnode ausggeben wird - hier gibts ein paar Tricks - die ich selbst erst mal rausgefunden habe, um den Flow einigermaßen übersichtlich zu halten:
Als erstes wird ein neues payload Objekt generiert und zwar mit einer sehr mächtigen JSONATA Funktion:
Die erste Change Node erzeugt folgendes payload Objekt der aktuellen Uhrzeit und des aktuellen Wochentags - wenn ein Nachricht in die AUTO Node kommt.
Die Change Node ist wie folgt aufgebaut:
Über die beiden unteren Regel werden 2 Datumsobjekte des aktuellen Zeitpunkts generiert und im ersten Objekt der Wochentag extrahiert mit dem Format "dddd" und der payload Eigenschaft weekday zugewiesen und mit dem Format "HH:mm" der payload Eigenschaft time zugewiesen.
Wenn man in der Change Mode bei dem JSONATA auf die 3 Punkte klickt - dann kann man den Befehl editieren und sieht auch die ganzen JSONATA Funktionien, die hier genutzt werden können:
In diesem Fall ist die Beschreibung der $moment Funktion eher spärlich:
Hier eine Webseite - welche Funktionen die Moment Library beschreibt:
https://momentjs.com/docs/#/displaying/format/
Hier die verwendeten Formate kurz hervorgehoben:
So nun noch die nächste switch Node - um mal zu zeigen, wie man reguläre Ausdrücke in switch Nodes auch anders nutzen kann.
Anstelle von 7 Ausgängen für jeden Wochentag und Verkabelung mit einem Zeitschema - kann man auch nur die Anzahl der benötigten Ausdrücke definieren und regEX nutzen indem man einfach die zu match (enden) Wörter mit ODER verknüpft:
die richtige Temperatur mit dem richtige Ausgang wird über die folgende Switch Node gesetzt wobei hier String Vergleiche aber mit Bereichen sehr einfach implementiert werden können:
So wir nähern uns dem Ende.
Bei den anderen Modi wird die Temperatur einfach auf die eingelesenen Werte oder einen konstanten Wert für OFF gesetzt:
OFF wird einfach auf einen konstanten Zahlenwert, also auf 4.5 gesetzt:
Bei eingelesenen Werten wird die payload auf die eingelesenen Werte und somit auf die im Nachrichtenobjekt mitgeführten Eigenschaften ausserhalb des payload Objektes gesetzt:
So nun der Ausgänge des Hauptflows je Heizung:
Aus allen 4 Nodes kommt also ein Zahlenwert raus, der die Temperatur darstellt, der für den setpoint des DP des MAXCube Adapters geschickt werden soll. Allerdings nur wenn die Temperatur verändert ist, sonst würde alle Minute ein Temperaturwert für jedes Thermostat geschickt und spätesten nach 10 Minuten ist der DutyCycle vor - deswegen oberste Prio bei diesem Flow war - nur wirklich notwendige Nachrichten zu verschicken.
Die rbe Node lässt grundsätzlich nur veränderte Werte durch und enthält den letzten gesetzten Temperaturwert.
Wie oben schon erwähnt, wenn zwischen den manuellen Modi gewechselt wird und die Temperatur nicht geändert wird muss auch kein Nachricht gesendet wird.Setzt man also die ECO Temperatur im Datenpunkt unter userdata auf 4,5°C und wechselt zwischen ECO und OFF - wird keine Nachricht gesendet usw. .
Die AUTO Node hat zum einen Bypass - da ja der Zeitplan weiter aktiv bleiben muss. Wenn man die Temperatur des AUTO Nodes nur in die rbe Node fließen lassen wurde, dann würde das auch beim Wechsel der Periode geblockt, wenn die nächste Temperaturänderung der letzten Temperatur eines AUTO Modus übereinstimmt. Sprich war der letzte manuelle Modus als HEAT 22°C und die aktuelle Periode im AUTO Modus ist auch 22°C würde keine Nachricht weiter geleitet.
Wir wollten ja, dass wenn man mit ALEXA einen neue Temperatur setzen als 24°C, dass das AUTO Programm weiter aktiv wird und wir nicht den manuellen Modus ausschalten müssen, da der MAX Cube Adapter immer auf den manuellen Modus umschaltet, sobald eine Temperatur gesetzt wird. Dies ist und war ja der Hauptgrund warum wir den ganzen Aufwand betreiben - weil es nicht gewünscht war, dass man aktiv wieder vom manuellen Modus wieder in den AUTO Modus schalten muss.
Da ALEXA ja direkt den setpoint des Thermostates setzt, soll ja bei nächsten Wechsel der Zeitperiode die Temperatur des AUTO Plans aktiv sein und das geht nur, wenn die AUTO Node senden kann, egal welchen Wert die letzte Temperatur eines manuellen Modus war.So das war die Begründung warum ein Kabel aus der AUTO Node die rbe Node umgeht. Warum muss man trotzdem die AUTO Node mit der rbe Node verbinden?
In der rbe steht ja immer ein Temperaturwert und der muss sich ändern, um die Nachricht weiterzuleiten. Wenn man die Nachricht aus der AUTO Node einfach direkt weiterschickt - war ja im ursprünglichen Flow so und die rbe die gesetzte Temperatur des AUTO Nodes nicht mitbekommt, dann passiert folgendes.
Es wird auf Modus OFF gesetzt, rbe Node enthält 4.5°C - Nachricht wird geschickt, weil die rbe Node ja noch nicht initialisiert war und es noch keinen Vorgängerwert gibt. Nun wird auf AUTO umgeschaltet - es wird direkt 17°C an den setpoint des Thermostats geschickt. Nun schaltet man wieder auf OFF. Es wird keine Nachricht geschickt, da dort ja immer noch 4,5°C steht. Also wird die rbe Node auch mit der Temperatur der AUTO Nodes versorgt. Damit wird beim Zurückschalten auf OFF die NAchricht wieder weitergeleitet, weil nun in der rbe Node ja die 17°C der Auto Node stehen und die 4,5°C ja nun wieder eine Wertänderung darstellt.So und nun die Entprell-Node - eine Trigger Node - die genialste Node im gesamten NodeRed System - weil die für so viele Anwendungsfälle verwendet werden kann.
Nun in diesem Fall werden ja aus dem AutoNode ein NAchrichtenobjekt beim Wechsel in den AUTO Mode einmal in die rbe Node geschickt und einmal direkt an die Verzögerungsnode. Es würden also 2 mal die gleichen Nachrichten mit der gleichen Temperatur geschickt. Das kann man zwar eigentlich vernachlässigen, aber um halt sicherzustellen, dass nur eine Nachricht verschickt wird - prüft man einfach, dass wenn innerhalb eines bestimmten Zeitraums nur 1 Nachricht verschickt wird.Deshalb ist die Trigger Node (also die Entprellen Node) wie folgt konfiguriert.
So als erstes kommt die Nachricht von der AUTO Node direkt in die Trigger Node und kurz darauf von der rbe Node. Die trigger Node wartet also 1 Sekunde und innerhalb dieser Sekunde 2 Nachrichten reinkommen, wird nur die letzte Nachricht geschickt.
Eigentlich ist das ein unnötige Verzögerung. Im Prinzip kann man die Trigger Node umgekehrt konfigurieren:
In diesem Fall wird die Nachricht aus der AUTO Node sofort und ohne Zeitverzögerung weitergeleitet. Die Nachricht der rbe Node die innerhalb einer Sekunde kommt, wird weggeschmissen. Das Intervall wird ausgedehnt wenn immer weitere Nachrichten kommen - das heißt jedes Dauerfeuer wird unterbrochen.
Zum Schluss werden alle Nachrichten mit einer halben Sekunde Verzögerung verschickt. Da die Heizungen ja parallel arbeiten - laufen die also in einer Node zusammen und werden dort in einer Queue gespeichert und dann mit gebremster Geschwindigkeit weitergeleitet.
So nun habe ich den Flow erklärt. Ich habe versucht sowohl die Funktion der Nodes zu erklären, aber auch die Logik, die in dem Flow steckt. Wichtig dafür ist aber wirklich, dass man sich voll auf diese Logik konzentriert, wenn sich da ablenken lässt - dann gibt es zuviele Logikfehler. Ich hoffe das wurde deutlich in dem ich versucht habe diverse Szenarien logisch in dem Flow durchzuspielen.
So nun habe ich fertig.
Und nochmal ein Tipp - wenn ich mir Eure Waschmaschinen- Blocklies anschaue. Überleg Dir mal wieviel Komfort so eine TriggerNode oder eine Aggregator Node für Dich bieten würde.
Lies Dir mal die Hilfe zu diesen Nodes durch. -
@marko1974 Nach dem Du ja beim Thema Waschmaschine schon wieder mit Blocklies unterwegs bist, scheinen Dich ja meine Tipps am Ende meiner Flow Beschreibung weniger zu interessieren.
Um Dir die Möglichkeiten der Split Node auch in Zusammenhang mit einer JOIN Node zu demonstrieren - habe ich im folgendem Flow mal ein paar Beispiele zusammen gefasst:
Ansonsten dann bis später am Abend.
-
@mickym said in MAX! Cube Blockly Abwesenheit:
@marko1974 Nach dem Du ja beim Thema Waschmaschine schon wieder mit Blocklies unterwegs bist, scheinen Dich ja meine Tipps am Ende meiner Flow Beschreibung weniger zu interessieren.
Um Dir die Möglichkeiten der Split Node auch in Zusammenhang mit einer JOIN Node zu demonstrieren - habe ich im folgendem Flow mal ein paar Beispiele zusammen gefasst:
Ansonsten dann bis später am Abend.
Ich hab da halt schon fertige Sachen gehabt und passe die nur an. Was komplett neu machen wollte ich da eigentlich nicht. Das blockly war ja schon fertig.
-
@marko1974 sagte in MAX! Cube Blockly Abwesenheit:
Ich hab da halt schon fertige Sachen gehabt und passe die nur an. Was komplett neu machen wollte ich da eigentlich nicht. Das blockly war ja schon fertig.
Na wenn es funktioniert ist ja gut - ich hab ja nur den Eindruck - noch nicht so wie gewünscht.
-
@mickym said in MAX! Cube Blockly Abwesenheit:
@marko1974 sagte in MAX! Cube Blockly Abwesenheit:
Ich hab da halt schon fertige Sachen gehabt und passe die nur an. Was komplett neu machen wollte ich da eigentlich nicht. Das blockly war ja schon fertig.
Na wenn es funktioniert ist ja gut - ich hab ja nur den Eindruck - noch nicht so wie gewünscht.
Der Eindruck könnte stimmen
-
@marko1974 sagte in MAX! Cube Blockly Abwesenheit:
@mickym said in MAX! Cube Blockly Abwesenheit:
@marko1974 sagte in MAX! Cube Blockly Abwesenheit:
Ich hab da halt schon fertige Sachen gehabt und passe die nur an. Was komplett neu machen wollte ich da eigentlich nicht. Das blockly war ja schon fertig.
Na wenn es funktioniert ist ja gut - ich hab ja nur den Eindruck - noch nicht so wie gewünscht.
Der Eindruck könnte stimmen
Na nachdem Ausschalten des Knitterschutzes jetzt sicher kein Problem mehr.
-
@mickym said in MAX! Cube Blockly Abwesenheit:
@marko1974 sagte in MAX! Cube Blockly Abwesenheit:
@mickym said in MAX! Cube Blockly Abwesenheit:
@marko1974 sagte in MAX! Cube Blockly Abwesenheit:
Ich hab da halt schon fertige Sachen gehabt und passe die nur an. Was komplett neu machen wollte ich da eigentlich nicht. Das blockly war ja schon fertig.
Na wenn es funktioniert ist ja gut - ich hab ja nur den Eindruck - noch nicht so wie gewünscht.
Der Eindruck könnte stimmen
Na nachdem Ausschalten des Knitterschutzes jetzt sicher kein Problem mehr.
Wäscht gerade zum 4 Mal
-
@mickym
habs jetzt hinbekommen -
@mickym said in MAX! Cube Blockly Abwesenheit:
@mickym Wohlfühltemperaturen habe ich nun anhand des AutoTemplates verstanden.
Wenn Du diese Telegramm Ausgabe mti den setpoint Temperaturen auslesen möchtest - solltest Du diese Info das auszulesende Topic - mit vollständigem Pfad einfügen:Ich würde am Besten fallst Du das mit dem Auslesen der originalen setpoint Temperaturen übernehmen willst - die Objekte um diese Eigenschaft ergänzen. Das würde ich aber dann bei beiden Change Nodes machen.
Hab die Pfade mal eingetragen:
irgendwie ist das ja nicht alles....entweder muss ich jetzt auch noch so ne Art Topic haben....oder der Pfad muss doch zumindest das .setpoint am Ende haben?!
-
@marko1974 Ja - aber den setpoint können wir doch an den String anhängen. Mit dem Thermostat Pfad haben wir nun aber schon mal den Basispfad und können damit auch noch andere Punkte als setpoint ansprechen, wenn dafür später Bedarf ist.
Wenn Du mir die beiden JSONs bitte hier in CodeTags zur Verfügung stellst - kann ich die in meinem Testflow nutzen - auch wenn Du jetzt die Nodes alle selbst erstellst.
-
@marko1974 sagte in MAX! Cube Blockly Abwesenheit:
irgendwie ist das ja nicht alles....entweder muss ich jetzt auch noch so ne Art Topic haben....oder der Pfad muss doch zumindest das .setpoint am Ende haben?!
Nein das ist noch lange nicht alles - aber nachdem Du anderen Flow und die Split Node verstanden hast, wirst Du den Flow selbst entwicklen und ich gebe Dir die Anleitung dazu.
-
@mickym said in MAX! Cube Blockly Abwesenheit:
@marko1974 Ja - aber den setpoint können wir doch an den String anhängen. Mit dem Thermostat Pfad haben wir nun aber schon mal den Basispfad und können damit auch noch andere Punkte als setpoint ansprechen, wenn dafür später Bedarf ist.
Wenn Du mir die beiden JSONs bitte hier in CodeTags zur Verfügung stellst - kann ich die in meinem Testflow nutzen - auch wenn Du jetzt die Nodes alle selbst erstellst.
für ECO
{ "Kinderzimmer": { "mode": "ECO", "thermostat": "maxcube.0.devices.thermostat_0dbe6c" }, "Schlafzimmer": { "mode": "ECO", "thermostat": "maxcube.0.devices.thermostat_0b39f5" }, "Wohnzimmer": { "mode": "ECO", "thermostat": "maxcube.0.devices.thermostat_0d1718" }, "Flur": { "mode": "ECO", "thermostat": "maxcube.0.devices.thermostat_0dc05e" }, "Küche": { "mode": "ECO", "thermostat": "maxcube.0.devices.thermostat_0df97e" }, "Badezimmer": { "mode": "ECO", "thermostat": "maxcube.0.devices.thermostat_0dfa5c" } }für Auto
{ "Kinderzimmer": { "mode": "AUTO", "thermostat": "maxcube.0.devices.thermostat_0dbe6c" }, "Schlafzimmer": { "mode": "AUTO", "thermostat": "maxcube.0.devices.thermostat_0b39f5" }, "Wohnzimmer": { "mode": "AUTO", "thermostat": "maxcube.0.devices.thermostat_0d1718" }, "Flur": { "mode": "AUTO", "thermostat": "maxcube.0.devices.thermostat_0dc05e" }, "Küche": { "mode": "AUTO", "thermostat": "maxcube.0.devices.thermostat_0df97e" }, "Badezimmer": { "mode": "AUTO", "thermostat": "maxcube.0.devices.thermostat_0dfa5c" } } -
@marko1974 OK - dann setzt Du nun eine weitere Change Node hinter die split Node und setzt den topic String so zusammen, dass das topic den vollständigen Pfad zum setpoint Datenpunkt enthält. Am besten immer ein Debug Node mit dem vollständigen Objekt ausgeben lassen.
Der Output der Nachricht für jeden Thermostat muss dann so aussehen, dass im room der Raum und im topic der Pfad zu dem zugrhöhrigenen setpoint des koorespondierenden Thermostats im setpoint zeigt:
-
@mickym said in MAX! Cube Blockly Abwesenheit:
@marko1974 OK - dann setzt Du nun eine weitere Change Node hinter die split Node und setzt den topic String so zusammen, dass das topic den vollständigen Pfad zum setpoint Datenpunkt enthält. Am besten immer ein Debug Node mit dem vollständigen Objekt ausgeben lassen.
Der Output der Nachricht für jeden Thermostat muss dann so aussehen, dass im room der Raum und im topic der Pfad zu dem zugrhöhrigenen setpoint des koorespondierenden Thermostats im setpoint zeigt:
Verstehe ich nicht. die eine change node bleibt stehen und ich setze ne neue zusammen?
-
@marko1974 Ja - wo ist das Problem - wir wollen doch eine Telegram Nachricht erzeugen, wenn Abwesenheit eintritt? - Wenn Du Dir nicht sicher bist schicke einen Screenshot - aber der output schaut doch gut aus - die bisherigen Nodes darfst Du natürlich nicht anfassen.
-
@mickym ja so hab ich das...bin beim topic ich will ja alle auslesen
-
@marko1974 sagte in MAX! Cube Blockly Abwesenheit:
@mickym ja so hab ich das...bin beim topic ich will ja alle auslesen
Genau nun ein iobroker get Node und damit liest Du alle setpoints aus. Die payload sollte nun alle Themperaturen der setpoints aus den verschiedenen Topics enthalten.
