networked CC1101 transceiver mit ESP8266?

[pjakobs]

moin zusammen,

da es ja so aussieht, dass die CUx Sender/Empfänger normalerweise nur ein Protokoll können braucht der Mensch manchmal halt mehrere (ich hab MAX!  Heizungsthermostate, möchte Homematic Schaltsender einsetzen, dumme Baumarkt-Steckdosen steuern und noch ein paar Dinge mehr - damit brauche ich schon drei CUx Module)..
Gut, ich kann weitere CUL Sticks kaufen, aber das ist doch auch irgendwie blöd, oder? Zumal dafür manchmal wirklich seltsame Preise aufgerufen werden.
Auf dem RaspberryPi, auf dem mein FHEM Server läuft wäre zwar sicher noch ein serieller Port frei, aber .. meh, auch zu unflexibel.
Was ich mir vorstelle wäre ein ganz anderes Modell (und bitte sagt mir, ob es das schon gibt und ich mir die Tinte sparen kann):
Mit dem ESP8266 bzw. ESP32 gibt es eine wunderbare Plattform, um alles, was wir bisher mit diversen Atmels gemacht haben nun auf einem preiswerten Controller mit WLAN zu machen. Für ein CUx Modul würde so neben der Stromversorgung nur ein cc1101 Modul und ein ESP01 gebraucht. Voraussetzung:
erstens: die culfw lässt sich auf den ESP portieren (auf den ersten Blick sieht das ziemlich portabel aus),
und zweitens: es gibt einen guten Weg, diesen remote CUx (eigentlich gehört das U ja auch gegen ein x getauscht) vernünftig in fhem einbinden, also nicht als serieller port, sondern vielleicht als network socket oder, lieber noch, als MQTT device.
Vielleicht gibt's das alles ja schon, und ich hab's nur nicht gefunden.
In jedem Fall wäre ich für Rückmeldung dankbar, ob dies möglich und / oder interessant ist.

Grüße

pj

[MadMax-FHEM]

Hi pj,

ähnliche Ideen gibt es schon, vielleicht passt da ja was:

https://forum.fhem.de/index.php/topic,42998.html

https://forum.fhem.de/index.php/topic,54511.html

https://forum.fhem.de/index.php/topic,56606.msg481258.html#msg481258

Wobei bzgl. Homematic (wegen diverser Timing-Probleme) wohl das HM-UART-Modul zu empfehlen ist...
...lässt sich wohl auch mit dem ESP betreiben...

Gruß, Joachim

[pjakobs]

danke MadMax und sorry, dass die Antwort ne Weile dauerte.

wenn ich das richtig sehe sind das ja im wesentlichen Projekte, die die serielle Kommunikation entweder per UART oder USB am FHEM Server abgreifen, irgendwie über WLAN transportieren und auf der anderen Seite wieder serialisieren (korrigier mich, falls ich da was falsches gesehen habe).
Das kommt mir halt ein bisschen steinzeitlich vor, denn ich nehme ein uralt Protokoll, packe es in was moderneres, übertrage es, packe es wieder aus und nutze es. Blöderweise brauche ich dazu auf dem Server auch noch Hardware!
Stattdessen könnte man das, was über das serielle Protokoll läuft doch besser über ein modernes Netzwerkprotokoll wie MQTT schicken und direkt verarbeiten. Damit würde auch die lästige Hardwareanforderung am Server wegfallen.

Was ich bisher nicht verstehe: sind die FHEM Module, die CUL/CUN bedienen überhaupt in der Lage, über andere (Software) Schnittstellen als (virtuelle) UART zu kommunizieren?

pj

pj

[rudolfkoenig]

Blöderweise brauche ich dazu auf dem Server auch noch Hardware!

Diesen Teil habe ich nicht verstanden, HA-Server ohne Netzwerk sind heutzutage unueblich. Die meisten FHEM-Module koennen dank DevIo sowohl direkt angeschlossene USB-Geraete wie auch Netzwerk-Ports ansprechen.

Stattdessen könnte man das, was über das serielle Protokoll läuft doch besser über ein modernes Netzwerkprotokoll wie MQTT schicken und direkt verarbeiten.

