Hallo,
Ich habe mir mit einem NodeMCU einen kleinen Fenstersensor gebaut.
Ablauf:
Gerät ist im Tiefschlaf und wird alle 30s geweckt
Prüfung Fensterstatus (Geschlossen/Geöffnet)
Wenn sich der Fensterstatus geändert hat, wird eine WiFi Verbindung aufgebaut und der Status per MQTT an HA übertragen.
Funktioniert soweit ganz gut, aber ich bin nicht ganz zufrieden damit, dass das Aufbauen der WiFi Verbindung teilweise recht lange dauert (15-20s). Das ist ja CPU Zeit, die da verbraten wird und zu Lasten der Akku-Laufzeit geht.
Daher bin ich jetzt am überlegen, wie ich das System optimieren kann, um den Stromverbrauch evtl zu reduzieren.
Mein erster Ansatz wäre, WiFi durch ZigBee zu ersetzen. Soweit ich das verstanden habe, sollte das damit schneller und effizienter funktionieren.
Nachteil wäre, dass ich nochmal ein zusätzliches ZigBee Modul bräuchte und damit mein Sensor ingesamt größer werden würde.
Alternativ habe ich überlegt, evtl einen anderen μC zu verwenden, der ZigBee schon an Board hat. Kann hier evtl jemand etwas empfehlen?
Ich habe das hier gefunden: Seeed XIAO ESP32-C6
Hat da evtl jemand schon Erfahrung mit?
darfs vielleicht gleich ein fertiger Sensor sein?
zB. ein Sonfoff SNZB-04P fertig für 15,xx USD evtl. auch noch günstiger zu finden.
Ansonsten finde ich, so ein Microcontroller soll bei Fensterstatus Änderung senden.
Und vieleicht einmal am Tag eine Statusmeldung z.B. wegen dem Batteriestand.
Wäre es nicht sinnvoller, den Controller durch einen externen Interrupt zu wecken? Dieser wird ja sicher mit einem, wie auch immer gearteten, Schalter am Fenstern verbunden sein.
Dann muss der Controller doch nur etwas machen, wenn sich der Status des Schalters ändert.
ich habe mir vor 3 Jahren diesen Sensor entwickelt und gebaut:
Mittlerweilen würde ich einen ATtiny1604 oder ATtiny1614 dafür nehmen und den TPL5111 weglassen, da der ATtiny einen Schlafstrom von ca. 700nA hat, und sich dabei periodisch wecken lässt.
Aktuell ist es so, dass ich mit einem Distanz-Sensor arbeite (den hatte ich halt noch rumliegen), der den Abstand zwischen Fensterbrett und Fensterrahmen misst, daher muss ich regelmäßig "manuell" messen. Aber ich werde mir wohl noch einen Reed-Schalter holen und es dann damit machen
Ich nutze jetzt schon fast 3 Jahre die Door.Sens von @SpaghettiCode. Bisher noch kein Absinken der Spannung zu sehen. Ich bin immernoch begeistert
Hier ein Video vom Prototyp.
Die LEDs sind dort nur symbolisch, um zu sehen ob die Zustände Zu=Rot, Offen=Grün, Gekippt=Aus richtig erkannt wurden.
Inzwischen blitzen sie nur kurz, um Status des Sendens zu erkennen, wie beim Orginal.
Wobei ich die 15 - 20 Sek. für zu lange halte. Evtl. ist auch nur ei Fehler in deinem Sketch, der beseitigt werden kann.
Als Beispiel, meine ESP8266 brauchen ca. 3 - 5 Sek. und die ESP32-C3 sogar noch weniger.
Für die meisten nodeMCU ESP32er gilt das: selbst im deepsleep noch 8 bis 15 mA.
Es gibt aber einen Hersteller der für 10 Euro ein auf Stromsparen durchoptimierten ESP32 anbietet.
Der verbraucht im deepsleep wirklich nur 15 µA = 0,015 mA
Die Idee mit Signalpegelwechsel aus dem deepsleep aufwecken finde ich gut.
Dann kann er immer so lange im deepsleep bleiben bis sich der Schaltzustand ändert.
Eine ESP-NOW-Nachricht ist innerhalb von 0,5 Sekunden abgesetzt. Aufwachen ESP-NOW absetzen sofort wieder schlafen legen.
Du musst dann eben einen weiteren EPS32 in Betrieb haben der die ESP-NOW-Nachricht empfängt. Der kann dann per Netzteil versorgt sein.
Also ich habe mir jetzt mal ein paar Reed-Sensoren (NO) und einen Xiao ESP32C3 geholt, um damit das Ganze nochmal etwas sauberer zu machen.
Aktuell sieht meine geplante Logik folgendermaßen aus:
Reed-Sensor hängt an Pin D2, direkt verbunden mit GND
Ich möchte den MC über den Reed-Sensor aufwecken, wenn das Fenster geöffnet und geschlossen wird
Beim Start checke ich mit INPUT_PULLUP auf D2, ob Reed-Sensor offen/geschlossen ist
Je nach Pin Status setze ich ESP_GPIO_WAKEUP_GPIO_LOW oder ESP_GPIO_WAKEUP_GPIO_HIGH für "esp_deep_sleep_enable_gpio_wakeup" auf Pin D2
MC geht schlafen
Macht es Sinn, das so anzugehen, oder übersehe ich etwas?
Anbei nochmal ein Schaubild der geplanten Verkabelung:
kannst du mir bitte mal die Beschriftung der Microcontroller-Pins in deinem Verkabelungsbild vorlesen? Also ich meine du schaust das BILD an das du gepostet hast und dann liest du die Beschriftung vor.
Wie ? geht nicht? Ach da ist gar keine Beschriftung? Na das is jetzt aber blöd!
Eben wollte ich schon sagen diese Frizzing-Bilder sind Verkabeln nach Zahlen. Aber es ist ja noch nicht mal das.
Wenn jetzt jemand deine Schaltung wirklich nachvollziehen will dann muss er sich das Pinout besorgen und dann die Pins durchzählen.
Deswegen ist ein ruckzuck freihand gezeichneter Schaltplan professionell.
Weil:
Wenn es so programmiert wird dann muss der ESP32 jeden Wechsel auch wirklich mitbekommen. Wenn ein Wechsel nicht detektiert wird dann würde er beim nächsten Wechsel nicht reagieren.
Beispielablauf:
Fenster zu Eingang ist LOW
ESP_GPIO_WAKEUP_GPIO_HIGH ist eingestellt
Jetzt wird das Öffnen des Fensters nicht detektiert
=> Keine Meldung
Das Fenster wird wieder geschlossen Eingang wird LOW
da aber immer noch
ESP_GPIO_WAKEUP_GPIO_HIGH eingestellt ist
auch keine Meldung
sondern erst beim nächsten Öffnen.
Unter diesen Randbedingungen bin ich dann doch wieder für
in gewissen Zeitabständen aufwecken und IO-pin-Pegel einlesen.
Dazu würde ich mal messen wie lange das Aufwecken und ESP-NOW-Nachricht absetzen dann wieder schlafen legen dauert.
