[Request] Nachts NRF inaktiv schalten

[SpaceTeddy]

Hi,
besten Dank für das tolle Projekt. Ich benutze die openDTU sehr gerne und bin über das Web design und die Stabilität sehr begeistert.
Allerdings fehlt mir eine Möglichkeit die Kommunikation vom NRF zum Inverter anzuhalten, da ich das sinnlose polling über 10-12h einfach unnötig finde. :) Ich hätte zwei Wünsche zur Implementierung:
a) mqtt command um die Kommunikation individuell ein/ausschalten zu können (Prio 1).
b) eine automatische Erkennung wie z.B. Ahoy über sunset / sunrise und GPS Daten (Prio 2). Dies wäre allerdings auch für User ohne externen Control-Server besser.

Eine deep-sleep Lösung wie hier schon mal geschrieben #397 ist natürlich auch super klasse, allerdings auch nur, wenn man diese per Web oder mqtt command mit aktivieren, oder deaktivieren kann.

lg,
Chris

[kpwg]

Hallo Chris,
dürfen wir noch das "Sparziel" erfahren? Ich habe mir zum Thema auch schon so meine Gedanken gemacht, einige Datenblätter gewälzt und Teile für ein zweites OpenDTU-Set gesammelt. Mit Schätzungen werden wir hier nicht weit kommen, es fehlen Messungen. Ich plane den Aufbau an einem der nächsten Wochenenden ein.

Beim "sinnlosen Polling" sollten wir daher genau schauen, ob es lohnt. Der Hersteller meint, das "11.3mA TX" und "13.5mA RX at 2Mbps air data rate" benötigt werden https://infocenter.nordicsemi.com/pdf/nRF24L01P_PS_v1.0.pdf, das macht somit eine Eingangsleistung von 0.037W für TX und 0.045W für RX. Selbst bei 100% Sendezeit können wir pro Kalenderjahr nur 0.3kWh einsparen. In der Praxis dürfte die Ersparnis deutlich darunter liegen, da das Funkmodul nicht ständig sendet oder empfängt, sondern auch in "sleep" läuft.

[SpaceTeddy]

Hi kpwg,

naja, es geht mir nicht wirklich um die Energieeinsparung des OpenDTU Systems, sondern generell finde ich es überflüssig einen Slave zu pollen, wohlwissend dass er niemals antworten wird. Falls es zu komplex ist es einzurichten, könnte man auch einfach das Pollen hard von 00:00 bis 05:00 abschalten, dann hätte man schon mal 5std RF Verschmutzung gespart.
Mehr wollte ich eigentlich nicht :)

Wenn ich abends von der Arbeit komme lass ich mein Auto auch nicht laufen, wenn ich morgens um 0600 wieder damit losfahren will. 😉.

Lg,
Chris

[b-a-9-0]

