SIGNALESP als Somfy-Gateway?

[rgr101]

Hi,
mit Interesse bin ich auf SIGNALESP gestoßen.
Um es kurz zu machen: Ich suche eine komfortablere Möglichkeit der Steuerung meiner 23 SOMFY RTS Motoren (aktuell steuere ich sie auf 5 Gruppenkanälen mit einer gehackten Telis-4 FB + Arduino an). Nach einigen ernüchternden Versuchen mit „üblichen“ 433 MHz China-Sendern (Reichweite!!) möchte ich einer robusten und leistungsfähigen Basis sicher sein.

SIGNALESP sieht mir da in Verbindung mit dem CC1101 sehr viel versprechend aus;
ggfs. wäre gar ein noch stärkerer Sender (SX1278 LoRa ?) als Garant für eine stabile Funkstrecke wünschenswert…?!?

Ich verstehe mich eher als Power-User mit „moderaten“ Programmierfähigkeiten (RF bzw. HF und bit banging ist nicht so mein Ding…) d.h. am liebsten würde ich auf eine robust funktionierende Basis aufsetzen, als Ziel schwebt mir ein "Somfy-Gateway" mit einer einfachen, offenen Schnittstelle vor...

Kann mich jemand bei der Realisierung unterstützen? Sicherlich an dieser Stelle etwas OT -> Kontakt daher sehr gern auch über PN (rgr101 ät online punkt de) :)

Danke & LG
Renato

[sidey79]

Der SIGNALESP zählt leider noch nicht zu einer stabilen Basis die Du suchst.

[rgr101]

Schade, dabei hörte sich das so gut an :) - woran liegt's?

Gerade hab ich beim freundlichen Chinesen ein nettes Board gefunden, das ich mir als ideale Hardwarebasis vorstellen könnte (außer, dass es den ESP32 wohl hoffnungslos unterfordern wird...):

https://de.aliexpress.com/store/product/SX1278-ESP32-LoRa-0-96-Inch-Blue-OLED-Display-Bluetooth-WIFI-Lora-Kit-32-Module-IOT/606998_32825749403.html

[sidey79]

Das Problem ist aktuell noch, dass die Netzwerkbibliothek Verzögerungen von 200 MS einbringt.

Ich weiss, dass an der Bibliothek, welche ich verwende, gearbeitet wurde, um das zu umgehen.
Ich habe es mit der Korrektur bislang nicht verifiziert.

Ansonsten sind in diesem Repo eine ältere, leider fehlerbehaftet ,Version der Mustererkennung.
Da ich gerade am Anpassen bin, mache ich das erst mal für den Signalduino fertig

[rgr101]

Ah, langsam beginne ich zu verstehen (nachdem ich etwas tiefer in den Code geschaut habe ;)) -> Die Architektur ist so, dass die gesamte Protokollaufbereitung im RFFHEM Modul vorgenommen wird, d.h. auf dem FHEM Server abläuft, und SIGNALduino nur für die reine Übertragung des Datenstroms zuständig ist, richtig?

Damit wird mir auch klar, dass das bei einer Wifi-Verbindung zu Problemen führt bzw. wahrscheinlich IMMER führen wird: Selbst sich wenn der 200ms lag innerhalb der Netzwerkbibliothek eines Tages reduziert lassen sollte, wird es in einem Heimnetz immer noch unendlich viele potentielle Gründe geben, warum ein Datenpaket nicht unmittelbar ankommt... - will sagen, das wird bei dieser Architektur immer eine Achillesferse bleiben ;) )

=> Mir ist bewusst, dass das was ich jetzt sage, deinen Architekturansatz komplett auf den Kopf stellt und dir dem entsprechend gar nicht gefallen kann... - sorry im Voraus ;) ->

Meines Erachtens muss die Protokollaufbereitung grundsätzlich möglichst "nahe" am RF Modul passieren, d.h. in diesem Fall direkt im ESP, damit man die beste Chance bekommt, das Timing zumindest einigermaßen im Griff zu behalten (Eigentlich ist das ja ein Echtzeitthema...!)
Beim Signalduino mag das noch einigermaßen unkritisch sein, da der Nano direkt über USB an FHEM hängt, aber wie gesagt, mit einer "Luftstrecke" dazwischen und dann auch noch mit IP Protokolloverhead etc. kommen mir da zu viele und unkalkulierbare Störfaktoren ins Spiel...

