FHEM Forum

Verschiedenes => Projekte => Thema gestartet von: saghonfly am 29 Mai 2020, 19:03:47

Titel: Integration Platform basierend auf ESP mit FHEM Modulen
Beitrag von: saghonfly am 29 Mai 2020, 19:03:47
Hallo,


 schaut euch bitte mal dieses Github Projekt an welches es sich zum Ziel gemacht hat, möglichst günstig und einfach eine Komplettlösung für die Integration von verschiedensten Sensoren (später auch Aktoren) zu erstellen.
https://github.com/saghonfly/shrdzm/wiki (https://github.com/saghonfly/shrdzm/wiki)


Das ganze steckt noch in den Kinderschuhen, wird aber stetig erweitert werden.
 
Mittlerweile gibt es dazu auch 2 Module für FHEM (SHRDZM, SHRDZMDevice).

Würde mich freuen wenn es ein paar Freiwillige gibt die sich das Projekt mal ansehen und entsprechend Rückmeldung geben um es letztendlich allgemein brauchbar zu machen.

Gruss
Saghonfly


Update: 23.06.2020
Die Einschränkung auf Sensoren wurde aus dem Konzept raus genommen. Vom Prinzip geht es nun generell um eine Integrations Plattform mit dem Fokus auf einer Ende-zu-Ende Lösung basierend auf ESP's, ESPNow und flexibler Integrations-Infrastruktur.


Update: 31.08.2020 (Version 0.3.0)
Implementierung Integration Style III (Mobile Integration) und SDS011 Beispiel hinzugefügt.


Update: 06.11.2020 (Version 0.3.1)
SmartMeter Siemens IM350 Device hinzugefügt.https://github.com/saghonfly/shrdzm/wiki/IM350 (https://github.com/saghonfly/shrdzm/wiki/IM350)
Titel: Antw:Sensor Platform basierend auf ESP mit FHEM Modulen
Beitrag von: M.Schulze am 02 Juni 2020, 12:28:24
Hallo,

ist ein interessantes Projekt, aber …

Ich arbeite nebenbei schon länger an einer eigenen Platform für Sensoren und Geräte.

Erste Generation ist schon im Einsatz. Ist  aber fix compiliert. Modular nur auf Quell-Code Ebene. ESP8266 ist damit wegen begrenzter Hardware abgehakt. Basiert auch auf dem alten nonos-SDK. Leistungsfähig aber ohne Zukunft.

Zweite Generation (alpha) ist im Kern so aufgebaut wie ein WEB-Server, ja wie FHEM, Modular mit Kommandos und Modulen, statt fhem.cfg eine makerfile.cfg, standardisierte Callbacks im Modul, auch im Select-Loop, jedenfalls soweit meine C-Kenntnisse dies zulassen und soweit mir das sinnvoll erscheint.
Bei RegEx-C-Umsetzung und bei Implementierung von Multithreading ist da allerdings aktuell oft Schluss.

Meine Meinung:
Ich würde nicht zu viel Zeit investieren in solch ein auf Arduino Framework basierendes Projekt. Nicht zukunftssicher. Nicht für alle SoC (sofort) einsetzbar. Haben auch schon andere probiert (auch hier aus dem Forum, glaube ich)
Eher etwas mehr Entwicklungszeit einkalkulieren und es gleich richtig machen, einen leisungsfähigeren SoC (ESP-32), dann gleich mit ESP-IDF entwickeln. Dann sollte es zukünftig auch auf allen Linux SoCs laufen, wenn die Projekte (Module) doch größer werden.


MfG
Titel: Antw:Sensor Platform basierend auf ESP mit FHEM Modulen
Beitrag von: MadMax-FHEM am 02 Juni 2020, 12:43:37
Ich werfe mal noch 2 "Altbekannte" in die Runde:

https://wiki.fhem.de/wiki/ESPEasy

https://wiki.fhem.de/wiki/Sonoff

https://forum.fhem.de/index.php?topic=90220.0

Gruß, Joachim
Titel: Antw:Sensor Platform basierend auf ESP mit FHEM Modulen
Beitrag von: PeMue am 11 Juni 2020, 15:27:23
Hallo,

