MAX! Cube Blockly Abwesenheit

[mickym]

@marko1974 sagte in MAX! Cube Blockly Abwesenheit:

Zu Deinem letzten Wunsch - wie hättest Du die Ausgabe den gerne?
Wenn Du Dich wie gesagt anscheinend doch nicht so gerne intensiv mit dem Flow auseinandersetzen willst - würde ich es vielleicht doch wieder mit Blockly versuchen?
Ja doch....ich bin doch die ganze Zeit da drin.
Im Prinzip nimmst Du egal ob mit Blockly oder NodeRed wieder Deinen absenceAll Punkt.
Nee wenn dann jetzt auch in Node-Red

Im Prinzip würde ich auch die setpoint Temperaturen im MaxCube Adapter nehmen, da diese in jedem Fall den aktuellen Zustand representieren?
Die Frage ist nur macht es Sinn - die Temperaturenabfragen durch den Abwesenheitstrigger einmal abzufragen oder sollten Temperaturänderungen triggern und dann nur während der Abwesenheit Meldungen erzeugen? Damit hättest Du nicht nur eine einmalige Abfrage des Temperaturzustände, sondern die Überwachung der Temperaturzuständen während der gesamten Abwesenheitsdauer?

Also ich weiss nicht ob das nicht zu hoch gegriffen ist. Du meinst quasi wie sich die Temperatur des Raumes verändert?
Ich meinte eher, dass man kurz schauen kann auf welche Temperatur nun jede Heizung gesetzt wird.
Das wird glaube ich aber auch schnell langweilig.

Nein nicht die aktuelle Temperatur - sondern der Inhalt des setpoints des Thermostat Datenpunktes. Wir speichern diesen Wert nicht selbst und er ist der letztlich massgebende Wert für das Thermostat. Also bitte die Pfade zu den Thermostaten mappen, wie ich das abgebildet habe.

[Marko1974]

@mickym said in MAX! Cube Blockly Abwesenheit:

@marko1974 sagte in MAX! Cube Blockly Abwesenheit:

@marko1974 sagte in MAX! Cube Blockly Abwesenheit:

@marko1974 was ich vielleicht gerne noch hätte ist, dass Telegram die Datenpunkte der verschiedenen Räume mit ausschmeisst.
Also dass man quasi sehen kann, wenn man draussen ist auf welche Temperaturen sie nun gestellt werden, aber nur wenn An- oder Abwesenheit sich ändern.
Nicht wenn das Auto Programm abläuft und man ist zuhause

Meine Fragen interessieren Dich eigentlich nicht, Du denkst schon wieder über weiter Features nach????

Das stimmt nicht und ist nur immer Dein Eindruck

Na ich bin mir immer noch nicht sicher, ob Du die split Node begriffen hast und was ein Javascript Objekt ist und es ist richtig, dass die ECO Temperatur tatsächlich immer ausgelesen wird, aber nachdem er dann ausgelsen wurde, wie wird er dann im Flow weiter verarbeitet? Und trotzdem würdest Du gerne noch eine telegramm Nachricht bekommen .

Nach rbe und entprellen ist bei mir Feierabend.....

[mickym]

@marko1974 sagte in MAX! Cube Blockly Abwesenheit:

@mickym said in MAX! Cube Blockly Abwesenheit:

@marko1974 sagte in MAX! Cube Blockly Abwesenheit:

@marko1974 sagte in MAX! Cube Blockly Abwesenheit:

@marko1974 was ich vielleicht gerne noch hätte ist, dass Telegram die Datenpunkte der verschiedenen Räume mit ausschmeisst.
Also dass man quasi sehen kann, wenn man draussen ist auf welche Temperaturen sie nun gestellt werden, aber nur wenn An- oder Abwesenheit sich ändern.
Nicht wenn das Auto Programm abläuft und man ist zuhause

Meine Fragen interessieren Dich eigentlich nicht, Du denkst schon wieder über weiter Features nach????

Das stimmt nicht und ist nur immer Dein Eindruck