Die Schnittstelle nach "außen" wird dann auf einer höheren Ebene wesentlich einfacher; zB. beim Senden (metasprachlich ausgedrückt:) "Somfy RTS Rolladen Kanal 1 auf" oder "Intertechno Steckdose 17 an" - und der ESP wüsste durch entsprechende vorherige Konfig (entweder über eine API oder per config-file/microSD), welches Gerät gemeint ist, und welches Protokoll dafür zu verwenden ist... Beim Empfangen könnte man überlegen, die aktuelle Logik beizubehalten (also Rückgabe des uninterpretierten Datenstroms an FHEM und Dekodierung dort), oder der ESP übernimmt diese Aufgabe (Vorteil: Man müsste die Muster/Protokolle nur an einer Stelle pflegen) und gibt entsprechend "sprechende" Ergebnisse zurück. Selbst bei unerkannten bzw. fremden Geräten könnte der ESP ein Ergebnis zurückspielen, da er ja in den meisten Fällen zumindest das Protokoll erkennen und den Inhalt interpretieren kann, und die Frage der Authentifizierung des empfangenen Signals/Geräts wiederum FHEM überlassen könnte...

Config und so Sauereien wie Rolling Codes etc. könnte man bequem und vor allem robust im üppigen Flash des ESP persistent (Soft-EEPROM) speichern -

Um die Asynchronität zwischen den beiden Instanzen (also FHEM und ESP) auch wirklich sicherzustellen, muss das Interface m.E. zwingend einen Queueingmechanismus mit ausreichender Puffergröße haben: Dieser entkoppelt zum einen von Verzögerungen im (W)LAN und zum anderen von längeren Laufzeiten bei der Signalaufbereitung/-Sendung, die tlw. in den Sekundenbereich gehen können! z.B. Somfy RTS: da kann ein Sendekommando mit entsprechend sichererer re-transmit-Mimik schnell >0,5 sek. laufen)!
(Könnte dafür ggfs. MQTT geeignet sein? Ich hab mich damit noch nicht tief genug befasst...)

Wenn ich etwas beitragen kann, jederzeit gerne! Am besten eher konzeptionell/im ESP Part; coding/bitbanging wie gesagt eher weniger und FHEM kenne ich ohnehin gar nicht... ;)

Als reinen Somfy-Alternativansatz habe ich hier eine 16 Kanal RTS FB liegen, deren Buttons ich angezapft und über Optokoppler mit einem ESP verbunden habe. Erste Gehversuche mit LUA/nodeMCU haben schon funktioniert; bin jetzt dabei die Befehlsmimik und Fernsteuerung (tcp/udp/MQTT?) auf Arduino IDE aufzusetzen... => Das läuft dann natürlich auch mit FHEM ;), ist aber schmerzlicherweise eine €100+ Lösung, da es die 16-Kanal FB - somfytypisch - gar nicht drunter zu kaufen gibt, und 16 Kanäle sind nun auch nicht grade üppig... - dafür hat man aber Null Stress mit Rolling Codes und anderen Untiefen des RTS-Protokolls und v.a. bekommt man eine (für 433MHz-Verhältnisse!) wirklich wirklich erstklassige Reichweite; ich hab das grade mal bei uns im Haus getestet: diagonal von oben nach unten durch 2 Betondecken und diverse Ziegel-Innenwände über eine Strecke von ca. 20 Metern.

[sidey79]

Weshalb eine WLAN Übertragung langsamer als eine Serielle Übertragung sein sollte wüsste ich jetzt auf Anhieb nicht. Die Serielle Übertragung ist ja schnecken Langsam.
Die 200ms Verzögerung rühren eher aus einer "seltsamen" Implementierung von TCP Nagle.
Der Fehler ist hier esp8266/Arduino/pull/2177 näher beschrieben, wenn es dich interessiert.

Leider gibt es immer noch kein final Release und nur in:
https://github.com/esp8266/Arduino/releases/tag/2.4.0-rc2

Das Grundprinzip hast Du aber korrekt verstanden. Der Microcontroller soll Muster erkennen und die Umwandlung in Protokolle passiert außerhalb des uC.
Diese Variante habe ich mit Absicht gewählt, da:

• Jedes Protokoll sonst eine neue FW bedeuten würde
• Es Massenhaft verschiedene Versionen der FW geben würde (Alle Protokolle würden wohl nie gleichzeitig in den Speicher passen).

