Node-Red als Frontend

[Master_Nick]

  Ich bin aktiv dabei mir den besten Ansatz zu suchen.
Ich überlege aktuell FHEM alles was an Aktionen (Schaltaktionen, Temperaturen, etc) rein kommt über MQTT an Node-Red weiter zu geben und dann dort zu anzuzeigen.
Eine direkte Schnittstelle scheint es nicht zu geben, von daher ist das bisher der einzige Weg der mir offen erscheint.

Ansonsten leider noch nicht viel - generell habe ich mein 10" Touchpanel schon fertig gestellt und kämpfe aktuell noch stark mit anderen Problemen die mich ablenken da sie in die aktuelle Nutzung einstreuen. (FHEM -> FCM -> andFHEM -> Widgets bleiben einfach wie sie sind statt Schaltzustände korrekt wiederzugeben - Da bin ich in regem Kontakt mit dem Entwickler)

Aber der Urlaub kommt. Und wenn ich die ersten Punkte gekaut und geschluckt habe wird es denke ich auch nicht mehr wie ein Berg aussehen.

Kurz um verzögert aber nicht begraben

[TWART016]

Eventuell hilft das
https://www.youtube.com/watch?v=AGn_QfPmk-g

[Master_Nick]

Definitiv nicht falsch denke ich.
Man muss das Rad ja nicht immer neu erfinden.

Danke dir!

[hexenmeister]

Eventuell hilft das
https://www.youtube.com/watch?v=AGn_QfPmk-g

Interessanter Ansatz. Bring mich auf eine Idee Warum nicht gleich ein Device entwickeln, das diese ganze Scripterei in sich vereint und mqtt-Pub/Sub-Funktionalität für alle Geräte zur Verfügung stellt
Die Definitionen könnte in etwa so aussehen:

Code Auswählen Erweitern

defmod mqttBridge MQTT_GENERIC_BRIDGE
attr mqttBridge mqttTopicPrefix /haus/

defmod sensorXYZ bla
...
attr sensorXYZ mqttTopic sensorXYZ
attr sensorXYZ mqttPubNames temperature humidity
...

defmod rolloX blup
...
attr rolloX mqttTopic rolloX
attr rolloX mqttPubNames pct:position state
attr rolloX mqttSubNames set:pct
...


wobei mqttBridge das Gerät wäre, das alles andere intern verwaltet.
Für sensorXYZ würden dann Readings temperature und humidity als /haus/sensorXYZ/temperature bzw. /haus/sensorXYZ/humidity gepublished.
Für rolloX würde die Position und State gepublished (Reading pct als /haus/rolloX/position und state als /haus/rolloX/state) und zusätzlich würde Topic /haus/rolloX/set aboniert und dessen Inhalte per "set rolloX pct VALUE" gesetzt.

Das würde mir meine Konfiguration an vielen Stellen vereinfachen. Vlt. realisiere ich das mal
Wie findet ihr die Idee?

[Master_Nick]

Ich denke das wäre ein Träumchen! Super Idee! Man könnte es fast als Schnittstelle verstehen.

Interessanter Ansatz. Bring mich auf eine Idee Warum nicht gleich ein Device entwickeln, das diese ganze Scripterei in sich vereint und mqtt-Pub/Sub-Funktionalität für alle Geräte zur Verfügung stellt
Die Definitionen könnte in etwa so aussehen:

Code Auswählen Erweitern

defmod mqttBridge MQTT_GENERIC_BRIDGE
attr mqttBridge mqttTopicPrefix /haus/

defmod sensorXYZ bla
...
attr sensorXYZ mqttTopic sensorXYZ
attr sensorXYZ mqttPubNames temperature humidity
...

defmod rolloX blup
...
attr rolloX mqttTopic rolloX
attr rolloX mqttPubNames pct:position state
attr rolloX mqttSubNames set:pct
...