Würde mich freuen wenn es ein paar Freiwillige gibt die sich das Projekt mal ansehen und entsprechend Rückmeldung geben um es letztendlich allgemein brauchbar zu machen.
den Ansatz mit den drei verschiedenen Integrationsmöglichkeiten finde ich interessant.
Allerdings unterscheidet sich die Variante I von der II nur durch den zwischengeschalteten MQTT Broker bzw. in IIa ist noch ein 433 MHz Empfänger mit dabei.
Was mich interessiert ist, ob die Möglichkeit des Batteriebetriebs besteht. Die ESP8266 sind m.E. für Batteriebetrieb nicht wirklich optimal.

Gruß Peter
Titel: Antw:Sensor Platform basierend auf ESP mit FHEM Modulen
Beitrag von: saghonfly am 11 Juni 2020, 18:55:29
Hallo,

Zitat
Allerdings unterscheidet sich die Variante I von der II nur durch den zwischengeschalteten MQTT Broker bzw. in IIa ist noch ein 433 MHz Empfänger mit dabei.
Ja, da hast du völlig recht.
Den Ansatz es modular aufzubauen ist Teil des Konzeptes.
Mit dem Gateway soll nur die Verbindung zu den Devices abstrahiert werden.
Ob dieses Gateway direkt (also seriell), über einen MQTT Wrapper oder/und über das noch geplante GSM Modul eingebunden werden soll ist dann von den Rahmenbedingungen des Einsatzes abhängig.
Befinden sich die Devices in unmittelbarer Nähe vom Server wo auch zB.: FHEM läuft, bietet sich die einfache serielle Variante an.
Im Falle das sich die Devices zB.: an einem ganz anderen Ort befinden (zum Beispiel in der Zweitwohnung), macht es Sinn diese über die MQTT Variante anzubinden.
Für eine mobile Variante ist die GSM Variante angedacht (Integration Style III). Dieses kann man dann zB.: im Auto mitführen und die Devices wären damit auch mobil.

Zu IIa, ja....ist eigentlich nur ein Zusatz der nur deshalb dazugekommen ist weil ich mir ein zusätzliches Gateway sparen wollte um 433MHz Zwischensteckdosen bzw. Funkfernsteuerungen einzubinden.
Passt zugegebenermaßen nicht ganz ins Konzept und da bin ich mir selbst nicht sicher ob das Zukunft hat...

Zitat
Was mich interessiert ist, ob die Möglichkeit des Batteriebetriebs besteht. Die ESP8266 sind m.E. für Batteriebetrieb nicht wirklich optimal.
Die Devices für die Sensoren sind prinzipiell für Batteriebetrieb gedacht, das Gateway eher nicht. Ich denke aber, das hast du damit nicht gemeint?
Leider ist es auch richtig, das die ESP's generell nicht sehr sparsam sind.
Mit dem Ansatz die ESP's so lange wie möglich im DeepSleep zu halten (stimmt, auch dabei sind sie nicht sooo sparsam) und nur für wenige Millisekunden hochzufahren um die Messung zu machen bzw. über ESPNow ohne allzu großen Overhead die Daten abzuschicken, hält sich der Stromverbrauch in Grenzen.
Versuche haben gezeigt, das ein ESP-12 mit einem DHT-22, einem Intervall von 2 Minuten und einem 18650-Akku mit 2.4 Ah, ca. drei bis vier Monate durchhält.
Hier sehe ich allerdings noch viel potential für Verbesserungen.

Die Gründe warum derzeit ESP's als Hardware und ESPNow als Transport verwendet wird ist dem derzeit unschlagbaren Preis eines 'Komplettsets' geschuldet bzw. dem einfachen Aufbaus dessen.


Gruss
Erich

Titel: Antw:Sensor Platform basierend auf ESP mit FHEM Modulen
Beitrag von: sash.sc am 14 Juni 2020, 15:43:31
Sprich das ganze baut auf espnow auf, und ist nicht mehr kompatibel zum normalen WLAN. Man braucht auf jeden Fall ein eigenes Gateway.
Titel: Antw:Sensor Platform basierend auf ESP mit FHEM Modulen
Beitrag von: saghonfly am 15 Juni 2020, 15:26:38
Hallo,

