SIGNALESP als Somfy-Gateway? #12
Comments
|
Der SIGNALESP zählt leider noch nicht zu einer stabilen Basis die Du suchst. |
|
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...): |
|
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. Ansonsten sind in diesem Repo eine ältere, leider fehlerbehaftet ,Version der Mustererkennung. |
|
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...!) 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)! 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. |
|
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. Leider gibt es immer noch kein final Release und nur in: Das Grundprinzip hast Du aber korrekt verstanden. Der Microcontroller soll Muster erkennen und die Umwandlung in Protokolle passiert außerhalb des uC.
Ü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. |
|
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.)? |
1 similar comment
|
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.)? |
|
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. |
|
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... |
|
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 :) |
|
Port. - verständlich... Senden - ja, aber was ;) muss ja das Signal erstmal aufbereitet kriegen... |
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
The text was updated successfully, but these errors were encountered: