MAX! Cube Blockly Abwesenheit

Marko1974

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.

mickym

@marko1974 sagte in MAX! Cube Blockly Abwesenheit:

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.

Nun ich bin ja noch lange nicht durch - wir stehen ja nun vor den Heizungen - kann ich das einfach mal durch erklären - ich WERDE DIR heute nämlich definitiv keinen neuen Flow schreiben.

Du musst ja auch nicht alles verstehen - aber vielleicht nimmst DU Dir diese Erklärung halt mehr als einmal vor und gehst das halt durch. Du siehst ja dass meine Postings ja auch einen ziemlichen Zeitaufwand für mich darstellen und diese Mühe mache ich mir nur, wenn ich auch nur den Hauch einer Chance sehe, dass sie morgen nicht wieder vergessen sind.

Marko1974

@mickym said in MAX! Cube Blockly Abwesenheit:

@marko1974 sagte in MAX! Cube Blockly Abwesenheit:

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.

Nun ich bin ja noch lange nicht durch - wir stehen ja nun vor den Heizungen - kann ich das einfach mal durch erklären - ich WERDE DIR heute nämlich definitiv keinen neuen Flow schreiben.

Na das sollst Du ja auch nicht! Um Gottes Willen.

Du musst ja auch nicht alles verstehen - aber vielleicht nimmst DU Dir diese Erklärung halt mehr als einmal vor und gehst das halt durch. Du siehst ja dass meine Postings ja auch einen ziemlichen Zeitaufwand für mich darstellen und diese Mühe mache ich mir nur, wenn ich auch nur den Hauch einer Chance sehe, dass sie morgen nicht wieder vergessen sind.

Ja das verstehe ich und das werde ich auch tun.

Eine Frage noch: Warum machst Du das?
Also denkst Du doch bestimmt bei mir gibts noch eine Chance, dass ich das demnächst hinbekomme?

mickym

@marko1974 sagte in MAX! Cube Blockly Abwesenheit:

Eine Frage noch: Warum machst Du das?
Also denkst Du doch bestimmt bei mir gibts noch eine Chance, dass ich das demnächst hinbekomme?

Ich werde Dir den ganzen Flow erklären auch wenn es mich noch einen Tag kostet.

Warum ich das mache - nun Du sollst als erstes mal erkennen, welche Genialität hinter NodeRed steckt. - aber das nur am Rande.
Ja ich gebe Dir eine Chance, aber so gerne ich helfe - wenn Du mal anschaust wievielen anderen ich geholfen habe, mache ich das nur, wenn die Leute es dann auch nutzen können. Wenn es Dir nur darum geht Lösungen - egal ob für die Miele Waschmaschine - oder Deine Shellies geht - oder eben Deiner Heizung geht - solltest Du in der Lage sein, so was selbst zu basteln.

Neben dem Tool - solltest Du aber auch einfach Ideen bekommen, wie man diese Dinge anpackt.

Was NodeRed so aussergewöhnlich macht - dass Du über diese Nodes und Kabel den Funktionsablauf siehst und Du wirst egal welches Problem Dir immer auch in der Hausautomation begegnet immer wie folgt vorgehen:

Links - du startes wie beim Lesen: die Trigger (Input Nodes, Iobroker IN Nodes, Alexa Nodes - was auch immer).
Mitte: Dann verarbeitest Du diese Informationen
Rechts: Du gibst Ergebnisse aus - an Datenpunkte in Deine Visualisierung, in Dateien, in Datenbanken, in Telegram, in was weiß ich.

Ich will das Du es verstehst und dann auch nicht mehr solche Vorschläge machst, ob Du mit Inject Nodes setpoints ausliest , was Du vorher vorgeschlagen hast.

Bitte ändere die Objekte der beiden Change Nodes noch in dem Du die korrespondierenden Thermostate in das JSON Objekt definierst und dann schau Dir an, was ich damit machen um effizient Deine telegram Ausgabe zu realisieren. Wenn Du auch wenn es komplex scheint - wird es Dir einfacher werden, wenn Du das Prinzip verstanden hast.