Zitat
Sprich das ganze baut auf espnow auf, und ist nicht mehr kompatibel zum normalen WLAN. Man braucht auf jeden Fall ein eigenes Gateway.

Ja, die Kommunikation zwischen den Sensoren (bzw. der Devices welche die Sensoren auslesen) und dem Gateway ist ESPNow.
Die Einbindung des Gateways ist dann flexibel.

Gruss
Erich
Titel: Antw:Sensor Platform basierend auf ESP mit FHEM Modulen
Beitrag von: balli1187 am 15 Juni 2020, 19:38:03
Hab’s nur kurz überflogen aber sehe jetzt keinen Vorteil gegenüber Tasmota oder ESPeasy (auch wenn ich letzteres nie genutzt hab).

Was kann diese Firmware, was die genannten nicht können?
Titel: Antw:Sensor Platform basierend auf ESP mit FHEM Modulen
Beitrag von: Papaloewe am 15 Juni 2020, 21:25:08
BATTERIEBETRIEB!
Titel: Antw:Sensor Platform basierend auf ESP mit FHEM Modulen
Beitrag von: Gisbert am 15 Juni 2020, 23:16:44
Hallo Saghonfly,

ich hatte deinen Thread erst gesehen, nachdem ich Interesse für ESP-Now bekundet habe.
Anscheinend bist du ein Experte in diesen und anderen Dingen und kannst mir gelegentlich unter die Arme greifen.

Im Moment kann ich das Projekt aus Zeitgründen noch nicht starten, würde mich aber bei Zeiten melden, ich hoffe, das geht in Ordnung.

Viele Grüße Gisbert
Titel: Antw:Sensor Platform basierend auf ESP mit FHEM Modulen
Beitrag von: PeMue am 16 Juni 2020, 07:55:09
BATTERIEBETRIEB!
Ist ESP8266 und Batteriebetrieb nicht ein Widerspruch in sich?

Gruß Peter
Titel: Antw:Sensor Platform basierend auf ESP mit FHEM Modulen
Beitrag von: MadMax-FHEM am 16 Juni 2020, 08:19:43
Ist ESP8266 und Batteriebetrieb nicht ein Widerspruch in sich?

Gruß Peter

Wenn man diesem Video glauben darf, dann nicht generell: https://www.youtube.com/watch?v=6NsBN42B80Q  ;)

Allerdings ist es dann halt eigentlich kein ESP/WLAN mehr, sondern halt eine "eigene lowpower Kommunikation"...
...also wieder Gateway...

Dann ist der Unterschied zu z.B. mySensors nicht mehr wirklich gegeben bzw. wäre mir dann (aktuell) durch die bestehende Integration von z.B. mySensors das "lieber"...

Gruß, Joachim
Titel: Antw:Sensor Platform basierend auf ESP mit FHEM Modulen
Beitrag von: balli1187 am 16 Juni 2020, 08:52:04
BATTERIEBETRIEB!
Tasmota unterstützt mittlerweile den deepsleep des ESP.
https://tasmota.github.io/docs/DeepSleep/

Damit sill Batteriebetrieb im allgemeinen möglich sein.
Titel: Antw:Sensor Platform basierend auf ESP mit FHEM Modulen
Beitrag von: MadMax-FHEM am 16 Juni 2020, 08:56:01
Tasmota unterstützt mittlerweile den deepsleep des ESP.
https://tasmota.github.io/docs/DeepSleep/

Damit sill Batteriebetrieb im allgemeinen möglich sein.

Ja aber dennoch mit sehr überschaubarer Laufzeit, weil eben zur Kommunikation immer noch: WLAN, Verbidung mit AP etc. nötig sind was eben lange/länger dauert und mehr Strom braucht als das "simple" ESP-Now...