Über die Genauigkeit braucht man sich beim ESP12 auch nicht so sehr Gedanken machen. Der hat nicht mal einen HW Interrupt, da läuft alles in SW.
Ob der ESP32 jetzt welche hat, weiss ich nicht. Ich glaube ja. Damit wäre dann schon mal dieses Problem gelöst.

[rgr101]

Ah, verstehe (so ungefähr zumindest; das mit dem TCP Nagle Problem geht mir allerdings zu tief rein - da steig' ich aus :) )

Zu langsam ist die WLAN Übertragung sicher nicht, da bin ich ganz bei dir! Ich meinte eher, dass sie hinsichtlich des Timings tendenziell unsicher ist, weil man nie weiß, wann da welche Störungen auftreten... ?!?

Meinst du mit "Muster erkennen" sozusagen den physical Layer (Frequenz, Modulationsart etc.)?
Und das Interface "nach außen" ist der digitale Datenstrom (also die Bitfolge) vor bzw. nach der Protokollanalyse bzw. -synthese durch FHEM ? Ja, das macht Sinn...
Aber - wird dabei immer ein kompletter "Datensatz" zum uC übertragen, und von diesem erst nach komplettem Empfang an die RF Ebene weitergereicht (dann wäre das Timing ja eigentlich unkritisch) oder erfolgt das in Datenpaketen, die jeweils direkt gesendet werden (dann wäre eine Verzögerung auf Wifi-Ebene ziemlich "tödlich")?

[rgr101]

Ah, verstehe (so ungefähr zumindest; das mit dem TCP Nagle Problem geht mir allerdings zu tief rein - da steig' ich aus :) )

Zu langsam ist die WLAN Übertragung sicher nicht, da bin ich ganz bei dir! Ich meinte eher, dass sie hinsichtlich des Timings tendenziell unsicher ist, weil man nie weiß, wann da welche Störungen auftreten... ?!?

Meinst du mit "Muster erkennen" sozusagen den physical Layer (Frequenz, Modulationsart etc.)?
Und das Interface "nach außen" ist der digitale Datenstrom (also die Bitfolge) vor bzw. nach der Protokollanalyse bzw. -synthese durch FHEM ? Ja, das macht Sinn...
Aber - wird dabei immer ein kompletter "Datensatz" zum uC übertragen, und von diesem erst nach komplettem Empfang an die RF Ebene weitergereicht (dann wäre das Timing ja eigentlich unkritisch) oder erfolgt das in Datenpaketen, die jeweils direkt gesendet werden (dann wäre eine Verzögerung auf Wifi-Ebene ziemlich "tödlich")?

[sidey79]

@rgr101

Beim Senden wird ein Signal an den ESP übergeben. Wenn das übertragen wurde, dann wird das Signal gesendet.

Die Modulation übernimmt der uC.

Beim Empfangen ist es etwas schwieriger. Immer wenn ein Puffer voll ist, oder eine Sendepause entsteht, dann wird an FHEM übergeben.
Hier fallen dann auch die 200 MS durch TCP Nagle ins Gewicht.

[rgr101]

@sidey79

OK - d.h. Senden funktioniert stabil ?!? (Würde für meine Zwecke ja reichen ;), und ich könnte mir mangels FHEM den perl-code des Somfy-Protokolls direkt in den ESP portieren :D - muss mal schauen, ob das ne Option wäre und v.a. ob ich das zeitlich und fähigkeitsmäßig hinkriege... ;D)

Empfang: Ja, ich sehe Problematik - vor allem, da das Signal ja erst auf FHEM Seite interpretiert wird und erst dort auf Vollständigkeit erkannt werden kann...
Und wenn du DOCH den Weg gehen würdest, die Protokoll-Erkennung in den ESP zu verlegen (Speicher sollte mindestens beim ESP32 doch eigentlich ausreichen...?!?) - die Erkennungsmuster könnte man ja im SPIFFS des ESP persistent ablegen und neue Protokolle im laufenden Betrieb ohne Re-Flash über eine entsprechende API-Funktion einspielen... ?

[sidey79]

Hmm, wäre mir zu viel Aufwand das FHEM Modul in den ESP zu portieren

Senden geht, Du kannst auch ohne FHEM etwas über den SIGNALESP senden :)

[rgr101]

Port. - verständlich... ☺️

Senden - ja, aber was ;) muss ja das Signal erstmal aufbereitet kriegen...