Und warum ich das mache - Du sollst nicht hilflos sein - und es wird vielleicht nicht so viele Leute geben - auch nicht hier an Board die überhaupt bereits sind den Flow nachzuvollziehen. Du siehst ja - der Flow musste ja von mir auch ein paar Mal angepasst werden bis er so lief, wer es jetzt tut.

Und ich möchte, dass Du selbstständig mit solchen Dingen umgehen kannst. Wir sind hier ein Forum, wo man sich gegenseitig hilft. Aber ich bin kein Implementierer und mach das auch nicht berufstätig und wenn Du hier bist, willst Du es ja auch selbst machen. Ansonsten kannst DU einen Hausautomatisierer beauftragen, da drückst Du dann ein paar Scheine ab und bei jeder Änderung darfst Du den wieder holen und er steckt sich weitere Scheine in die Tasche - und das wollen wir doch alle hier nicht. Wir wollen die Dinge doch selbst in die Hand nehmen, oder???

Marko1974

@mickym said in MAX! Cube Blockly Abwesenheit:

@marko1974 sagte in MAX! Cube Blockly Abwesenheit:

Eine Frage noch: Warum machst Du das?
Also denkst Du doch bestimmt bei mir gibts noch eine Chance, dass ich das demnächst hinbekomme?

Ich werde Dir den ganzen Flow erklären auch wenn es mich noch einen Tag kostet.

Warum ich das mache - nun Du sollst als erstes mal erkennen, welche Genialität hinter NodeRed steckt. - aber das nur am Rande.
Ja ich gebe Dir eine Chance, aber so gerne ich helfe - wenn Du mal anschaust wievielen anderen ich geholfen habe, mache ich das nur, wenn die Leute es dann auch nutzen können. Wenn es Dir nur darum geht Lösungen - egal ob für die Miele Waschmaschine - oder Deine Shellies geht - oder eben Deiner Heizung geht - solltest Du in der Lage sein, so was selbst zu basteln.

Neben dem Tool - solltest Du aber auch einfach Ideen bekommen, wie man diese Dinge anpackt.

Was NodeRed so aussergewöhnlich macht - dass Du über diese Nodes und Kabel den Funktionsablauf siehst und Du wirst egal welches Problem Dir immer auch in der Hausautomation begegnet immer wie folgt vorgehen:

Links - du startes wie beim Lesen: die Trigger (Input Nodes, Iobroker IN Nodes, Alexa Nodes - was auch immer).

Mitte: Dann verarbeitest Du diese Informationen

Rechts: Du gibst Ergebnisse aus - an Datenpunkte in Deine Visualisierung, in Dateien, in Datenbanken, in Telegram, in was weiß ich.

Ich will das Du es verstehst und dann auch nicht mehr solche Vorschläge machst, ob Du mit Inject Nodes setpoints ausliest , was Du vorher vorgeschlagen hast.

Bitte ändere die Objekte der beiden Change Nodes noch in dem Du die korrespondierenden Thermostate in das JSON Objekt definierst und dann schau Dir an, was ich damit machen um effizient Deine telegram Ausgabe zu realisieren. Wenn Du auch wenn es komplex scheint - wird es Dir einfacher werden, wenn Du das Prinzip verstanden hast.

Und warum ich das mache - Du sollst nicht hilflos sein - und es wird vielleicht nicht so viele Leute geben - auch nicht hier an Board die überhaupt bereits sind den Flow nachzuvollziehen. Du siehst ja - der Flow musste ja von mir auch ein paar Mal angepasst werden bis er so lief, wer es jetzt tut.

Und ich möchte, dass Du selbstständig mit solchen Dingen umgehen kannst. Wir sind hier ein Forum, wo man sich gegenseitig hilft. Aber ich bin kein Implementierer und mach das auch nicht berufstätig und wenn Du hier bist, willst Du es ja auch selbst machen. Ansonsten kannst DU einen Hausautomatisierer beauftragen, da drückst Du dann ein paar Scheine ab und bei jeder Änderung darfst Du den wieder holen und er steckt sich weitere Scheine in die Tasche - und das wollen wir doch alle hier nicht. Wir wollen die Dinge doch selbst in die Hand nehmen, oder???

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 Thema

mickym

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

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

Marko1974

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

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

NEWS

MAX! Cube Blockly Abwesenheit

Support us

529

32.4k

81.4k

1.3m