Gruß, Joachim
Titel: Antw:Sensor Platform basierend auf ESP mit FHEM Modulen
Beitrag von: Beta-User am 16 Juni 2020, 09:04:57
Na ja, wenn WLAN im Spiel ist, ist das ganze eben energieintensiv, von daher dürfte dieses ESPNow Vorteile gg. der Tasmota-Lösung haben.

Ich sehe einen weiteren Vorteil der ESPNow-Lösung: das GW kann auch seriell angeschlossen werden, man braucht also keine "klassische" (W)-LAN-Infrastruktur.

Trotzdem wird auch ESPNow vermutlich nie die Batterie-Performance haben, die man mit MySensors oder AskSin++ erreichen kann - und mit der NRF52-Plattform gäbe es für MySensors auch eine "lötfreie" bzw. "lötreduzierte" Variante...

Aber sei's drum, es könnte eine Alternative für "Löteinsteiger" sein, von daher: Willkommen im Club!

Mittlerweile gibt es dazu auch 2 Module für FHEM (SHRDZM, SHRDZMDevice).
Ein separates GW-Modul wird man dafür wohl brauchen, aber wir können uns gerne auch austauschen, ob man MYSENSORS_DEVICE ggf. "aufbohren" kann, um diese Art Client zu bedienen. Tendenziell würde ich heute aber dazu raten, schlicht MQTT2_DEVICE als Client zu nutzen, das kann das Meiste von alleine, wenn man die übergebenen Daten entsprechend aufbereitet.
Falls da Gesprächsbedarf besteht: Einfach melden.
Titel: Antw:Sensor Platform basierend auf ESP mit FHEM Modulen
Beitrag von: saghonfly am 16 Juni 2020, 15:42:07
Hallo,

 danke erstmal für diese ersten Anregungen, Fragen und auch validen Bedenken.
Ich versuch im Folgenden auf diese einzugehen.
Bitte verzeiht wenn ich was übersehen haben sollte bzw. trotzdem Fragen/Bedenken offen bleiben sollten.

Zitat
BATTERIEBETRIEB!
Tatsächlich steht das ganz oben auf der Motivationsliste.
Dies ist auch einer der Gründe auf ESPNow zu setzen. Mit diesem Ansatz ist es möglich, innerhalb von ein paar hundert Millisekunden die Messung sowie den Datentransfer abzuarbeiten.
Den Rest der Zeit legt sich das Device dann schlafen.
Bei den ESP's ist das 2.4GHz Funkmodul auch schon eingebaut was wiederum zum ESP geführt haben.
Das Argument das ESP's an sich nicht sehr Stromsparend sind, ist valide (das gilt auch für den DeepSleep Mode). Ein paar Monate hält heute ein Sensor-Device durch (mit einem billigen 2.4Ah 18650-Akku), angedachte Optimierungen bei der Up-Time sollten das aber noch verbessern.

Zitat
ich hatte deinen Thread erst gesehen, nachdem ich Interesse für ESP-Now bekundet habe.
Anscheinend bist du ein Experte in diesen und anderen Dingen und kannst mir gelegentlich unter die Arme greifen.

Im Moment kann ich das Projekt aus Zeitgründen noch nicht starten, würde mich aber bei Zeiten melden, ich hoffe, das geht in Ordnung.
Als Experte würde ich mich nicht sehen, versuche es aber besser zu verstehen und bestmöglich zu benutzen.  :)
Selbstverständlich gebe ich mein Wissen diesbezüglich gerne weiter, bin aber sehr daran interessiert wenn sich jemand findet der auch Tipps für die optimale Benutzung geben kann.

Zitat
Ich sehe einen weiteren Vorteil der ESPNow-Lösung: das GW kann auch seriell angeschlossen werden, man braucht also keine "klassische" (W)-LAN-Infrastruktur.
Ja, die Gateways machen die Abstraktion zur Infrastruktur. Die Sensor-Devices selbst sind von dieser unabhängig.
Die Sensor-Devices werden letztendlich nur mit dem gewünschten Gateway gepaart und brauchen diesbezüglich auch keine Konfiguration.

