UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Marc Berg]

@rewenode sagte in Node-RED Nodes für externe ioBroker Integration:

Da wünschte ich mir die Möglichkeit, ein arrayOfStates angeben zu können. Ich kann aber auf die Schnelle auch nicht überblicken, wie aufwendig das wäre.

Ja, kann ich verstehen. Die Umsetzung stelle ich mir gerade ziemlich fehleranfällig vor, und das werde ich (bevor ich ganz sicher bin, dass der Rest ~100% funktioniert) eher nicht angehen. Aber mit der "append" Option kann man den Chart Node auch gut mit mehreren Datenreihen beschicken:

[rewenode]

@marc-berg sagte in Node-RED Nodes für externe ioBroker Integration:

Aber mit der "append" Option kann man den Chart Node auch gut mit mehreren Datenreihen beschicken:

Da hast du recht, das tut es auch.

[Marc Berg]

@rewenode sagte in Node-RED Nodes für externe ioBroker Integration:

Das gilt eigentlich generell für das Abonnieren von states. Machmal sind da standard-wildcards für mich zu unflexibel. Bisher filtere ich mir dann die Daten im Nachgang oder (im Fall meiner eigenen WS-function-node) verwende gleich ein arrayOfStates für die zu abonnierenden states.

Das sähe dann so aus:

Man kann eine Reihe States abonnieren und entscheiden, ob man nur den jeweils geänderten State als Message wie bisher haben möchte oder gebündelt wie im Bild mit allen States sowie dem "Auslöser". Wenn sich aber in kurzer Zeit alle Werte ändern, bekommt man das Bündel x mal. Bin mir noch nicht sicher, ob das gut ist.

[rewenode]

@marc-berg sagte in Node-RED Nodes für externe ioBroker Integration:

@rewenode sagte in Node-RED Nodes für externe ioBroker Integration:

Das gilt eigentlich generell für das Abonnieren von states. Machmal sind da standard-wildcards für mich zu unflexibel. Bisher filtere ich mir dann die Daten im Nachgang oder (im Fall meiner eigenen WS-function-node) verwende gleich ein arrayOfStates für die zu abonnierenden states.

Das sähe dann so aus:

Man kann eine Reihe States abonnieren und entscheiden, ob man nur den jeweils geänderten State als Message wie bisher haben möchte oder gebündelt... Bin mir noch nicht sicher, ob das gut ist.

Das ist genial. Gebündelt ist nicht nötig und sicher nicht sinnvoll aus den schon von dir genannten Gründen. Es sei denn, man will das explizit so haben.
Es mag Fälle geben wo das hilfreich wäre. z.B. Wenn man zu einem State immer einen 2ten(oder mehrere) braucht, weil mann beide in der Weiterverarbeitung vergleichen/auswerten muss. Da habe bisher meist nach dem Empfang einer Änderung einen get für den 2ten state ausgelöst oder mir die Änderungen gespeichert. Bei solchen Sonderfällen ist das sicher hilfreich, weil es eine ganze Menge Aufwand sparen kann.
Mach so wie du denkst und es für dich keinen extremen Aufwand bedeutet.

[Marc Berg]

@rewenode sagte in Node-RED Nodes für externe ioBroker Integration:

Da habe bisher meist nach dem Empfang einer Änderung einen get für den 2ten state ausgelöst oder mir die Änderungen gespeichert. Bei solchen Sonderfällen ist das sicher hilfreich, weil es eine ganze Menge Aufwand sparen kan

Genau das. Da es auch bei mir den einen oder anderen Flow vereinfachen wird, werde ich es drin lassen.

[Marc Berg]

@marc-berg sagte in Node-RED Nodes für externe ioBroker Integration:

Das sähe dann so aus

:arrow_right: v0.9.5

EDIT: noch Ideen für weitere Nodes oder Erweiterungen/Verbesserungen? Mir fällt nichts mehr ein, was sich nicht mit Node-RED Standardmitteln lösen ließe.

[peterfido]

@marc-berg Vielleicht eine Option, das Node-Red oder den Rechner darunter neu zu starten.

[rewenode]

@marc-berg sagte in Node-RED Nodes für externe ioBroker Integration:

v0.9.5