Die Loesung Seriell->TCP/IP plain hat mehrere Vorteile gegenueber MQTT:
- man muss nicht das dahinter liegende Firmware aendern
- man braucht keinen MQTT Server
- in FHEM ist fuer den Endanwender keine Aenderung der Events/Befehle/etc notwendig
- fuer manche Protokolle (wie z.Bsp. ZWave) reicht ein FHEM MQTT Modul nicht, man muesste also fuer ZWave over MQTT ein neues FHEM Modul bauen, was fuer den Benutzer keine Vorteile bringt, nicht mal Multiplexing (s.u)

Fuer MQTT spricht:
- "kostenloses" Multiplexing, d.h. Verteilung der Daten an mehrere Empfaenger (jedenfalls fuer manche Protokolle).
- man kann den Hardware mit anderen, MQTT faehigen Software verwenden

[pjakobs]

vielleicht fehlt mir da ja nur der Überblick, denn bisher hatte ich genau ein CUL Modul laufen und das ist lokal (per UART) am RasPi, brauche jetzt aber noch zwei mehr und mir graust vor dem Dongle-Wald, der dann am RasPi entstünde.

Wenn ich Dich richtig verstehe ist das serielle Protokoll ziemlich tief in die Software / Firmware eingebunden.
Was mir nicht klar ist: UART ist kein Protokoll, auf dessen Timing ich mich absolut verlassen könnte, ergo muss das Timing so oder so auf dem Microcontroller passieren - warum hat dann das Transportprotokoll einen Einfluss auf die Funktionalität? In meiner Vorstellung ist es völlig egal, ob ich
[FHEM Modul]---o---{UART-Verbindung}---o---[Firmware],
[FHEM Modul]---o---{UART}---o---{UART-WLAN-BRIDGE}---o---{UART}---o---[Firmware] oder
[FHEM Modul{MQTT Client}]---o---{MQTT Broker}---o---[{MQTT Client} Firmware] verwende

Aber wie gesagt: die ganze CUL/CUN Architektur ist mir bisher noch nicht klar geworden. Vielleicht steckt da doch noch mehr dahinter.

Ich nutze MQTT seit einer Weile für alle möglichen (selbst gebauten) Sensoren, weil es einfach banal einfach ist - sowohl auf der Firmware Seite als auch zum Einbinden in virtuelle FHEM Devices ohne dafür gleich zwangsweise neue Module schreiben zu müssen.

pj

[rudolfkoenig]

[FHEM Modul]---o---{UART}---o---{UART-WLAN-BRIDGE}---o---{UART}---o---[Firmware]

Das ist falsch, und sieht so aus:
[FHEM Modul]---o---{UART-WLAN-BRIDGE}---o---{UART}---o---[Firmware]
oder mit leichter firmware-Aenderung (z.Bsp. culfw@CUN*)
[FHEM Modul]---o----[Firmware (spricht TCP/IP)]

als auch zum Einbinden in virtuelle FHEM Devices ohne dafür gleich zwangsweise neue Module schreiben zu müssen

Bei einfachen Sensoren ist das auch normal. Sobald das Protokoll komplizierter wird, braucht man aber auf der FHEM Seite ein Modul, und der muss entweder MQTT oder das  bisherige serielle Protokoll entschluesseln. Klar koennte man 00_CUL.pm durch ein neues "00_MQTTCUL.pm" austauschen, aber den muesste man erst bauen, und Vorteile gegenueber "plain TCP/IP" haette es nicht.

Statt CUN* empfehle ich uebrigens CUL+RPi+ser2net: ist universeller und auf lange Sicht einfacher.

[MadMax-FHEM]

Hallo,

so nun auch mal wieder was von mir

Es gibt auch noch (soweit ich das umrissen habe z.B. zusammen mit dem HM-UART) folgende Variante:

[FHEM Modul]---o---{WLAN-BRIDGE-UART }---o---[Firmware]

bzw. ist das dann ja quasi eine Abwandlung von:

[FHEM Modul]---o----[Firmware (spricht TCP/IP)]

Da Quasi durch die Anbindung des HM-UART an einen ESP8266 der HM-UART zum HM-WLAN wird...
Und per Anbindung an einen seriell-LAN zum HM-LAN werden kann...

Und das (wie Rudolf geschrieben hat) ohne (große) Anpassung der Module bzw. FW.
(Es wird ja quasi nur der Transportweg geändert: von direkt USB-Anschluss zu "entferntem" USB-Anschluss [per LAN, WLAN])

Gruß, Joachim

[pjakobs]