Na ich bin mir immer noch nicht sicher, ob Du die split Node begriffen hast und was ein Javascript Objekt ist und es ist richtig, dass die ECO Temperatur tatsächlich immer ausgelesen wird, aber nachdem er dann ausgelsen wurde, wie wird er dann im Flow weiter verarbeitet?

Nunja....Node-Red funktioniert halt so, dass es Nachrichten durch die einzelnen Nodes schickt. Die Nachrichten sind Javascript objekte die einen bestimmten Typ haben können. z.b. Number, string oder boolean (also true or false). Die haben alle ne ID und können so auch getracked werden.
Der einfachste Weg zu sehen was gesendet wird ist die Debug node. Die kann ich halt auch so setten, dass ich nur bestimmte Dinge sehen möchte. Standardmäßig zeigt die erstmal den ganzen payload an. Interessant ist aber auch was in Object oder sonstigen unterpunkten passiert.

Die Nachrichten sind Javascript objekte die einen bestimmten Typ haben können. z.b. Number, string oder boolean (also true or false).

Das ist falsch - das wesentliche eines Javascript Objektes ist, dass es meist mehrere Eigenschaften besitzt, die skalare Werte (wie strings etc.) enthalten können aber auch weitere Objekte.

Aus dieser Webseite - hier mal die Person - als ein Objekt.

Und wie auf die Eingeschaften auf diese Objekte zugreifst.

Siehst Du Ähnlichkeiten mit dem JS Objekt in den Change Nodes?

[mickym]

@marko1974 sagte in MAX! Cube Blockly Abwesenheit:

@mickym said in MAX! Cube Blockly Abwesenheit:

@marko1974 sagte in MAX! Cube Blockly Abwesenheit:

@marko1974 sagte in MAX! Cube Blockly Abwesenheit:

@marko1974 was ich vielleicht gerne noch hätte ist, dass Telegram die Datenpunkte der verschiedenen Räume mit ausschmeisst.
Also dass man quasi sehen kann, wenn man draussen ist auf welche Temperaturen sie nun gestellt werden, aber nur wenn An- oder Abwesenheit sich ändern.
Nicht wenn das Auto Programm abläuft und man ist zuhause

Meine Fragen interessieren Dich eigentlich nicht, Du denkst schon wieder über weiter Features nach????

Das stimmt nicht und ist nur immer Dein Eindruck

Na ich bin mir immer noch nicht sicher, ob Du die split Node begriffen hast und was ein Javascript Objekt ist und es ist richtig, dass die ECO Temperatur tatsächlich immer ausgelesen wird, aber nachdem er dann ausgelsen wurde, wie wird er dann im Flow weiter verarbeitet? Und trotzdem würdest Du gerne noch eine telegramm Nachricht bekommen .

Nach rbe und entprellen ist bei mir Feierabend.....

Welche Node genau in dem Flow liest den ECO Wert aus dem Datenpunkt und wie?

Tipp - rbe und entprellen sind viel weiter hinten - und aus dem Feierabend wollen wir doch ein erhellendes Aufwachen am Morgen machen, oder?

[mickym]

@marko1974 sagte in MAX! Cube Blockly Abwesenheit:

Zumindest kenne ich nun schon Inject, change, iobroker out, split und auch debug nodes ...wie man die debugs intgriert, wie man sie an und ausmacht und wo die nachrichten ankommen....und dass man auch mal trocken üben kann.
Willst Du mir jetzt wirklich noch unterstellen, ich sei nicht lernfähig oder hab da keinen Bock drauf?
Ich bau doch sogar in blockly nach. Ja....teilweise war es kopiert, aber die Inhalte hab ich geändert....und genau dann weiss ich doch auch wie es funktioniert, oder? Wenn ich es mit meinen anderen Dingen nachbaue.
Das Fenster habe ich immer noch nicht fertig drin....

Na die split Node hast noch nicht richtig erklärt - mache ich in meinem nächsten Post. Wenn Du die Inject Node so halbwegs begriffen hast und den Unterschied, ob Du in den debug Nodes nur die payload oder das ganze Nachrichtenobjekt ausgibst - also das Javascript Objekt - dann weißt Du schon mal was zu den Grundlagen, auf den wir weiter aufbauen.

