MAX! Cube Blockly Abwesenheit

[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.

[mickym]

@marko1974 sagte in MAX! Cube Blockly Abwesenheit:

@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

Sorry - darauf gehe ich nun nicht ein. Ich habe es exakt erklärt.

Die switch Node prüft den Wert des Duty Cycles und leitet das NAchrichtenobjekt je nach Wert des DutyCycles an den oberen oder untern Ausgang. Ist der DutyCycle über 85 wird die flow Variable mit der anschließenden Change Node auf false (unten) oder true (oben) gesetzt. Ist der dutyCycle über 85 bekommst Du nun eine Warnung im iobroker Log.

[mickym]

@marko1974 sagte in MAX! Cube Blockly Abwesenheit:

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

Hier bist Du wieder mal in den Alexa Flow gesprungen - wie gesagt - ich glaube echt, dass Du im Reallife arge Schwierigkeiten hast Dich auf eine Sache zu konzentrieren - aber so bist Du halt.

Also zum AlexFlow:

Du hast selbst unten zu Beginn, wo wir Deine neue ALexa Node ausprobiert haben die Nachrichtenobjekte angeschaut.
Die Alexa Nodes ist auf Passthrough eingestellt. Da wir ja den Status der Thermostate aus dem MAXCube Adapter holen und in der AlexaNode passthrough eingestellt haben, kommen die Nachrichtenobjekte so wie wir sind in die Alexa Node geschickt haben auch hinten wieder raus. Um Endlosschleifen zu vermeiden - sprich wenn wir die Alexa Node mit dem setpoint Datenpunktwert (also der aktuell eingestellten Temperatur füttern), dann dürfen wir den ja hinten nicht wieder setzen, sonst kommt er ja von links gleich wieder an und Dein Flow hat eine Endlosschleife. Dann wirst Du nicht mehr auf die Oberfläche Deinen iobroker kommen und musst dann den NodeRed Adapter gewaltsam über die Kommandozeile beenden.
Wir wollen also nur Nachrichtenobjekte aus der Alexa Node durchlassen, die von Alexa selbst kommen und nicht die, die wir geschickt haben, um Alexa bzw. die App mit dem aktuellen Status zu versorgen.

Also lassen wir mit Quelle= nur Nachrichten durch in dem wir die source Eigenschaft des payload Objektes prüfen und schauen, ob da "alexa" drin steht. Das passiert nur, wenn die Node von Alexa und nicht von unserem Flow gefüttert wurde.

Hier hilft also die Hilfe anzuschauen.

Also die Quelle? - Switch Node hat die äußerst wichtige Aufgabe - nur Nachrichtenobjekte durchzulassen, die von Alexa stammen, sonst hätten wir Endlosschleifen.

Die Was ist zu tun switch Node - ist ebenfalls sehr wichtig:

Sie analysiert die Eigenschaft der directive des payload Objects des msg Objects, die von Alexa ausgefüllt wird - deswegen habe ich Dich ja die Kommandos sprechen lassen und Du musstest mir hier den Output posten:

Wenn Du mit Alexa einen Wert setzt wird die directive Eigenschaft auf "SetTargetTemperature" gesetzt, wenn Du wärmer oder kälter sagst wird AdjustTemperature als directive gesetzt. In diesem Fall wird die aktuell gesetzte Temperatur von Alexa um 1 Grad kälter oder wärmer gemacht in dem die Eigenschaft targetTemperature angepasst wird.
Die beiden Direktiven werden an den 1. und 2. Ausgang geschickt, da über targetTemperature direkt die setpoints der Thermostaten eingestellt werden.

Die untere directive SetThermostateMode lenkt das Nachrichtenobjekt an den 3. Ausgang und wird an den mode Datenpunkt unter 0_userdata.0.heizung.mode geschickt. Diese Änderung wird ja durch den anderen Trigger mit dem nächsten Minutenzyklus verarbeitet.

[Marko1974]

@mickym said in MAX! Cube Blockly Abwesenheit:

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

Ja das verstehe ich.

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:

Ja stimmt mit dem exakt ausdrücken....mir fehlen da die Fachbegriffe für node-red....daher hab ich das grob in normaler sprache umschrieben.

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:

Hab ich irgendwie auch verstanden.

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.

Ja aber da muss man immer jede Menge im Hinterkopf behalten....ist ja auch n ziemlich umfangreicher flow.

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.

Das hab ich auch verstanden.

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.

Stimmt die hatte ich ja schon geändert und habs jetzt nochmal probiert. die ändert er.
Wunderbar! Auch ganz tolle Erklärung. Nachbauen könnte ich es trotzdem nicht. Es ist einfach zu umfangreich.
Ich muuss mit Fenster offen und zu wie in Blockly anfangen und mich langsam entlanghangeln.

Man könnte ja mal probieren alle Blocklys die ich habe probieren in Node red nachzubauen. Die sind nicht gross.
Aber dieses Heizungsding ist einfach zu gewaltig. Da muss man sich schon sehr gut auskennen.
Das ist so als ob ich Englisch lerne und Du kommst nicht mit Peter, Paul and Mary sondern direkt mit Romeo und Julia um die Ecke.
Einfach too much auf einmal.