NEWS

@achim62 Bearbeite die Flow Datei. Dort würde ich alle Flows nacheinander rausholen und in nodered importieren. Dann kannst du weiter eingrenzen.

@DerPfanne Versuch einmal in den Instanzeinstellungen den Sicherheitsmodus zu aktivieren und damit die Ausführung deiner Fließ zu stoppen um wieder aufs UI zu kommen. Dann schau Mal ob du evtl. eine Endlosschleife gebaut hast, die zum Absturz führt.

MFG
CrunkFX

@stefande Starte mal in den Instanzeinstellungen den Sicherheitsmodus, damit werden alle Flows angehalten und du solltest wieder auf deine Oberfläche zugreifen können. Ich kenne das, wenn ich mal wieder aus Versehen eine Endlosschleife gebaut habe, dann passiert es gerne, dass die Oberfläche sich Tot Lädt.

MFG
CrunkFX

Wie fast immer, konnte ich es selber lösten, allerdings ist es mir ein Rätsel warum es nun wieder läuft.
Ich hatte ein Backup von gestern eingespielt und Node-Red danach auch 1.17.2 downgegradet (mit 2.0.0 kann ich keine Nodes wie Amazon nachinstallieren), die Amazon Hub Node nach installiert und wieder auf 2.0.0 upgedatet und nun ist der selbe Zustand wie vorher erreicht, allerdings verbindet der Port 80 wieder, warum auch immer.
f4c4facd-2a22-4202-8c16-5eae653c03ea-grafik.png

Es ist genauso wie @hallo-amt beschreibt Du musst natürlich Deine E-Mail Parameter richtig auch mit den entsprechenden Security Einstellungen einstellen.

msg.topic = Betreff der E-Mail
msg.payload = Text der Mail

Mit einem Inject Node also testen: String einstellen und Text ist dann msg.payload - Topic ist dann der Betreff.

@CrunkFX
Ich habe mal Dein Blockly Skript importiert und versucht in Node-Red umzusetzen:

[ { "id": "9f04b667.5cd998", "type": "tab", "label": "Flow 2", "disabled": false, "info": "" }, { "id": "3bcbf948.4c3446", "type": "ioBroker in", "z": "9f04b667.5cd998", "name": "", "topic": "0_userdata.0.dein_TH16_Temp_DP", "payloadType": "value", "onlyack": "", "func": "all", "gap": "", "x": 230, "y": 200, "wires": [ [ "9deba34c.8a806" ] ] }, { "id": "9deba34c.8a806", "type": "change", "z": "9f04b667.5cd998", "name": "to Number", "rules": [ { "t": "set", "p": "payload", "pt": "msg", "to": "$number(msg.payload)\t", "tot": "jsonata" } ], "action": "", "property": "", "from": "", "to": "", "reg": false, "x": 470, "y": 200, "wires": [ [ "79074a2f.e315f4", "79a6662f.b72558" ] ] }, { "id": "79074a2f.e315f4", "type": "change", "z": "9f04b667.5cd998", "name": "Level Oben + 0.2", "rules": [ { "t": "set", "p": "payload", "pt": "msg", "to": "payload + 0.2", "tot": "jsonata" }, { "t": "set", "p": "LevelOff", "pt": "flow", "to": "payload", "tot": "msg" } ], "action": "", "property": "", "from": "", "to": "", "reg": false, "x": 690, "y": 180, "wires": [ [] ] }, { "id": "79a6662f.b72558", "type": "change", "z": "9f04b667.5cd998", "name": "Level Unten - 0.2", "rules": [ { "t": "set", "p": "payload", "pt": "msg", "to": "payload - 0.2", "tot": "jsonata" }, { "t": "set", "p": "LevelOn", "pt": "flow", "to": "payload", "tot": "msg" } ], "action": "", "property": "", "from": "", "to": "", "reg": false, "x": 690, "y": 220, "wires": [ [] ] }, { "id": "a3f4a48c.5fbea8", "type": "inject", "z": "9f04b667.5cd998", "name": "", "topic": "Temperatur", "payload": "19", "payloadType": "str", "repeat": "", "crontab": "", "once": false, "onceDelay": 0.1, "x": 150, "y": 360, "wires": [ [ "200998b7.04c3e8" ] ] }, { "id": "200998b7.04c3e8", "type": "change", "z": "9f04b667.5cd998", "name": "to Number", "rules": [ { "t": "set", "p": "payload", "pt": "msg", "to": "$number(msg.payload)\t", "tot": "jsonata" } ], "action": "", "property": "", "from": "", "to": "", "reg": false, "x": 310, "y": 360, "wires": [ [ "60e1c1db.31561" ] ] }, { "id": "60e1c1db.31561", "type": "switch", "z": "9f04b667.5cd998", "name": "Schalte", "property": "payload", "propertyType": "msg", "rules": [ { "t": "gt", "v": "LevelOff", "vt": "flow" }, { "t": "lt", "v": "LevelOn", "vt": "flow" } ], "checkall": "true", "repair": false, "outputs": 2, "x": 460, "y": 360, "wires": [ [ "775acae7.a07974" ], [ "c65452e7.c57c8" ] ] }, { "id": "775acae7.a07974", "type": "change", "z": "9f04b667.5cd998", "name": "Ausschalten Off/False", "rules": [ { "t": "set", "p": "payload", "pt": "msg", "to": "false", "tot": "bool" } ], "action": "", "property": "", "from": "", "to": "", "reg": false, "x": 700, "y": 340, "wires": [ [ "184ff99a.c85ca6" ] ] }, { "id": "c65452e7.c57c8", "type": "change", "z": "9f04b667.5cd998", "name": "Einschalten On/true", "rules": [ { "t": "set", "p": "payload", "pt": "msg", "to": "true", "tot": "bool" } ], "action": "", "property": "", "from": "", "to": "", "reg": false, "x": 690, "y": 380, "wires": [ [ "184ff99a.c85ca6" ] ] }, { "id": "184ff99a.c85ca6", "type": "ioBroker out", "z": "9f04b667.5cd998", "name": "zur Steckdose", "topic": "", "ack": "false", "autoCreate": "false", "x": 980, "y": 360, "wires": [] } ]