[Marko1974]

@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:

@marko1974 sagte in MAX! Cube Blockly Abwesenheit:

@marko1974 was ich vielleicht gerne noch hätte ist, dass Telegram die Datenpunkte der verschiedenen Räume mit ausschmeisst.
Also dass man quasi sehen kann, wenn man draussen ist auf welche Temperaturen sie nun gestellt werden, aber nur wenn An- oder Abwesenheit sich ändern.
Nicht wenn das Auto Programm abläuft und man ist zuhause

Meine Fragen interessieren Dich eigentlich nicht, Du denkst schon wieder über weiter Features nach????

Das stimmt nicht und ist nur immer Dein Eindruck

Na ich bin mir immer noch nicht sicher, ob Du die split Node begriffen hast und was ein Javascript Objekt ist und es ist richtig, dass die ECO Temperatur tatsächlich immer ausgelesen wird, aber nachdem er dann ausgelsen wurde, wie wird er dann im Flow weiter verarbeitet?

Nunja....Node-Red funktioniert halt so, dass es Nachrichten durch die einzelnen Nodes schickt. Die Nachrichten sind Javascript objekte die einen bestimmten Typ haben können. z.b. Number, string oder boolean (also true or false). Die haben alle ne ID und können so auch getracked werden.
Der einfachste Weg zu sehen was gesendet wird ist die Debug node. Die kann ich halt auch so setten, dass ich nur bestimmte Dinge sehen möchte. Standardmäßig zeigt die erstmal den ganzen payload an. Interessant ist aber auch was in Object oder sonstigen unterpunkten passiert.

Die Nachrichten sind Javascript objekte die einen bestimmten Typ haben können. z.b. Number, string oder boolean (also true or false).

Das ist falsch - das wesentliche eines Javascript Objektes ist, dass es meist mehrere Eigenschaften besitzt, die skalare Werte (wie strings etc.) enthalten können aber auch weitere Objekte.

Aus dieser Webseite - hier mal die Person - als ein Objekt.

Und wie auf die Eingeschaften auf diese Objekte zugreifst.

Siehst Du Ähnlichkeiten mit dem JS Objekt in den Change Nodes?

Ja die Heizung ist das eigentliche Objekt und die kann halt mehrere Eigenschaften haben.

Dann muesste ja auch gehen:

const heizung = {
name :  "Schlafzimmerthermo xyz",
mode: AUTO
setpointtemperature: 20
};

[Marko1974]

@mickym said in MAX! Cube Blockly Abwesenheit:

@marko1974 sagte in MAX! Cube Blockly Abwesenheit:

Zumindest kenne ich nun schon Inject, change, iobroker out, split und auch debug nodes ...wie man die debugs intgriert, wie man sie an und ausmacht und wo die nachrichten ankommen....und dass man auch mal trocken üben kann.
Willst Du mir jetzt wirklich noch unterstellen, ich sei nicht lernfähig oder hab da keinen Bock drauf?
Ich bau doch sogar in blockly nach. Ja....teilweise war es kopiert, aber die Inhalte hab ich geändert....und genau dann weiss ich doch auch wie es funktioniert, oder? Wenn ich es mit meinen anderen Dingen nachbaue.
Das Fenster habe ich immer noch nicht fertig drin....

Na die split Node hast noch nicht richtig erklärt - mache ich in meinem nächsten Post. Wenn Du die Inject Node so halbwegs begriffen hast und den Unterschied, ob Du in den debug Nodes nur die payload oder das ganze Nachrichtenobjekt ausgibst - also das Javascript Objekt - dann weißt Du schon mal was zu den Grundlagen, auf den wir weiter aufbauen.

Nein ich gebe immer das ganze Objekt aus, denn wie gerade mal wieder gelernt hat das JS Objekt mehrere Eigenschaften und die kann ich ja dann aufklappen.

[Marko1974]

@marko1974 kann ich nicht einfach ein injectnode mit get desiredtemperature nehmen?

[Marko1974]

@marko1974 said in MAX! Cube Blockly Abwesenheit:

@marko1974 kann ich nicht einfach ein injectnode mit get desiredtemperature nehmen?

nee das geht nicht...das ist quatsch

[Marko1974]

@mickym

ach guck mal....der injectnode holt sich den dutycycle aus dem adapter, wenn der kleiner oder gleich 85 ist dann dürfen erst die setpoints gesetzt werden.
ist er größer setzt er dutycycle ok auf false und es wird gar nichts aus dem flow an die heizungen gesendet. Somit läuft das nicht über - und er macht nen Logeintrag. Das hast du ganz schön gewitzt gemacht. Darunter ist noch ne inject node die den payload angibt.

[mickym]

@marko1974 sagte in MAX! Cube Blockly Abwesenheit:

Ja die Heizung ist das eigentliche Objekt und die kann halt mehrere Eigenschaften haben.
Dann muesste ja auch gehen:

> const heizung = {
> name :  "Schlafzimmerthermo xyz",
> mode: AUTO
> setpointtemperature: 20
> };

Richtig müsste es also wie folgt aussehen:

> const heizung = {
> name :  "Schlafzimmerthermo xyz",
> mode: "AUTO",
> setpointtemperature: 20
> };

Grundsätzlich ja - wenn Du in Javascript programmieren würdest.
Zugreifen würdest Du dann auf die Eigenschaften mit

var name= heizung.name;
var desiredTemperature = heizung.setpointtemperature

Die Variable name würde dann den String "Schlafzimmerthermo xyz" enthalten.
Du würdest noch einen Fehler bekommen, weil Du das Komma hinter AUTO vergessen hast, das die Eigenschaften voneinander abgrenzt und AUTO ein String ist, der immer in Anführungszeichen stehen muss

in Node Red definierst Du ein Objekt zum Beispiel in Inject-Nodes oder ChangeNodes - wenn Du beide geschweiften Klammern siehst - das weisst man also nicht einer Variablen zu, sondern wieder einer Eigenschaft des Nachrichtenobjektes.

Um Dein Beispiel zu nehmen - was Du im Javascript gemacht hast und es einem Objekt namens heizung zugewiesen hast - sieht dann in einer InjectNode, wie folgt aus:

Wenn Du also Deine Definition im JSON Editor einer Inject Node reinkopierst - bekommst Du Fehler - weil das Objekt wie oben beschrieben Syntaxfehler hast. Fährst Du mit der Maus über den Fehler bekommst Du eine Fehlermeldung, die Dir Hinweise geben:

Das Problem ist, dass Du die Objekteigenschaften nicht als Objekt direkt eingibst, sondern als JSON String. Deshalb müssen die Eigenschaften auch in "Anführungszeichen" setzen muss.

So würde also Deine Objektdefinition im NodeRed als JSON String aussehen:

dieses Objekt weisen wir also dem Objekt heizung zu und da in Node Red nur msg Objekt durch die Kabel laufen - ist das Objekt Heizung wiederum eine Eigenschaft des msg Objektes.

Nun lassen wir uns das ganze Javascript Object msg in der Debug Node ausgeben - indem wir das in der Debug Node so bestimmen:

Führen wir diesen Flow aus - und klappen im msg.objekt - das objekt heizung auf

siehst Du alle Eigenschaften Deines Objektes.

[mickym]

@marko1974 sagte in MAX! Cube Blockly Abwesenheit:

@mickym

ach guck mal....der injectnode holt sich den dutycycle aus dem adapter, wenn der kleiner oder gleich 85 ist dann dürfen erst die setpoints gesetzt werden.
ist er größer setzt er dutycycle ok auf false und es wird gar nichts aus dem flow an die heizungen gesendet. Somit läuft das nicht über - und er macht nen Logeintrag. Das hast du ganz schön gewitzt gemacht. Darunter ist noch ne inject node die den payload angibt.

