Umstellung von Telnet auf MQTT

[TheChatty]

Es wäre schön, wenn SignalDuino per MQTT kommunizieren würden, so wie OpenMQTTGateway. Dann wäre man nicht an FHEM gebunden.

Konkret möchte ich Homebridge zum steuern meiner 433MHz-Aktoren verwenden, welche per mqttthing (Plugin mit sehr umfangreicher Geräteunterstützung) eingebunden werden sollen.

O.g. Projekt bietet aber bei weitem nicht die Protokollunterstützung von diesem Projekt an. Am besten wäre natürlich eine Zusammenarbeit der beiden Projekte.

Bis SignalDuino MQTT unterstützt verwende ich schlechtere Plugins als mqttthing, die die Ausführung eines Skripts erlauben. Darin setze ich per Netcat die raw messages an SignalDuino ab.

Die Nutzung von SignalDuino ohne Dekodermodul hat zwei Richtungen.

• RF-Signale senden: Man kann bereits jetzt per echo "SR;R=5;P0=5000;P1=-600;..." | nc sduino 23 eine rawMsg absetzen. Das würde relativ einfach auch per MQTT gehen.
• RF-Signale empfangen: Die empfangene rawMsg einer Fernbedienung unterscheidet sich bei jedem Tastendruck etwas voneinander. Ich frage mich, wieviel "Dekodierung" in den ESP-Teil verschoben werden kann, um hier zumindest eine Stabilisierung zu erreichen, dass MQTT sinnvoll wird?

Im Ergebnis könnte man dann einfache Schalter steuern und sogar die Signale weiterer Fernbedienungen berücksichtigen.

[Dattel]

Selbiges hätte ich mir in der Vergangenheit auch schon mal erhofft. Mein Signalduino ist auch die einzige Komponente, die derzeit jeglichen Blick über den FHEM-Tellerrand verhindert. Auf Hybridsysteme, bei denen dann nur für Signalduino eine FHEM Instanz für die Readings laufen muss würde ich nicht wollen.

Ich denke aber, dass es illusorisch ist, das gesamte Decoding der Protokolle (welches ja jetzt im FHEM läuft) in den Signalduino zu verlagern. D.h. du müsstest dir dann wahrscheinlich sowieso die RAW-Message als MQTT-Paket nehmen, das Protokoll selber verstehen und dann den Dekoder dafür schreiben...?

[sidey79]

Nunja, man könnte die Verarbeitung in einem eigenständigen Perlprogramm machen. Die Steuerung dessen müsste dann noch irgendwie in einem anderen Heimautomatisierungssystem etabliert werden. Prinzipiell alles möglich, leider aber auch Aufwand :(

[TheChatty]

Ich arbeite im Moment mit Homebridge. Vielleicht probiere ich mich mal an dem Projekt @sidey79. Im Idealfall würden dazu die unveränderten Quelldateien von dir zum Einsatz kommen zwecks Updates.

[TheChatty]

Was hältst du von der Idee, SignalDuino in Tasmota zu integrieren? Dann wäre die Umstellung auf MQTT implizit. Die Protokolldekodierung könnte man per Skript machen (bietet Tasmota bereits). Diese wäre natürlich individuell und würde nur die Codes der eigenen Geräte umfassen (Speicherplatz ist kostbar).

[sidey79]

Der Grundsatz dieses Projektes besteht darin, die Verarbeitung der Daten nicht im uC zu machen, sondern nur die demodulierung des Funksignales, da sonst ständig angepasste Firmware Stände. nötig sind.

Eine Integration in Tasmota ist für mich nicht möglich. MQTT wäre vergleichsweise einfach zu realisieren.

[SpaceTeddy]

Hallo alle, ich wäre ganz klar auch für mqtt. Habe viele Tasmotas im Einsatz und die laufen wirklich dauerhaft gut. Telnet ist bei mir etwas instabiel mit meinem SignalESP.

[git-developer]

Ich finde ebenfalls die Idee interessant, SIGNALduino ohne FHEM betreiben zu können. MQTT würde sich meiner Erfahrung nach hervorragend als Schnittstelle eignen. Natürlich ist es wünschenswert, die bisherige Implementierung weiterzuverwenden und auch zukünftig ohne Doppel-Implementierung auszukommen. Ich stelle mir das ungefähr so vor:

1. Die SIGNALduino-Firmware bleibt unverändert.
2. RFFHEM wird aufgeteilt: RFFHEM selbst enthält nur noch die FHEM-spezifischen Funktionen, ein neues Projekt (Arbeitsname "rfd-core") enthält die bestehende SIGNALduino-Logik.
   • Evtl. ist es auch möglich, RFFHEM völlig unverändert zu belassen (minimaler Aufwand), das kann ich nicht beurteilen.
3. rfd-core wird in ein neu zu implementierendes Perl-Programm (Arbeitsname "rfd-cli") eingebettet.
   • Das Programm rfd-cli ist die neue Laufzeitumgebung für rfd-core.
   • Es kann als eigenständiges Programm über die Kommandozeile gestartet werden.
   • Es verwendet bestehende Perl-Bibliotheken für MQTT.
   • Es fungiert als Adapter zwischen rfd-core und MQTT.
   • Es hat eine eigene Konfiguration (z.B. Kommandozeilen-Argumente oder eine YAML-Datei), in der die Angaben des heutigen Moduls RFFHEM und die MQTT-Konfiguration enthalten sind.
4. Optional kann für rfd-cli ein Docker-Image erstellt werden, das als Schnittstellen zur Außenwelt nur das USB-Gerät und einen MQTT-Broker kennt und alle notwendigen Perl-Abhängigkeiten mitbringt.

Wäre das so denkbar? Ergeben sich weitere Aufgaben?

Eine mit weniger Implementierungsaufwand verbundene Alternative wäre eine Art abgespecktes "Mini-FHEM", das die Aufgabe von rfd-cli übernimmt und nach außen nicht als FHEM zu erkennen ist. Es gibt ja inzwischen auch ein Docker-Image für FHEM. Allerdings hätte man damit eine Abhängigkeit auf FHEM, und ich bin mir nicht sicher, wie klein man dieses Mini-FHEM tatsächlich bekommen wird. Diese Variante halte ich deshalb eher für eine Notlösung.

[sidey79]

@git-developer

Prinzipiell ist das alles machbar. Der Aufwand ist aber nicht zu unterschätzen. Grundlegend, habe ich auf der Perl Seite durchaus schon manche Dinge von FHEM gelöst. Viele sind aber auch eng verbunden :(

Ursprünglich geht es in diesem Issue aber um die Verwendung von MQTT anstelle Telnet und damit ist meines Erachtens die Schnittstelle zwischen uC und FHEM gemeint. Das müsste man in jedem Fall in der Firmware implementieren, was vermutlich nur etwas Fleißarbeit ist, denn heute wird schon eine callback Funktion verwenden, welche das Senden der Daten über das Netzwerk realisiert. Dann würden diese Daten an einem beliebigen MQTT Server ankommen können. Beispielsweise im FHEM MQTT Server. Wie von dort dann die Weiterleitung an das Modul klappt müsste ich recherchieren. Wenn ich deine Grundidee hier richtig verstehe, würdest Du aber nicht FHEM als MQTT Gegenstelle sehen, sondern ein Programm rdf-core, welches die Demodulation aus de, Signalduino Modul übernimmt. Wie werden die Daten zwischen diesen Bausteinen übertragen?

[Dattel]

Ich bin raus. Mein signalduino wurde durch openmqttgateway ersetzt, welches für meine Zwecke ausreicht.

[git-developer]

Ursprünglich geht es in diesem Issue aber um die Verwendung von MQTT anstelle Telnet und damit ist meines Erachtens die Schnittstelle zwischen uC und FHEM gemeint.

Dann ist mein Beitrag an dieser Stelle eigentlich Off-Topic. Ich habe mich nicht auf die Kommunikation zwischen dem µC und dem Host-System bezogen. Für eine Entkopplung von SIGNALduino und FHEM ist nach meinem Verständnis auch das Wissen notwendig, das in den SIGNALduino-Client-Modulen steckt. Ich fände es ineffizient, wenn diese Implementierungen in jeder Smart-Home-Integrationsplattform erneut implementiert werden müssten. Und ich halte es für unrealistisch, dieses gesamte Wissen in den µC-Code zu überführen, zumal dieser dann häufig aktualisiert werden müsste. Folglich kam ich gedanklich zur Wiederverwendung des bestehenden Perl-Codes mit "rfd-core".

Wie werden die Daten zwischen diesen Bausteinen übertragen?

In meiner Vorstellung kann die Kommunikation zwischen dem µC und der Software auf dem Host unverändert bleiben, also USB (serielle Kommunikation). Das stellt für mich kein Problem dar und ist auch bei anderen Funk-Protokollen üblich (z.B. ZigBee, Z-Wave, Bluetooth, SDR).

Ich sehe inzwischen, dass man mit MQTT verschiedene Ziele verfolgen könnte:

1. Anbindung des SIGNALduino-µC an eine andere SmartHome-Plattform und Re-Implementierung der Client-Module (ursprünglicher Wunsch in diesem Issue)
2. Entkopplung der gesamten SIGNALduino-Implementierung (µC + Client-Module) von FHEM (meine Idee)

[TheChatty]

@git-developer: Ich stimme dir zu. Kommunikation zwischen µC und rfd-core bleibt unverändert, aber rfd-core wird durch die Unterstützung von MQTT offen für die Integration in beliebige SmartHome-Platformen.