Das sieht dann so aus:

screen.png

Und ich will niemand bekehren, aber doch vielleicht auch Alternativen aufzeigen.

Das wäre in meinen Augen das, was Du mit dem Blockly machst - ich habe mir das extra mal importiert. 😉

Ich persönlich mag dieses Flow basierende, da es gerade für Neulinge einfacher zu verstehen ist, was passiert wenn ....
Im Übrigen wird man eben auch gezwungen zu unterscheiden, was sind "Parameter" Flows oder dann "Schalter" Flows. Ich finde, dass man hier "erzogen" wird, die Probleme richtig zu strukturieren - deshalb bin ich halt ein kleiner Fan-Boy von Node-Red. Man möge mir das Nachsehen.

Statt dem Inject Node - für die Temperatur natürlich den Datenpunkt der Sonoff setzen und analog zu oben in Zahl konvertieren und natürlich den Datenpunkt zur Steckdose anpassen und ob True/False oder 0/1 oder On/Off gesetzt werden muss.

So hab nun entlich den fehler gefunden. durch das erstellen mehrer gleicher Images, wurde die Client ID im node red mit kopiert. aus diesen grund wurde nur der zuletzt aktualisierte Raspberry angesprochen.

@Homer-J

Ich hab die Lösung aus dem Thread auch benutzt. Funktioniert.

@Bluefox kann Du mit dem nächsten Update die Palette bitte wieder implementieren? ( für die User , die den Workaround noch nicht angewendet haben)

Lies mal die Hilfe zu dem Node:

Setting msg.enabled to false will disable the switch widget.

Das was Du machst, ist dass Du die Nodes komplett inaktiv machst - das hat aber nichts mit dem Interface zu tun.

Im Node Red Dashboard wirst Du also immer alle sehen. Du schickst an die Nodes (Switches), die Du inaktivieren willst eine msg.enabled mit einem Bool "false", zum aktivieren einen Bool "true".

Also einfach einen entsprechenden "Change" Node dazwischen klemmen.