Super !!! - Genau so ist - die Inject Node kannst wegschmeissen - die habe ich nur gebraucht - weil ich ja keinen MaxCube Adapter habe.

wenn der kleiner oder gleich 85 ist dann dürfen erst die setpoints gesetzt werden.

Nur wie kommt das OK des duty Cycle in den Hauptflow?

In diesem Fall wird die flow Variable dutyCycleOK auf true oder false gesetzt und dann unten in dem Flow abgefragt. Das ist nötig, da die Ereignisse ja nicht gleichzeitig an der selben Node ankommen.
Deswegen wird die flowVariable zeitlich unabhängig vom eigentlichen Flow gesetzt.

In der switch Node wird der Inhalt der flowVariablen abgefragt und dann der Flow entweder blockiert oder durchgelassen.

Die wichtigen Dinge markiere ich Dir immer farbig:

Du kannst Dir den Inhalt Deiner Kontextdaten wie folgt anschauen:

Im Kontextfenster siehst Du dann den Inhalt der Kontextvariablen - in diesem Fall der Flowvariable dutyCycleOK

hier musst Du aber immer manuell aktualisieren

[Marko1974]

@marko1974 Ich glaube ich habe gerade helle Momente:

Der Trigger fragt ab ob die Heizungssteuerung aktiv ist. Da wollten wir eventuell noch was vorbauen, also ist die erstmal IMMER aktiv jetzt.
Dann erstellst Du die Räume Kinderzimmer, Schlafzimmer etc.
mit topic setzen holt man sich quasi alle daten aus unseren erstellten DP in userdata0.heizung....keinen bestimmten, sondern alle. Nee die holt man sich nicht, sondern man setzt sie quasi als ein "Oberthema?" im nächsten Schritt in get mode im ioBroker in braucht man dann quasi nur nach mode zu fragen und muss den Datenpunkt nicht wählen, da man im Schritt davor quasi schon den Pfad bereitgestellt hat. So auch mit der Temperatur und auch der ecotemperatur
Neben den Räumen gibt es dann die Heizungen.....warum die als Eigenschaft msg.room haben weiss ich noch nicht. Zumindest zählt man dann auf welche heizungen es gibt.

Im nächsten Schritt setzen wir den Mode für jede Heizung der den Entweder unser Auto Profil sein kann, oder aber auch ECO, HEAT oder OFF. Off wird hier direkt eine Temperatur zugewiesen. Heat bekommt desiredTemperature als payload gesetzt und eco die eco_temperature. rbe hält was auf falls die alle unentwegt was senden. Entprellen sagtest Du ist was, dass es etwas verlangsamt wird, bevor es an den adapter punkt gesendet wird. Ob da nochmal ne Verzögerung rein muss darüber lässt sich streiten...und wenn dann noch der Duty cycle ok ist...als kleiner oder gleich 85 senden die Heizungen also der room an die DP direkt.

WIE WAR ICH?

[mickym]

@mickym So ich wollte mit der Theorie fortfahren, aber erst mal auf Dein Vorpost eingehen - Du wirst langsam immer besser - und nun beginnt es mir wieder etwas Spaß zu machen die Dinge zu erklären. Ich hoffe Du führst Dir auch meine Ausführungen zu dem JS und msg Objekt aus meinem vorangegangen Post zur Gemüte und fragst, wenn was unklar ist. Das ist mir wichtiger als der Flow - weil die Grundlagen musst Du verstehen, wenn Du den Flow verstehen willst. - Wie auch was eine Flowvariable etc. ist.

[Marko1974]

@mickym sind Quelle und Was ist zu tun nicht eigentlich nur ne Hilfestelllung für den besseren Überblick?

[Marko1974]

@mickym said in MAX! Cube Blockly Abwesenheit:

@mickym So ich wollte mit der Theorie fortfahren, aber erst mal auf Dein Vorpost eingehen - Du wirst langsam immer besser - und nun beginnt es mir wieder etwas Spaß zu machen die Dinge zu erklären. Ich hoffe Du führst Dir auch meine Ausführungen zu dem JS und msg Objekt aus meinem vorangegangen Post zur Gemüte und fragst, wenn was unklar ist. Das ist mir wichtiger als der Flow - weil die Grundlagen musst Du verstehen, wenn Du den Flow verstehen willst. - Wie auch was eine Flowvariable etc. ist.