ok, dann gibt's das, was ich grundsätzlich will (ein CUL/CUN für das ich keine lokale zusätzliche Hardware brauche) ja doch schon. Gut
Und - na ja, ich find RAW Sockets halt immer ein bisschen seltsam, also sowas wie async over tcp / udp, alleine schon weil eines character based, das andere packet based ist. Aber wenn's funktioniert soll's mir recht sein

Dann muss ich ja nur noch ein Projekt finden, bei dem die culfw auf den 8266 portiert läuft (denn ich möchte natürlich auch nicht zusätzlich einen Atmel laufen haben)
danke für die Info!

pj

ps: erinnert mich ein bisschen an den CAPTURE Befehl mit dem man früher lokale Druckerports auf irgendwelche Netzwerkdrucker umleiten durfte

[eiten]

Hallo Pjakobs,

bist Du bei Deiner suche nach einer ESP-Portierung der culfw erfolgreich gewesen? Ich suche was ähnliches, sonst muss ich mich ans Werk machen  .

Danke und Gruss, Edi

[pjakobs]

Hi Edi, leider nein, ich hab jetzt halt zwei "normale" Atmel CULs gebaut.

pj

[eiten]

Tja, dann werde ich mal die libs analysieren und schauen, mit welchem Ausgangspunkt das am einfachsten sein könnte... Danke Dir!

[adn77]

Hallo zusammen,

ich Frage mich auch schon eine Weile, ob ein Arduino Oberhaupt notwendig ist, da ein ESP8266 wahrscheinlich deutlich leistungsfähiger ist, er aber nur als stupider WLAN-Seriell Umsetzer genutzt wird.

Mein Ansatz ist die a-CULFW von Björn Hempel. Ich bin echt keine Programmier-Leuchte in C(++) , aber so wie ich das verstehe, muss man "nur" eine Board-Definition für den ESP anlegen. Dabei ist Schritt 1 zunächst Arduino Kompatibilität zu erreichen (d.h. Kommunikation via UART). Schritt 2 wäre, einen CUN zu emulieren.
In jedem Fall kommst du wohl mit einem ESP-01 nicht weit - man braucht zumindest eine SPI und noch zwei weitere Pins. Den ESP-12e/f gibt es bei ebay inzwischen ebenfalls für rund zwei Euro.

Vielleicht sind die Jungs und Mädels vom Lacrosse Gateway auch eine Hilfe, denn da läuft es ja schon längst so.

Wäre cool, wenn noch jemand auf den Zug aufspringen würde
Alex

[pjakobs]

genau das war mein Gedanke:

zwei ESP8266 als Serielle Brücke zu verwenden und dahinter einen Arduino zu haben ist gelinde gesagt Unsinn.

Elegant wäre ein ESP8266 als CUN, u.U. würde die Rechenleistung sogar genügen, um mehr als ein Funkmodul zu bedienen, aber das wäre eine zu große Änderung der Architektur.

Ich sehe ein paar Punkte die größere Änderungen mit sich bringen werden:

• Netzwerkinterface
  
  
  
  • Kommunikation via TCP oder UDP
  • Konfiguration via html Frontend?
• ggf. Timer auf der ESP Seite

pj

[hjgode]

Hi

ich habe zwar nicht alle Beiträge durchgelesen aber wenn es um folgendes geht sollte ein ESP8266 ESP-12 mit der esplink software von Jeelink ausreichen:
CUL oder Nachbau wird per Rx/TX an den EPS-12 angeschlossen. Das esplink ist eine Bridge zwischen seriell und WLAN. In FHEM kann man statt einem 'virtuellen' seriellen Port einfach die 'Telnet' Schnittstelle von esplink einsetzen.

Hab ich so mit einem SignalDuino laufen. Statt /dev/ttyUSBx staht da dann 192.168.0.99:23 für die Telnet Schnittstelle. Bei entsprechender Verkabelung kann man sogar remote flashen. Geht bei dieser SignalDuino Geschichte bei mir wunderbar.

Vorteil: keine Änderung am CUL code; CUL kann beliebig innerhalb der WLAN Reichweite platziert werden.
Nachteil: Zusätzliche Stromversorgung für das Gespann ESP-CUL

Da der ESP8266 sehr zeitkritisch bezgl WLAN ist, können schnelle Interrupts die Verbindung stören. Eine Portierung von zeitkritischem Code zur Auswertung von Signalen wird sich schwierig bis unmöglich gestalten

Nur so ein paar Gedanken.