Da bin ich echt platt:+1: Läuft wie geschmiert bis jetzt.
Ich werde die Tage beginnen meine Flows nacheinander umzustellen. Da wird bestimmt noch das ein oder andere auftauchen.

@Marc-Berg Hast du mal getestet, ob deine contrib-iobroker auch unter dem iob-node-red Adapter läuft? Das würde die Umstellung der Flows vereinfachen, weil ich dabei nicht mit 2 Systemen hantieren müßte. Habe im Moment kein Testsystem zur Hand, sonst würde ich das selbst testen.
Ich dachte daran, jeweils den original-Flow zu adaptieren und dann zu deaktivieren. Dann kann der neue Flow einige Zeit laufen und beobachtet werden, wobei ich (falls nötig) per Knopfdruck wieder auf den alten Flow wechseln könnte.

Deine notes sind wirklich exzellent dokumentiert. Macht echt Spass, damit zu experimentieren.

@marc-berg sagte in Node-RED Nodes für externe ioBroker Integration:

Mir fällt nichts mehr ein, was sich nicht mit Node-RED Standardmitteln lösen ließe.

Ja, das stimmt schon, aber mit so komfortablen nodes ist es entschieden angenehmer :grinning:

[Marc Berg]

@peterfido sagte in Node-RED Nodes für externe ioBroker Integration:

Vielleicht eine Option, das Node-Red oder den Rechner darunter neu zu starten.

Das ist sehr systemspezifisch und kann (unter Aushebelung einiger Sicherheitsvorkehrungen) mit dem exec Node erledigt werden. Es braucht je nach System (Linux/Windows/Container) völlig unterschiedliche Herangehensweisen. Da es mit ioBroker auch nicht direkt etwas zu tun hat, würde ich es nicht integrieren.

[Marc Berg]

@rewenode sagte in Node-RED Nodes für externe ioBroker Integration:

@Marc-Berg Hast du mal getestet, ob deine contrib-iobroker auch unter dem iob-node-red Adapter läuft?

Ja, das geht. Etwas unschön ist im Moment, dass dann beide Nodes in der Palette in einer Kategorie vermischt sind und man etwas genauer hinschauen muss. In der nächsten Version bekommen sie eine eigene Kategorie.

Ich dachte daran, jeweils den original-Flow zu adaptieren und dann zu deaktivieren. Dann kann der neue Flow einige Zeit laufen und beobachtet werden, wobei ich (falls nötig) per Knopfdruck wieder auf den alten Flow wechseln könnte.

So ähnlich mache ich das auch. Schritt für Schritt umstellen, exportieren und in ein eigenes Node-RED importieren.

Deine notes sind wirklich exzellent dokumentiert. Macht echt Spass, damit zu experimentieren.

Da hilft natürlich die KI. Den Output muss man dann aber in jedem Fall editieren, denn gern wird da halluziniert und nicht vorhandene Funktionen dazuerfunden. :-)

[MartyBr]

@marc-berg
Ich habe Node-Red auf meiner Synology als Docker installiert und auch die Nodes dort installiert.
Nun habe ich eine Frage zu Node-Red im allgemeinen. Bei Node-Red innerhalb vom ioBroker konnte man unter Einstellungen den Speicherbedarf/Nutzung einstellen. Ist das auf einen eigenen Node-Red Docker nötig oder nimmt sich hier Node-Red einfach den verfügbaren Speicher?

[Marc Berg]

@martybr sagte in Node-RED Nodes für externe ioBroker Integration:

Ist das auf einen eigenen Node-Red Docker nötig oder nimmt sich hier Node-Red einfach den verfügbaren Speicher?

Im Default nimmt sich Node-RED alles was es bekommen kann. Begrenzen kann man es über die Umgebungsvariable

NODE_OPTIONS

Musst du mal googlen, die genauen parameter habe ich nicht parat.

[rewenode]

@marc-berg sagte in Node-RED Nodes für externe ioBroker Integration:

Da hilft natürlich die KI. Den Output muss man dann aber in jedem Fall editieren, denn gern wird da halluziniert und nicht vorhandene Funktionen dazuerfunden.

Na zu irgendwas muss die ja nützlich sein:grin:
Im Ernst, ich setze auch gerne KI für meine kleinen Projekte ein.
Habe mir vor einiger Zeit einen Mac-Kurzbefehl geschrieben, der mir meine Flows an Hand des Flow-Export dokumentiert.
Purzelt sowas dann raus.