Ich kanns auch nur immer wiederholen - der MQTT Adapter als Broker hat Probleme mit dem ACK.Flags.

https://forum.iobroker.net/topic/32143/mqtt-problem

Mit dem Haken geht das zwar - Du wirst nur Probleme bekommen, wenn Deine Werte von den Geräten nicht bestätigt werden bzw. wirst leicht Endlosschleifen produzieren. MIch hat dieses Problem echt Monate gekostet bis ich auf mosquitto umgestiegen bin und den Adapter nur als Client nutze, um die MQTT-Zustände weiter zu verarbeiten.

Habs gefunden :), beim IN für ioBroker muss Value als Command kommen 🙂

Hallo @smarthomegirl,

ich kann es nachvollziehen, dass man irgendwann resigniert wenn immer das Gleiche passiert. Auch ich hatte mit der Verbindung der Alexa und Node Red schon manche Probleme hinter mir. Auch dein spezielles Problem ist mir bekannt.
Ich habe dann folgendes getan und meistens funktionierte es danach wieder wunderbar:

Echo, Show und Dot vom Strom trennen. 30 Sekunden warten.

Nur Dot wieder Strom zuführen und Befehle ausprobieren.
Falls nicht gewünschter Effekt/ Ergebnis wieder da, betreffende Geräte löschen und am Dot "Suche Geräte" auslösen. Danach sollte alles funktionieren.

Die weiteren Geräte, wie Echo, Show, usw. zuschalten.

Wie gesagt, bei mir hat dies alles geholfen. Vielleicht ist es bei dir ein Versuch wert. Es ist eben blöd, dass Amazon ständig etwas verändert, aber manchmal ist es für uns ja von Vorteil.

Gr

PS: Wenn du noch hübsch bist 👱‍♀️ , bitte ich dich, spring nicht sondern lass uns kennen lernen. 💑 Spaß

Habe jetzt mal debugging eingeschaltet und bekomme die Meldung "State "node-red.0.system.adapter.admin.0.connected" does not exist in the ioBroker".

node-red sucht also nach einem state im node-red Zweig, der natürlich nicht existiert.

Das topic im node ist "system.adapter.admin.0.connected"

Den inbound-payload kann man in diesem Fall ignorieren.

Je nach dem ob man percentage oder bri verwendet - wenn dieser Wert > 0 ist, bedeutet das "Lampe ein", bzw. wenn dieser Wert gleich 0 ist, dann bedeutet das "Lampe aus". Es reicht meisten inbound-payload rauszufiltern und nur percentage oder bri als payload an die Lampe zu schicken.

@Hc-Yami
Wenn 3 Nodes übersichtlicher sind als eine, dann bleib ich bei einer und sehe gleich was los ist😉

Hallo,

Möglicherweise liegt es an den Berechtigungen, die das Plugin braucht.

Ich benutze diese "Palette": "node-red-contrib-local-alexa-devices"
...diese möchte Port 80 benutzen und braucht dafür erweiterte Berechtigungen, die der User "iobroker" erstmal nicht hat.

Variante 1: Fix Script laufen lassen
https://forum.iobroker.net/topic/20211/iobroker-installation-fixer-beta-verfügbar

curl -sL https://iobroker.net/fix.sh | bash -

Variante 2: iobroker service als User "root" laufen lassen

sudo service iobroker status
sudo nano /lib/systemd/system/iobroker.service

Unter [Service] :
User=root

ACHTUNG:
Es kann sein, dass deine vorhandenen "flows" damit "verschwinden", da sie an den User "iobroker" gebunden sind.
Dann erst alle flows exportieren und unter "root" wieder importieren.

PS:
Ggf. kann die "palette" auch per CLI wieder deinstalliert werden.

iobroker list adapters
iobroker list instances
iobroker del system.adapter.node-red.0
((ungetestet))

Hi, vielleicht habe ich die Frage auch falsch verstanden, was ist denn mit Alexa Gerät gemeint, ich dachte damit sei die Node gemeint, damit man den Status sieht. Oder ist damit ein Echo gemeint?

Habe es gefunden. Habe den Wert weitergegeben und nicht das Kommando. Danke.

@Seb_123 Danke, ja das wars.