Nee bei Flowvariablen bin ich noch nicht...

[Marko1974]

@mickym said in MAX! Cube Blockly Abwesenheit:

@marko1974 sagte in MAX! Cube Blockly Abwesenheit:

@mickym

ach guck mal....der injectnode holt sich den dutycycle aus dem adapter, wenn der kleiner oder gleich 85 ist dann dürfen erst die setpoints gesetzt werden.
ist er größer setzt er dutycycle ok auf false und es wird gar nichts aus dem flow an die heizungen gesendet. Somit läuft das nicht über - und er macht nen Logeintrag. Das hast du ganz schön gewitzt gemacht. Darunter ist noch ne inject node die den payload angibt.

Super !!! - Genau so ist - die Inject Node kannst wegschmeissen - die habe ich nur gebraucht - weil ich ja keinen MaxCube Adapter habe.

wenn der kleiner oder gleich 85 ist dann dürfen erst die setpoints gesetzt werden.

Nur wie kommt das OK des duty Cycle in den Hauptflow?

In diesem Fall wird die flow Variable dutyCycleOK auf true oder false gesetzt und dann unten in dem Flow abgefragt. Das ist nötig, da die Ereignisse ja nicht gleichzeitig an der selben Node ankommen.
Deswegen wird die flowVariable zeitlich unabhängig vom eigentlichen Flow gesetzt.

Dachte eigentlich weil der duty cycle check unabhängig vom restflow ist und quasi obendrüber gesetzt wird, sendet er ein okay in den flow, was dann unten abgefragt wird.

In der switch Node wird der Inhalt der flowVariablen abgefragt und dann der Flow entweder blockiert oder durchgelassen.

Die wichtigen Dinge markiere ich Dir immer farbig:

Du kannst Dir den Inhalt Deiner Kontextdaten wie folgt anschauen:

Im Kontextfenster siehst Du dann den Inhalt der Kontextvariablen - in diesem Fall der Flowvariable dutyCycleOK

hier musst Du aber immer manuell aktualisieren

[Marko1974]

@marko1974 said in MAX! Cube Blockly Abwesenheit:

@mickym said in MAX! Cube Blockly Abwesenheit:

@marko1974 sagte in MAX! Cube Blockly Abwesenheit:

@mickym

ach guck mal....der injectnode holt sich den dutycycle aus dem adapter, wenn der kleiner oder gleich 85 ist dann dürfen erst die setpoints gesetzt werden.
ist er größer setzt er dutycycle ok auf false und es wird gar nichts aus dem flow an die heizungen gesendet. Somit läuft das nicht über - und er macht nen Logeintrag. Das hast du ganz schön gewitzt gemacht. Darunter ist noch ne inject node die den payload angibt.

Super !!! - Genau so ist - die Inject Node kannst wegschmeissen - die habe ich nur gebraucht - weil ich ja keinen MaxCube Adapter habe.

wenn der kleiner oder gleich 85 ist dann dürfen erst die setpoints gesetzt werden.

Nur wie kommt das OK des duty Cycle in den Hauptflow?

In diesem Fall wird die flow Variable dutyCycleOK auf true oder false gesetzt und dann unten in dem Flow abgefragt. Das ist nötig, da die Ereignisse ja nicht gleichzeitig an der selben Node ankommen.
Deswegen wird die flowVariable zeitlich unabhängig vom eigentlichen Flow gesetzt.

Dachte eigentlich weil der duty cycle check unabhängig vom restflow ist und quasi obendrüber gesetzt wird, sendet er ein okay in den flow, was dann unten abgefragt wird.

In der switch Node wird der Inhalt der flowVariablen abgefragt und dann der Flow entweder blockiert oder durchgelassen.

