Verschiedenes > Projekte

Integration Platform basierend auf ESP mit FHEM Modulen

(1/4) > >>

saghonfly:
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


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

M.Schulze:
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

MadMax-FHEM:
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

PeMue:
Hallo,


--- Zitat von: saghonfly am 29 Mai 2020, 19:03:47 ---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.

--- Ende Zitat ---
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

saghonfly:
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.
--- Ende Zitat ---
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.
--- Ende Zitat ---
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

Navigation

[0] Themen-Index

[#] Nächste Seite

Zur normalen Ansicht wechseln