Man könnte im Webinterface eine Eingabemaske mit Standort Koordinaten implementieren und dann mit einer Sunrise Lib (z. B. https://github.com/JChristensen/JC_Sunrise) die Kommunikation abschalten. Ich wäre auch aus o. g. Gründen dafür.

[kpwg]

Hallo miteinander,

wenn es nicht um die Energieeinsparung geht, was ist dann das Sparziel? Die Funktion macht doch nur Sinn, wenn sie im Ergebnis irgend eine Verbessung bringt, welche den verbrauchten Speicher rechtfertigt. Versteht mich nicht falsch, das Feature ist interessant, aber was ist danach besser?

Habt ihr das verlinkte Dokument gelesen?
In Bezug auf das Argument "5h RF Verschmutzung" merke ich an, die die meisten von uns sicher die Standard-Einstellung mit -12dBm nutzen. Ich habe damit gute Erfahrung gemacht, das geht auch durch mehrere Wände. Um die Zahl etwas greifbarer zu machen, rechne ich das mal um: es entspricht 63 mikroWatt am Ausgang des Senders, was einem sehr geringen Bruchteil der HF entspricht, die sonst so in unseren Haushalten unterwegs ist. Wenn also die HF Verschmutzung messbar reduziert werden soll, müssen zuerst alle Handys in der Familie abgeschalten werden, WLAN im Haus aus, DECT aus, alle Smartwatches aus, SmartHome aus, Computer aus, usw.
Damit könnte man die HF Verschmutzung ansatzweise reduzieren, sollte aber auch noch alle Nachbarn, Mobilfunkmasten, Radiosender und sonstige Funkanlagen berücksichtigen, sonst war der Rest umsonst.

Zudem ergeben sich mit dem Feature noch zwei weitere Baustellen:

• Angenommen ich habe eine freie Ost-Ausrichtung, da nach Westen ein Gebirgszug beschattet, möchte ich früh gerne ab der ersten Minute Strom ernten, aber ab 16.00 benötige ist dann keine Verbindung mehr, da komplett im Schatten (Die Zeiten sind durchaus reale Bespiele). Wie soll ich das einstellen? Korrekturzeiten einführen? Eine pauschale sunset/sundown Funktion greift hier nicht.
• Durch versehentliche Aktivierung (ja, davon muss man stets ausgehen) erhöht sich am Ende immer der Supportaufwand, das gerade zu biegen.

Bitte studiert nochmal ernsthaft das Datenblatt und das Protokoll, lest Euch zu den Grundlagen der HF-Technik ein (dB-Rechnung, Freiraumdämpfung, etc.) und nennt mir dann ein echtes Argument für diese Funktion.

LG

... und das Ganze ist nicht böse gemeint.

[OFreddy]

Hallo zusammen.

Natürlich ist das sicherlich Quatsch mit dem Abschalten des NRF in der Nacht.

Wenn es trotzdem jemand interessiert oder er es nützlich findet:
Ich habe eine Implementierung in meinem Fork: https://github.com/OFreddy/OpenDTU

Kommentare, Anregen oder Erweiterungswünsche sind herzlich willkommen.

Viele Grüße

[muibusan]

Hi!

Die Entscheidung, ob das jemand nutzen will oder nicht, könnte man doch einfach jedem Anwender überlassen. :) Wenn das jemand als Quatsch empfindet, läßt er die Funktion einfach ausgeschaltet und guts ists. Und die anderen Anwender, die sich sowas wünschen, sind glücklich, wenn es das Feature gibt. Offenbar gibt es bei manchen Anwendern den Wunsch nach sowas. Und als ganz und gar von der Rolle würd ich es auch nicht bezeichnen: Es läßt sich wie @OFreddy zeigt recht leicht implementieren und OpenDTU bleibt auch mit diesem Feauture ein tolles Stück Software. :)

[SpaceTeddy]

Hi OFreddy,
ich habe deinen Branch aufgespielt und prüfe die neue Funktion. Danke dafür.

[b-a-9-0]

Danke, werde es mir auch anschauen und in mein Repo übernehmen.

[LarsRaw]

Deshalb bin ich für kompletten DeepSleep, dann ist WLAN + NRF aus. Und bei mir Garten (Insel) zählt eben jede Wattstunde :) Besonders im Winter + Schnee

[tbnobody]

Implemented in cd99ab8

[Zackzarack1]

Hi OFreddy,
danke für die Implementierung der DeepSleep Funktion. Ein ESP läuft bereits seit April absolut stabil damit. Ich bevorzuge den ESP nachts komplett schlafen zu legen. Bei der aktualisierten Version ist mir folgendes aufgefallen: Es gibt jetzt "nur" Deepsleep Periode" in Sekunden. Heißt das ESP geht nur für die eingestellte Anzahl in den Deepsleep Modus und bootet dann erneut, um sich im Anschluss erneut schlafen zu legen - währen der der NTP-Modus auf Nacht steht? Bei der älteren Implementierung gab es zwei Felder "Offset Sonnenaufgang/Sonnenuntergang" in Minuten. Damit war der ESP die ganze Nacht im Deepsleep. Falls das bei der aktuellen Version nicht mehr so ist, finde ich das sehr schade und leider kann ich das alte Binary nicht mehr finden.

[OFreddy]

Hallo Zackzarack1.
Die Felder "Offset Sonnenaufgang/Sonnenuntergang" wurden obsolete durch die Option Dämmerungstyp im Upstream.
An der Implementierung der Deepsleep Funktion hat sich dabei nichts geändert.
Es wird die Deep Sleep Funktion mit Timer Wake up verwendet. Der Controller wird dabei nach Ablauf der eingestellten Zeit neu gestartet. Dabei wird auch die Setup() Methode durchlaufen. Der Intervall wird duch die DeepSleep Periode bestimmt.
Der Neustart ist der Architektur in der ESP32 Core geschuldet.

