Funkmodul LAN Extender

[jp112sdl]

Lasercutter

CNC3018 mit 5.5W Laser nutze ich.
Aber mehr sollte es dann hier im Thread nicht OT werden

[deimos]

Hi,

mal wieder ein Update von mir:

Ich bin ein gutes Stück weitergekommen und sehe langsam Licht am Ende vom Tunnel:

Ich habe jetzt eine klare Vorstellung, was in eine Version 1 rein muss, bzw. eher, was auf eine spätere Version warten muss:

• Transportverschlüsselung
• HTTPS für die Weboberfläche
• Eine komplette Erkennung des aufgesteckten Funkmoduls innerhalb der HB-RF-ETH
• Ein LAN-GW Modus
• Einstellungen für LED Helligkeit und Fading

Was in Version 1 drin sein wird:

• raw-uart für das Funkmodul per Netzwerk (klar, das ist die Hauptaufgabe )
• Ansteuerung der LEDs von einem RPI-RF-MOD und der eingebauten LEDs an der Position, an welcher der Pi3 auch seine LEDs hat
• Ansteuerung einer RTC, entweder die vom RPI-RF-MOD oder ein optionales DS3231 Modul (wie z.B. https://www.amazon.de/DS3231-Echtzeituh ... ef=sr_1_10)
• (S)NTP Server zur Bereitstellung der Zeit im lokalen Netz (ggf. mit RTC Pufferung)
• (S)NTP Client zum Abruf der Zeit aus dem Internet
• DCF77 Empfänger mit optionalem DCF Modul (https://de.elv.com/elv-gehaeuse-fuer-ex ... =842724529)
• Kabelgebundenes Netzwerk, IP per DHCP oder statisch
• MDNS Server um die HB-RF-ETH im lokalen Netzwerk bekannt zu machen
• PoE optional möglich
• WebUI für die Einstellung der Netzwerkparameter und für das Einspielen von Firmware Updates

Bis auf die WebUI sind alle Features fertig, bei der WebUI fehlt noch eine Möglichkeit für eine Authentifizierung und die Implementierung des Speicherns der Einstellungen.

Das Kernel Modul ist so gut wie fertig, hier fehlt nur noch die Auswertung von Keep Alive Paketen, welche die HB-RF-ETH regelmäßig aussendet.

Was im Moment noch komplett fehlt, ist die Einbindung in piVCCU3 und debmatic in einer Art und Weise, dass das nicht nur von mir gestartet werden kann, sondern dass das auch von normalen Nutzern verwendet werden kann.

Was ebenfalls im Moment noch fehlt, ist ein Braindump für die Doku. Wie das bei Entwicklern halt so ist, die wird immer schön weit nach hinten geschoben.

Insgesamt hege ich die Hoffnung, dass ich im Juli mit einer ersten Version fertig werde.

Viele Grüße
Alex

[klassisch]

[*] Kabelgebundenes Netzwerk, IP per DHCP oder statisch
[*] MDNS Server um die HB-RF-ETH im lokalen Netzwerk bekannt zu machen
[*] PoE optional möglich
[*] WebUI für die Einstellung der Netzwerkparameter und für das Einspielen von Firmware Updates

[*] Ansteuerung einer RTC, entweder die vom RPI-RF-MOD oder ein optionales DS3231 Modul (wie z.B. https://www.amazon.de/DS3231-Echtzeituh ... ef=sr_1_10)
[*] (S)NTP Server zur Bereitstellung der Zeit im lokalen Netz (ggf. mit RTC Pufferung)
[*] (S)NTP Client zum Abruf der Zeit aus dem Internet

Das klingt ja so als wolltest Du den gravierenden Mangel der Fritte ausgleichen und einen schnell bootenden SNTP Server mit Netzausfallüberbrückung etablieren.
Ich habe kürzlich gesehen, daß einer meiner ESP8266 basierten Sensoren meint, seit epoch uptime zu haben. Der war wohl beim Stromausfall 2018 schneller an Deck als die Fritte und ich habe diesen Zustand noch nicht ordentlich abgefangen. Da wäre so ein Server hilfreich. Und um alles konsistent zu halten, sollte die Fritte dann auch ihre Zeit von dort beziehen. Aber ob die mit einem SNTP zufrieden ist, oder einen NTP verlangt?

[*] DCF77 Empfänger mit optionalem DCF Modul (https://de.elv.com/elv-gehaeuse-fuer-ex ... =842724529)
[/list]

Wozu das? Ein LAN, welches eine piVCCU beinhaltet, wird ja wohl auch immer irgendwie Internetanschluss haben.

Bis auf die WebUI sind alle Features fertig, bei der WebUI fehlt noch eine Möglichkeit für eine Authentifizierung und die Implementierung des Speicherns der Einstellungen.

Respekt! Wenn der Prozessor I^2C hat, dann kann man doch ein I^2C EEPROM AT24C256 nehmen. Habe ich an meinem Wasseruhrsensor, war selbst für mich problemlos. Gibts mittlerweile sogar als fertiges breakout board.

[jp112sdl]

Wenn der Prozessor I^2C hat, dann kann man doch ein I^2C EEPROM AT24C256 nehmen

Deimos schrieb eingangs mal was von ESP32. Dieser bringt 16k (physischen, nicht gänzlich nutzbaren) NVS mit. Das sollte mehr als genug sein.

ESP8266

ist wohl für ein solches Projekt nicht die beste Wahl.
Allein schon die 2 Cores des ESP32 machen Vieles entspannter, was zeitkritische Prozesse betrifft

[deimos]

Hi,

[*] Ansteuerung einer RTC, entweder die vom RPI-RF-MOD oder ein optionales DS3231 Modul (wie z.B. https://www.amazon.de/DS3231-Echtzeituh ... ef=sr_1_10)
[*] (S)NTP Server zur Bereitstellung der Zeit im lokalen Netz (ggf. mit RTC Pufferung)
[*] (S)NTP Client zum Abruf der Zeit aus dem Internet

Das klingt ja so als wolltest Du den gravierenden Mangel der Fritte ausgleichen und einen schnell bootenden SNTP Server mit Netzausfallüberbrückung etablieren.

Auch wenn ich nicht die Fritte im Speziellen im Sinn hatte, grundsätzlich war das der Gedanke.

Ich habe kürzlich gesehen, daß einer meiner ESP8266 basierten Sensoren meint, seit epoch uptime zu haben. Der war wohl beim Stromausfall 2018 schneller an Deck als die Fritte und ich habe diesen Zustand noch nicht ordentlich abgefangen. Da wäre so ein Server hilfreich. Und um alles konsistent zu halten, sollte die Fritte dann auch ihre Zeit von dort beziehen. Aber ob die mit einem SNTP zufrieden ist, oder einen NTP verlangt?

SNTP ist auf UDP Ebene kompatibel mit NTP. So ziemlich alle Implementierungen, welche nur einen Upstream Server nutzen, sind per se "nur" SNTP; NTP definiert da vor allem viel bei der Auswahl der "richtigen" Zeitquelle und wie man bewerten kann, was die "richtige" Zeitquelle ist. Grade die ganzen ESPs können nur SNTP.

[*] DCF77 Empfänger mit optionalem DCF Modul (https://de.elv.com/elv-gehaeuse-fuer-ex ... =842724529)
[/list]

Wozu das? Ein LAN, welches eine piVCCU beinhaltet, wird ja wohl auch immer irgendwie Internetanschluss haben.

Einfach weil ich es kann und es cool fand

Bis auf die WebUI sind alle Features fertig, bei der WebUI fehlt noch eine Möglichkeit für eine Authentifizierung und die Implementierung des Speicherns der Einstellungen.

Respekt! Wenn der Prozessor I^2C hat, dann kann man doch ein I^2C EEPROM AT24C256 nehmen. Habe ich an meinem Wasseruhrsensor, war selbst für mich problemlos. Gibts mittlerweile sogar als fertiges breakout board.

Ich nutze ja den ESP32, der hat genug Flash dafür. Es geht bei dem Punkt nur darum, dass die geänderten Daten von der WebUI in das Flash geschrieben werden müssen. Von dort ausgelesen werden sie schon.

Wenn der Prozessor I^2C hat, dann kann man doch ein I^2C EEPROM AT24C256 nehmen

Deimos schrieb eingangs mal was von ESP32. Dieser bringt 16k (physischen, nicht gänzlich nutzbaren) NVS mit. Das sollte mehr als genug sein.

Nur bei Verwendung vom Arduino Core sind das 16k. Der NVS ist einfach eine Partition im Flash, bei Verwendung von esp-idf kann die auch deutlich größer sein als 16k, theoretisch auch mehrere MB. Wobei es bei den größen dann Sinn macht, das nicht per NVS, sondern per SPIFFS zu nutzen.
Ich hatte mit dem Arduino Core angefangen, aber ich bin wirklich froh, dass ich vor zwei Wochen alles auf esp-idf portiert habe, die Arduino Libs abstrahieren sehr viel weg. Das ist gut für Anfänger und schelle Projekte, aber für Spezialanwendungen ist es problematisch. Z.B. kann man mit den Arduino Libs den UART nur pollen, mit esp-idf kann man da Interrupt gesteuert arbeiten, was die Latenz natürlich deutlich verbessert.

ESP8266

ist wohl für ein solches Projekt nicht die beste Wahl.
Allein schon die 2 Cores des ESP32 machen Vieles entspannter, was zeitkritische Prozesse betrifft

Der hat noch einige Vorteile mehr:

• Die MAC Schicht ist bereits im Prozessor drin, für kabelgebundenes Netzwerk braucht es nur noch einen PHY, in meinem Fall den LAN8720A, wodurch man den kompletten TCP/IP Stack vom ESP nutzen kann.
• Der ESP8266 hat nur einen UART, blöd, wenn man einen UART für das Funkmodul braucht und nicht anfangen will zu multiplexen. Software UART für das Funkmodul dürfte sich wegen der Latenzen verbieten
• Er hat Unterstützung für Hardware beschleunigte Verschlüsselung, welche später für die Transportverschlüsselung wichtig ist.
• Deutlich mehr GPIOs und ich nutze tatsächlich alle

Die ganzen weiteren Hardware Schnittstellen wie I2C, I2S, Bluetooth, mehr ADCs, Touchsensoren, Hallsensor, etc. brauch ich zwar nicht, aber sie machen die Platine ggf. auch interessant für Projekte, welche nicht direkt mit Homematic zu tun haben.

Viele Grüße
Alex

[klassisch]

Deimos schrieb eingangs mal was von ESP32. Dieser bringt 16k (physischen, nicht gänzlich nutzbaren) NVS mit. Das sollte mehr als genug sein.

Bei einem ESP32 oder ESP8266 braucht man kein externes NVM für seltene Konfigurationen. Da nutze ich auch den internen Speicher. Bei meinem Wasserzähler mit dem ESP8266 schreibe ich vorwiegend volumengesteuert den Zählerstand ins EEPROM. Der wurde mittlerweile 34523 mal geschrieben. Das wollte ich dem eingebauten Flash nicht antun. Aber auch das ist nur "Spielerei", denn vorher hatte ich die zwischengespeicherten Daten nach dem Start von der CCU geholt. Das ging auch.

ESP8266

ist wohl für ein solches Projekt nicht die beste Wahl.
Allein schon die 2 Cores des ESP32 machen Vieles entspannter, was zeitkritische Prozesse betrifft

Mir ist es leider nie gelungen, die einzelnen Prozesse frei auf die Cores aufzuteilen. Der WLAN Prozess und mein Anwendungsprozess landeten immer auf dem selben Core. Aber ich habe das auch nur mit der Arduino IDE versucht und das auch nur zu Anfang. Das mag heute oder mit der Espressif-IDF gehen. Vielleicht war ich auch einfach zu ungeschickt und ich habe auch nicht genügend Zeit investiert um das RTOS zu erkunden.

[jp112sdl]

alles auf esp-idf portiert habe, die Arduino Libs abstrahieren sehr viel weg.

Ja, die Erfahrung habe ich auch schon gemacht.
Der Umstieg ist aber halt wie "noch mal ganz von vorn" anfangen.

Der hat noch einige Vorteile mehr:

Das in jedem Fall!

Der WLAN Prozess und mein Anwendungsprozess landeten immer auf dem selben Core. Aber ich habe das auch nur mit der Arduino IDE versucht

Ja, das ist, wie Deimos schon schrieb, mit der Arduino IDE für den schnellen Einstieg wirklich gut.
Man muss sich nicht um viel kümmern, da im Hintergrund alles für eine "working"-Konfiguration eingestellt ist.
Aber wenn man die Hardware ausreizen will, kommt man um das IDF nicht herum.

[klassisch]

Auch wenn ich nicht die Fritte im Speziellen im Sinn hatte, grundsätzlich war das der Gedanke.

Das klingt gut. Könnte man auch nutzen, wenn man den eigentlichen Funkmodul LAN Extender nicht braucht.

Grade die ganzen ESPs können nur SNTP.

könnte eine Fritte von einem ESP die Zeit holen?

Einfach weil ich es kann und es cool fand

Das ist das Schöne bei unseren Freizeitprojekten. Da darf man sowas machen.

Ich nutze ja den ESP32, der hat genug Flash dafür. Es geht bei dem Punkt nur darum, dass die geänderten Daten von der WebUI in das Flash geschrieben werden müssen. Von dort ausgelesen werden sie schon.

EEPROM.h kann das handeln. Allerdings Arduino.

Ich hatte mit dem Arduino Core angefangen, aber ich bin wirklich froh, dass ich vor zwei Wochen alles auf esp-idf portiert habe, die Arduino Libs abstrahieren sehr viel weg. Das ist gut für Anfänger und schelle Projekte, aber für Spezialanwendungen ist es problematisch. Z.B. kann man mit den Arduino Libs den UART nur pollen, mit esp-idf kann man da Interrupt gesteuert arbeiten, was die Latenz natürlich deutlich verbessert.

Langfristig lohnt sich das sicher. Wahrscheinlich kann man dann auch die Prozesse den Cores zusteuern.

• Die MAC Schicht ist bereits im Prozessor drin, für kabelgebundenes Netzwerk braucht es nur noch einen PHY, in meinem Fall den LAN8720A, wodurch man den kompletten TCP/IP Stack vom ESP nutzen kann.

Das klingt interessant.

[*] Der ESP8266 hat nur einen UART, blöd, wenn man einen UART für das Funkmodul braucht und nicht anfangen will zu multiplexen. Software UART für das Funkmodul dürfte sich wegen der Latenzen verbieten

Das ist für mich einer der größten Nachteile des ESP8266. Und wenn ich neben der debug-Schnittstelle eine HWSerial brauche, dann nehme den ESP32. Allerdings nur mit Arduiono IDE.

[*] Deutlich mehr GPIOs und ich nutze tatsächlich alle
[/list]

Oh, alle GPIOs! Das ist schon recht komplex.
Der ESP8266 hat auch etliche Beschränkungen bei der Nutzung der GPIOs. Auch da ist der ESP32 viel stärker.
Die Low-Power Cores und der eingebaute HW-Zähler klingen auch noch sehr interessant. Aber da muß man sicher tiefer in Espressif IDF und RTOS eintauchen.

Die ganzen weiteren Hardware Schnittstellen wie I2C, I2S, Bluetooth, mehr ADCs, Touchsensoren, Hallsensor, etc. brauch ich zwar nicht, aber sie machen die Platine ggf. auch interessant für Projekte, welche nicht direkt mit Homematic zu tun haben.

Ja, z.B.
- gepuffertes Real Time Modul
- Seriell 2 Ethernet Wandler, um z.B. die optische Info-Schnittstelle des Stromzählers ins LAN einzuspeisen. ioBroker müßte das dann verarbeiten können.

[deimos]

Hi,

könnte eine Fritte von einem ESP die Zeit holen?

Kann ich leider nicht sagen, ich habe keine (mehr). Das Ubiquiti USG macht für den Nerd einfach deutlich mehr Spaß.

Ich nutze ja den ESP32, der hat genug Flash dafür. Es geht bei dem Punkt nur darum, dass die geänderten Daten von der WebUI in das Flash geschrieben werden müssen. Von dort ausgelesen werden sie schon.

EEPROM.h kann das handeln. Allerdings Arduino.

Ja, ist nur Arduino. In esp-idf sind das die nvs_set_* Methoden. Das physikalische Speichern ist auch schon fertig, mit fehlt der weg von WebUI per AJAX in meine Settings Klasse. Das ist technisch nicht weltbewegend, es ist einfach nur noch nicht fertiggestellt.

Ich hatte mit dem Arduino Core angefangen, aber ich bin wirklich froh, dass ich vor zwei Wochen alles auf esp-idf portiert habe, die Arduino Libs abstrahieren sehr viel weg. Das ist gut für Anfänger und schelle Projekte, aber für Spezialanwendungen ist es problematisch. Z.B. kann man mit den Arduino Libs den UART nur pollen, mit esp-idf kann man da Interrupt gesteuert arbeiten, was die Latenz natürlich deutlich verbessert.

Langfristig lohnt sich das sicher. Wahrscheinlich kann man dann auch die Prozesse den Cores zusteuern.

Auch bei Arduino kann man Prozesse auf andere Cores schieben, allerdings sind die internen fix einem Core zugeordnet. Ich versuche mich aber grade von einer Core Affinity zu lösen und dem Task Scheduler zu überlassen, welcher Core genutzt wird. Mit Arduino ist das leider unmöglich.

Viele Grüße
Alex

[stan23]

Auch bei Arduino kann man Prozesse auf andere Cores schieben, allerdings sind die internen fix einem Core zugeordnet. Ich versuche mich aber grade von einer Core Affinity zu lösen und dem Task Scheduler zu überlassen, welcher Core genutzt wird. Mit Arduino ist das leider unmöglich.

Multicore-Programmierung bringt beliebig unglaubliche Fehler mit sich, wenn man nicht konsequent darauf achtet seine Variablen bzw. Daten vor Zugriffen aus einem anderen Kontext bzw. Core zur "falschen Zeit" zu schützen. Das ist bei SMP noch schlimmer als bei BMP.

Arduino schützt den Programmierer da zum Teil davor indem vieles auf einem Core abläuft.