Zitat
Ein separates GW-Modul wird man dafür wohl brauchen, aber wir können uns gerne auch austauschen, ob man MYSENSORS_DEVICE ggf. "aufbohren" kann, um diese Art Client zu bedienen.
Das mit den eigenen FHEM Modulen ist [bisher zumindest] Absicht.
Ein Ziel des Projektes war es auch bestmöglich eine End-zu-End Lösung anzubieten.
Mit den FHEM Modulen soll die Einbindung in die gewählte Hausautomatisierungslösung auch bestmöglich von der Infrasturkturentscheidung getrennt sein.
Ich würde diese derzeit eher als Komfortfunktion sehen. Eine 'native' Einbindung direkt über seriell oder MQTT ist auch möglich aber dann halt nicht in einem Modul gekapselt.
Inwieweit man das MYSENSORS_DEVICE aufbohren könnte, kann ich nicht beurteilen, finde die Idee aber interessant.

Beste Grüße
Erich

Titel: Antw:Sensor Platform basierend auf ESP mit FHEM Modulen
Beitrag von: Beta-User am 16 Juni 2020, 15:55:00
Das mit den eigenen FHEM Modulen ist [bisher zumindest] Absicht.
Ein Ziel des Projektes war es auch bestmöglich eine End-zu-End Lösung anzubieten.
Mit den FHEM Modulen soll die Einbindung in die gewählte Hausautomatisierungslösung auch bestmöglich von der Infrasturkturentscheidung getrennt sein.
Ich würde diese derzeit eher als Komfortfunktion sehen. Eine 'native' Einbindung direkt über seriell oder MQTT ist auch möglich aber dann halt nicht in einem Modul gekapselt.
Inwieweit man das MYSENSORS_DEVICE aufbohren könnte, kann ich nicht beurteilen, finde die Idee aber interessant.
Zwischenzeitlich hatte ich einen kurzen Blick auf das Wiki und die Erläuterung zu den Modulen. Von daher scheint da einiges an spezifischer Funktionalität drin zu sein, die es eher erschwert, da was gemeinsames zu machen.
Spontan war mein Eindruck, dass es (zwischenzeitlich) nicht besonders glücklich ist, das von externen (MQTT-) libs abhängig zu machen. Eine Lösung, die eher in Richtung MQTT2-Module ginge, wäre vermutlich aus Usersicht einfacher, aber dazu müßtest du vermutlich den Code nochmal entsprechend überarbeiten.

Vermutlich wäre MQTT2_DEVICE heute schon flexibel genug, auch die speziellen setter abzubilden, allerdings wäre das dann eher eine Art offenes Konstrukt, was eher nicht zur allg. Architektur paßt.
Titel: Antw:Integration Platform basierend auf ESP mit FHEM Modulen
Beitrag von: saghonfly am 31 August 2020, 19:27:21
Status-Update



Nähere Information gibt es auf https://github.com/saghonfly/shrdzm/wiki (https://github.com/saghonfly/shrdzm/wiki)
Titel: Antw:Integration Platform basierend auf ESP mit FHEM Modulen
Beitrag von: Billy am 07 September 2021, 17:26:48
Status-Update
  • Mittlerweile ist Integration Style III (Mobile Integration) implementiert.
    Hierfür wird ein SIM800 GSM-Modul direkt mit dem SHRDZMGateway verbunden.
    Damit ist es möglich, die SHRDZMDevices mobil zu verwenden (zB.: im Wohnmobil).
  • Im Prinzip werden nun auch Aktore unterstützt. Dies ist aber noch in einem sehr rudimentären Zustand und wenn es jemanden jetzt schon interessiert dann bitte melden da die Dokumentation noch nicht auf neuestem Stand ist.

Die Anwendung Integration Style III mit SIM800 GSM-Modul finde ich äußerst interessant.
Ist es möglich den Sonoff Basic als Aktor einzubinden, indem man die SHRDZMDevice.ino.generic.bin auf den Sonoff flasht?

Um zum Beispiel den Kühlschrank im Gartenhaus/Ferienhaus einschalten zu können?

Vielen Dank für deine Mühe ist ein tolles Projekt.
Gruss Billy