[Zackzarack1]

Hallo OFreddy,
danke für die Antwort. Bitte entschuldige, wenn ich jetzt noch einmal nachfrage. Eventuell habe ich meine Frage auch nicht genau genug formuliert. Bei der älteren Implementierung von Dir wurde der ESP von Sonnenuntergang bis Sonnenaufgang in den Deepsleep geschickt (dauerhaft). Wenn ich Deine Antwort richtig verstanden habe ist die Funktionsweise jetzt so, dass: Nach Erreichen des Sonnenuntergangs (je nach Dämmerungstyp bei erreichen des Modus Nacht), der ESP für z.B 60s in Deepsleep versetzt und startet dann neu. Dieser Vorgang wiederholt sich dann die ganze Nacht. Gibt es einen Grund warum nicht, wie bei Deiner ersten Version, die Zeiten, die jetzt durch die Dämmerungsfunktion errechnet werden (versehen mit einem Offset) benutzt werden, um den ESP dauerhaft für die ganze Nacht schlafen zu legen und nur 1x am nächsten morgen wieder zu starten?

[OFreddy]

Hallo Zackzarack1.
Ich bin mir nicht sicher wie Du darauf kommst, dass es zuvor anders war.
Ich habe gerade noch einmal in die Commits geschaut. Schon bei der ersten Version vom 20.02.2023 (Commits on Feb 20, 2023)
war es so, dass der ESP für die parametrierte Deepsleep Time (Default 180s) in den Schlaf geht und danach geweckt wird.

 if (Configuration.get().Sunset_Deepsleep) {
        **esp_sleep_enable_timer_wakeup(Configuration.get().Sunset_Deepsleeptime * uS_TO_S_FACTOR);**
        MessageOutput.println(F("SunsetClass - Going to sleep now"));
        delay(1000);
        MessageOutput.flush(); 
        esp_deep_sleep_start();
    }

So wie ich es aus der ESP Doku lese ist der Wakeup per Timer gar nicht anders möglich.
Der Parameter zum setzten des Timers ist ein uint64_t. Angegeben wird die Zeit in us. Sicherlich lässt sich die Zeit dann bis zum nächsten Morgen in us errechnen, dass er dann nur einmal schlafen geht. Mir ist das aber zu unsicher. Momentan sind maximal 300 Sekunden Deepsleep Time parametrierbar. Den Grenzwert kann man sicherlich höher setzten, dadurch verändert sich aber auch die Unschärfe um den Sonnenaufgang herum.

[Zackzarack1]

Hallo OFreddy,
danke für die Aufklärung. Ich hatte einige Zeit einen Energiemesser am Netzteil zum ESP. Da ging ging die Leistung dann auf 0W. Normalbetrieb schwankend zwischen 0.6-1W. Wenn der Defaultwert 180s für Deepsleep war dann erklärt das, warum ich auf dem Messgerät immer die 0W gesehen haben - ich habe da nicht lange genug auf das Messgerät geschaut. Der Rest war dann wohl meine Interpretation der einzustellenden Parameter.
Unabhängig davon habe ich auch ein paar kleine Projekte mit dem ESP umgesetzt, die auf maximales Stromsparen ausgelegt waren (Offgrid Akkubetrieb). Da kämpft man gerne um das letzte Watt. Meine Erfahrung bezüglich länger Deepsleepzeiten waren: Bei Deepseep von 12h gab es bei mir Abweichung in der Zeit von max 2s. Ich denke dieser Fehler wäre bestimmt vernachlässigbar. Vielleicht probiere ich das einfach mal über den Weihnachtsurlaub aus - falls ich Zeit dazu finde. Aktuell beschäftige ich mich noch mit der Steuerung für die Klimaanlage. Leider wird meine nicht direkt von ESPHome oder ähnlichen unterstützt. Das Protokoll habe ich bereits komplett reverse engineered. Jetzt fehlt noch die Umsetzung. :-) Vielen Dank für die schnellen und ausführlichen Antworten und schöne Feiertage

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion or issue for related concerns.