wobei mqttBridge das Gerät wäre, das alles andere intern verwaltet.
Für sensorXYZ würden dann Readings temperature und humidity als /haus/sensorXYZ/temperature bzw. /haus/sensorXYZ/humidity gepublished.
Für rolloX würde die Position und State gepublished (Reading pct als /haus/rolloX/position und state als /haus/rolloX/state) und zusätzlich würde Topic /haus/rolloX/set aboniert und dessen Inhalte per "set rolloX pct VALUE" gesetzt.

Das würde mir meine Konfiguration an vielen Stellen vereinfachen. Vlt. realisiere ich das mal
Wie findet ihr die Idee?

[hexenmeister]

Habe eine erste teil-funktioniernde Version (nur publish, keine subscribe). Bin mir aber noch nicht sicher, wie (Format) ich die KonfigurationsAttribute haben will. Ich werde die Tage ein neuen Thread dafür eröffnen, hier sind wir schon sehr OT.

[Absolute Beginner]

Hochinteressantes Thema! Habe Node-RED als Frontend zu FHEM im Test, nutze ausschließlich MQTT als Interface. Läuft prima und ich wundere mich, warum hier im Forum so wenig über Node-RED steht. Nur leider ist die Einrichtung aller Instanzen über die MQTT-Bridge ziemlich aufwändig. Am ioBroker habe ich mich auch schon versucht - der hat sehr wohl einige Vorteile, mir ist er aber zu 'unhandlich' (dito für Openhab2). Deshalb würde ich mich sehr über eine generische Bridge freuen. Devices mit FHEM einrichten ist einfach und gut! Bei dieser Gelegenheit gefragt: FHEM und Node-RED auf einem Rpi3 - läuft das gut zusammen? Gibt es etwas zu beachten?

[hexenmeister]

Bei mir laufen 3 FHEM Instanzen plus Node-Red auf einem Rpi3 zusammen. Sprechen munter miteinander über mosquitto, das wiederum auf einem Cubietruck (zusammen mit einer weiteren FHEM Instanz) installiert ist.
Keine Probleme.

[Absolute Beginner]

Und wenn der Broker (Mosquitto) auch auf dem einen RPi läuft? Bisher habe ich Node-RED auf einem PC zum Testen laufen.

[hexenmeister]

Wird auch kein Problem sein. Mosquitto braucht nicht viel.

[Shojo]

Habe eine erste teil-funktioniernde Version (nur publish, keine subscribe). Bin mir aber noch nicht sicher, wie (Format) ich die KonfigurationsAttribute haben will. Ich werde die Tage ein neuen Thread dafür eröffnen, hier sind wir schon sehr OT.

Hast Du da schon was zu testen   

[hexenmeister]

Habe ich. Versuche morgen bereit zu stellen. Sorry, gerade zeitlich sehr knapp.

[Shojo]

Habe ich. Versuche morgen bereit zu stellen. Sorry, gerade zeitlich sehr knapp.

Bloß kein Stress
Bin aber gespannt! 

[hexenmeister]

Bin aber gespannt!

Wie angedroht hier ist das in einem neuen Thread: https://forum.fhem.de/index.php?topic=81418.new#new

[Darrol]

Habe heute mein TabletUI durch die MQTT/NodeRed-Dashboardlösung ersetzt und bin begeistert.
Die größte Herausforderung war lediglich den Output von der Log-Datenbank für die Charts aufzubereiten.
Der Rest ging quasi im Handumdrehen.
Das Dashboard lädt schnell und reagiert praktisch ohne erkennbare Verzögerung.
Bei mir laufen Fhem, postgres, Mosquitto und Node-RED auf einer Intel-NUC in Containern.

Allerdings muss ich sagen, dass die TabletUI von Fhem sehr viel umfangreicher und teilweise auch hübscher ist als das Node-Red-Dashboard. Leider ist mir da aber die Einrichtung zu frickelig und die Performance auch nur so lala.
Für mich ist damit der größte Knackpunkt von Fhem, nämlich das fehlende, saubere und flotte  Anwender-Frontend, behoben bzw. umschifft.