Lediglich den Screen-shot füge ich hier von Hand ein. Im Prompt kann ich noch einstellen, wie detailliert ich die Erklärung haben will.

@marc-berg sagte in Node-RED Nodes für externe ioBroker Integration:

In der nächsten Version bekommen sie eine eigene Kategorie.

Will vorher sowieso noch einige Experimente machen.

@Marc-Berg Gibt es irgendwie die Möglichkeit bei einem State Abo/Get optional die Objektdaten der ID dazu zu bekommen? Bisher habe ich da immer den ioB-List hinterhergeschaltet um letztlich an die Objectdaten (Name/Enums etc) zu kommen.

[Marc Berg]

@rewenode sagte in Node-RED Nodes für externe ioBroker Integration:

Gibt es irgendwie die Möglichkeit bei einem State Abo/Get optional die Objektdaten der ID dazu zu bekommen? B

Müsstest du jetzt ähnlich machen. Beim einfachen "in" oder "get" frage ich keine Objektdaten ab.

[MartyBr]

@marc-berg
Danke für die Antwort. Da es ja ein Docker für Node-Red ist, kann sich Node-Red hier aus dem vollem bedienen.
:+1:

[rewenode]

@marc-berg sagte in Node-RED Nodes für externe ioBroker Integration:

Müsstest du jetzt ähnlich machen. Beim einfachen "in" oder "get" frage ich keine Objektdaten ab.

Ja, das tut es genau so gut.

[Marc Berg]

@martybr sagte in Node-RED Nodes für externe ioBroker Integration:

kann sich Node-Red hier aus dem vollem bedienen.

Naja, ein Auge sollte man trotzdem darauf haben. Angenommen, man begrenzt den Container selbst (hier im Beispiel 512MB), dann muss man auch Node-RED (bzw. Node.js) begrenzen (hier 400MB), damit der Container im Extremfall nicht gekillt wird.

services:
  node-red:
    image: nodered/node-red
    mem_limit: 512m                    # Docker Limit: 512MB
    environment:
      - NODE_OPTIONS=--max-old-space-size=400 

[MartyBr]

@marc-berg
Okay, werde ich dann so umsetzen.

Edit: Wird diese Einstellung im compose.yaml eingetragen?

Edit 2:
Ja, wird in der Compose.yaml eingetragen.

[rewenode]

@marc-berg Bin grad dabei etwas intensiver zu testen.
Sag mal, gibt es irgendeine Möglichkeit an die ENUMS eines Objects zu kommen?
Da sind ja üblicherweise die Räume/Batteriebetrieben usw hinterlegt.
Bei den alten Nodes gibt es zumindest die ioB-List-node, die zum Objekt die ENUMS mit auswirft. Ideal wäre, wenn die ENUM zum getObj mit ausgeben würden.

[Marc Berg]

@rewenode sagte in Node-RED Nodes für externe ioBroker Integration:

Ideal wäre, wenn die ENUM zum getObj mit ausgeben würden.

So ist das, wenn man Funktionen nicht selbst braucht und einsetzt ...

Ich werde die Ausgabe der Enums optional machen und so in das Objekt einbetten:

{
	"type": "channel",
	"common": {
		"name": {
			"en": "AZThermostat"
		},
		"role": "thermostat"
	},
	"_id": "alias.0.Haus.Arbeitszimmer.AZThermostat",
	"native": {},
	"acl": {
		"object": 1636,
		"owner": "system.user.admin",
		"ownerGroup": "system.group.administrator"
	},
	"from": "system.adapter.admin.0",
	"user": "system.user.admin",
	"ts": 1692695747121,
	"enumAssignments": {
		"rooms": [
			{
				"id": "enum.rooms.Arbeitszimmer",
				"name": "Arbeitszimmer",
				"type": "rooms",
				"members": [
					"alias.0.Haus.Arbeitszimmer.AZThermostat",
					"alias.0.Haus.Arbeitszimmer.BlindAZ1",
					"alias.0.Haus.Arbeitszimmer.BlindAZ2"
				]
			}
		],
		"functions": [],
		"other": []
	}
}

Außerdem ist es dann wohl auch eine gute Idee, die Enums separat suchen und filtern zu können.