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.
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.
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.
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.
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