Das hab ich aber doch auch so geschildert.
Jetzt nicht mit fremden Federn schmücken, bitte

Die wichtigen Dinge markiere ich Dir immer farbig:

Du kannst Dir den Inhalt Deiner Kontextdaten wie folgt anschauen:

Im Kontextfenster siehst Du dann den Inhalt der Kontextvariablen - in diesem Fall der Flowvariable dutyCycleOK

hier musst Du aber immer manuell aktualisieren

[Marko1974]

@marko1974 said in MAX! Cube Blockly Abwesenheit:

@marko1974 said in MAX! Cube Blockly Abwesenheit:

@mickym said in MAX! Cube Blockly Abwesenheit:

@marko1974 sagte in MAX! Cube Blockly Abwesenheit:

@mickym

ach guck mal....der injectnode holt sich den dutycycle aus dem adapter, wenn der kleiner oder gleich 85 ist dann dürfen erst die setpoints gesetzt werden.
ist er größer setzt er dutycycle ok auf false und es wird gar nichts aus dem flow an die heizungen gesendet. Somit läuft das nicht über - und er macht nen Logeintrag. Das hast du ganz schön gewitzt gemacht. Darunter ist noch ne inject node die den payload angibt.

Super !!! - Genau so ist - die Inject Node kannst wegschmeissen - die habe ich nur gebraucht - weil ich ja keinen MaxCube Adapter habe.

wenn der kleiner oder gleich 85 ist dann dürfen erst die setpoints gesetzt werden.

Nur wie kommt das OK des duty Cycle in den Hauptflow?

In diesem Fall wird die flow Variable dutyCycleOK auf true oder false gesetzt und dann unten in dem Flow abgefragt. Das ist nötig, da die Ereignisse ja nicht gleichzeitig an der selben Node ankommen.
Deswegen wird die flowVariable zeitlich unabhängig vom eigentlichen Flow gesetzt.

Dachte eigentlich weil der duty cycle check unabhängig vom restflow ist und quasi obendrüber gesetzt wird, sendet er ein okay in den flow, was dann unten abgefragt wird.

In der switch Node wird der Inhalt der flowVariablen abgefragt und dann der Flow entweder blockiert oder durchgelassen.

Das hab ich aber doch auch so geschildert.
Jetzt nicht mit fremden Federn schmücken, bitte

Die wichtigen Dinge markiere ich Dir immer farbig:

Du kannst Dir den Inhalt Deiner Kontextdaten wie folgt anschauen:

Im Kontextfenster siehst Du dann den Inhalt der Kontextvariablen - in diesem Fall der Flowvariable dutyCycleOK

hier musst Du aber immer manuell aktualisieren

Das habe ich mir angesehen. Bestätigt mich irgendwie in der Aussage, dass diese flow dutyCycle irgendwo aus dem aktuellen flow geholt wird.
Die globale Heizungssteuerung ist ja auf global auch true

[mickym]

@marko1974 sagte in MAX! Cube Blockly Abwesenheit:

@marko1974 Ich glaube ich habe gerade helle Momente:

Der Trigger fragt ab ob die Heizungssteuerung aktiv ist. Da wollten wir eventuell noch was vorbauen, also ist die erstmal IMMER aktiv jetzt.

Korrekt. Man muss nicht mehr direkt was vorbauen, sondern kann ja mit einem weiteren Flow, der beispielsweise einen anderen Datenpunkt aus dem iobroker ausliest die globale Variable gHeizungssteuerung - die wie die dutyCycleOK funktioniert aber global über alle Flows gültig ist . Das heisst man kann diese Variable aus allen Flows später ansprechen - z.Bsp auch von einem Flow mit dem Du Wetterdaten auf einer ganz anderen Seite erstellst.

Dann erstellst Du die Räume Kinderzimmer, Schlafzimmer etc.

Na Du musst - sorry wenn ich das sage - versuche Dich präziser auszudrücken. Ich setze in jedem der Nachrichtenobjekte (msg) mach halt einfach eine Debug Node mit dem kompletten Nachrichtenobjekt hinter so eine Node:
Exakt muss es also heißen - ich definiere eine Eigenschaft rooms im Nachrichtenobjekt und setze in jeder Change Node den Wert dieser Eigenschaft:

Du siehst das Nachrichtenobjekt ist noch sehr klein:

mit topic setzen holt man sich quasi alle daten aus unseren erstellten DP in userdata0.heizung....keinen bestimmten, sondern alle. Nee die holt man sich nicht, sondern man setzt sie quasi als ein "Oberthema?" im nächsten Schritt in get mode im ioBroker in braucht man dann quasi nur nach mode zu fragen und muss den Datenpunkt nicht wählen, da man im Schritt davor quasi schon den Pfad bereitgestellt hat. So auch mit der Temperatur und auch der ecotemperatur

Genau . ich plaziere also mal die Debug Node hinter die msg.topic Node:

Da alle Change Nodes mit dieser 1. set topic Node verkabelt sind - kommen durch EINMALIGES Drücken der Inject Node 6 Nachrichten aufeinmal raus:

Der Topic - enthält nun also genau den Pfad zu dem Datenpunkt der ausgelesen werden soll.
Das geht über String Manipulation mit JSONATA - das auch sehr mächtige Funktionen enthält - wird uns auch später noch begegnen:

Die Stringszusammensetzung findet ja in dieser topic Node fest:

Das große J: - zu Beginn zeigt an, dass es sich hier um eine JSONATA Funktion handelt - diese hat wohl aus welchen Grunden bei Dir beim Import Probleme gemacht - das room enthält quasi den Inhalt der msg.room Eigenschaft die in den vorangegangenen Nodes gesetzt wurde.

Im nächsten Schritt setzen wir den Mode für jede Heizung der den Entweder unser Auto Profil sein kann, oder aber auch ECO, HEAT oder OFF. Off wird hier direkt eine Temperatur zugewiesen. Heat bekommt desiredTemperature als payload gesetzt und eco die eco_temperature.

Na alles viel zu flapsig und nicht exakt! - Also NEIN.

Auf zur nächsten Node - der 1. iobroker get Node.

Wenn Du Dir wieder die Hilfe zu dieser Node anschaust, dann siehst Du das die Node diese Datenpunkte abruft, die in msg.topic stehen und davon haben wir uns ja via Debug Node überzeugt, dass dem so ist.

Wichtig ist nun die Definition des Attributes.

Es gibt an in welche Eigenschaft des msg.Objektes der Inhalt des ausgelesenen Datenpunktes gespeichert wird.

Neben den Räumen gibt es dann die Heizungen.....warum die als Eigenschaft msg.room haben weiss ich noch nicht. Zumindest zählt man dann auf welche heizungen es gibt.

Kommt später

rbe hält was auf falls die alle unentwegt was senden. Entprellen sagtest Du ist was, dass es etwas verlangsamt wird, bevor es an den adapter punkt gesendet wird. Ob da nochmal ne Verzögerung rein muss darüber lässt sich streiten...und wenn dann noch der Duty cycle ok ist...als kleiner oder gleich 85 senden die Heizungen also der room an die DP direkt.

WIE WAR ICH?

Die beiden letzen Punkte in einem gesonderten Post.

Wenn Du die von mir deaktivierte Debug Node des gesamten Nachrichtenobjektes mal kurz aktivierst - siehst Du dass alle Minuten für alle 6 Räume Nachrichten mit allen Informationen der iobroker userdata Datenpunkte enthalten sind. Hier wird also der ECO Datenpunkt in der 3. iobroker getNode ausgelesen und dann in der Eigenschaft ecoTemperature des Nachrichtenobjektes gespeichert und durch den Flow geschickt.

Alle Minuten erhälst Du alle 6 Nachrichten mit allen Informationen aus den Userdatenpunkten.

Nun siehst Du auch wo die ECO Temperatur im Flow gespeichert wird. Ändere nun die ECO Temperatur im Datenpunkt und Du wirst sehen im nächsten Minutencyclus sind die Änderungen enthalten - probier es einfach aus.