Hallo,
Wo kann ich denn den aktuellen Sleeptimer-Stand abfragen?
Bei MQTT wird im State nur der Wert angezeigt, den ich per CMD übermittelt hab.
Auf dem Web-Interface habe ich auch keinen Wert irgendwo gefunden.
Danke vorab für die Hilfe
Per Default gibt es keinen Sleeptimer. Insofern macht’s Sinn, dass du den im State siehst, den du per CMD übermittelt hast.
Im Webinterface ist der Sleeptimer nicht aufgeführt.
Dann wäre das doch ein schönes feature zur Implementation.
Der Timer funktioniert ja, wo wird der denn gemacht?
Gruß
Thomas
In der System.cpp: System_SetSleepTimer()
Gibt auch schon einen GETer dafür: System_GetSleepTimer().
Hallo,
bin da leider auch nicht viel weiter gekommen.
Es müsste ja ein Wert sein, der sich wie folgt zusammensetzt:
(Aktuelle Zeit - (Timer-Start-Zeit + Timerwert))
Aber dafür reichen meine Kenntnisse bei weitem nicht aus.
Vielleicht kann mir da jemand unter die Arme greifen?
Gruß
Thomas
Vielleicht schafft es einer, in einer der nächsten Versionen, einen Rückgabewert der Rest-Timer-Zeit mit einzupflegen und per MQTT dann zu übermitteln.
Ich habe definitiv zu wenig Programmierkenntnisse dazu…
Vorab vielen Dank für eure Mühe
Habe inzwischen meine Boxen auf den aktuellen Stand gebrach und sogar ein Update OTA gemacht.
Ist echt super wie sich das Projekt inzwischen entwickelt hat.
Ich bin sehr stolz auf euch!!!
Vielleicht gibt es ja inzwischen auch einen, der das Programm entsprechend anpassen kann, dass der Rest-Timer-Wert per MQTT ausgegeben werden kann.
In meine Hausvisualisierung könnte ich dann sehen, ob meine Kids die Box nicht inzwischen neu gestartet haben, um den Timer zu umgehen.
Die finden immer für alles irgend einen Weg…
Reden wir von der Zeit, bis ESPuino in den Deepsleep geht, nachdem ein Schlafmodus gestartet wurde?
Ja, wenn ich den Sleeptimer auf z.B. 30 min stelle, wäre es super, wenn ein Wert über mqtt kommen würde, wie viele Minuten es bis zum Deepsleep noch sind.
Das Thema ist nicht ganz so einfach. Also bei den fest zeitlich orientierten Schlafmodi kann ich einfach zB alle 10s die Restlaufzeit pushen - denn die kenne ich ja, da sie intern auch verwaltet wird. Bei EOT/EOP/EO5T sieht das anders aus - da weiß ich die Restlaufzeit nicht. Mir fällt jetzt ad hoc kein Weg ein, mit dem ich das generisch löschen könnte.
Du wirst das lokal bei dir lösen müssen. Beispielsweise das Topic für software_revision wird nur beim Neustart aktualisiert. Den Zeitpunkt der letztmaligen Aktualisierung wird, das weiß ich aus Erfahrung, mind. mal bei OpenHAB und Home Assistant gespeichert. Das kannst du auswerten und siehst dann, ob ein Neustart stattgefunden hat.
Die Restlaufzeit des normalen Schlaf-Modus würde mir schon vollkommen reichen
Hallo zusammen,
ich habe einen Test-Fix für die MQTT-Ausgabe des Sleep-Timers erstellt.
Aktuell wird der Sleep-Timer über MQTT nicht fortlaufend aktualisiert. Zusätzlich wurde beim Verbindungsaufbau teilweise der interne Startzeitpunkt statt der eingestellten Zeit gesendet und beim Abschalten teilweise das falsche Topic verwendet.
Mein Testbranch basiert auf dem aktuellen dev:
Die Änderung soll:
- beim Setzen sofort die eingestellte Zeit senden,
- die verbleibende Zeit minütlich aktualisieren,
- beim Abschalten
0übertopicSleepTimersenden, - beim MQTT-Reconnect den aktuellen Zustand ausgeben.
Bei 30 Minuten sollten ungefähr folgende Werte kommen:
30, 29, 28, ... 1, 0
Könnte das bitte jemand testen? Besonders interessant wären:
- normaler Minuten-Timer,
- manuelles Abschalten mit
0, - MQTT-Reconnect während eines laufenden Timers,
EOT,EOPundEO5T.
Der Code ist bisher als Test gedacht und noch nicht umfassend geprüft.
Hallo zusammen,
ich habe den MQTT-Status des ESPuino-Sleeptimers erweitert.
Das bisherige Topic sleepTimer bleibt unverändert und damit weiterhin vollständig abwärtskompatibel. Es liefert wie bisher Minutenwerte sowie die Werte EOT, EOP, EO5T oder 0.
Zusätzlich gibt es nun vier neue retained MQTT-Topics:
sleepTimerModesleepTimerActivesleepTimerRemainingMinutessleepTimerRemainingTracks
Für sleepTimerMode sind folgende Werte vorgesehen:
OFFMINUTESEOTEOPEO5T
Beispiel für einen aktiven 30-Minuten-Timer:
sleepTimerMode = MINUTES
sleepTimerActive = 1
sleepTimerRemainingMinutes = 30
sleepTimerRemainingTracks = 0
Die verbleibenden Minuten werden während des Countdowns einmal pro Minute aktualisiert.
Bei EO5T wird zusätzlich die verbleibende Anzahl der Titel ausgegeben und bei jedem Titelwechsel aktualisiert:
sleepTimerMode = EO5T
sleepTimerActive = 1
sleepTimerRemainingMinutes = 0
sleepTimerRemainingTracks = 5
Beim Ablauf oder beim Abbrechen eines Timers werden die retained Werte sauber zurückgesetzt:
sleepTimerMode = OFF
sleepTimerActive = 0
sleepTimerRemainingMinutes = 0
sleepTimerRemainingTracks = 0
Das Zurücksetzen erfolgt noch vor dem Deep Sleep. Dadurch bleibt im MQTT-Broker kein veralteter Timerstatus stehen, wenn der ESPuino anschließend offline ist.
Getestet habe ich:
- Minuten-Timer mit Countdown
- Abbrechen des Timers
- Ende des aktuellen Titels (
EOT) - Ende der Playlist (
EOP) - Ende nach fünf Titeln (
EO5T) - Playlist-Wiederholung
- MQTT-Neuverbindung
- retained Status nach dem Einschlafen
Der PlatformIO-Build für lolin_d32_pro_sdmmc_pe läuft erfolgreich durch.
Pull Request:
Über Rückmeldungen und Tests mit anderen Boards oder Konfigurationen würde ich mich freuen.
-
Warum retained? Wenn da ein ESPuino reinschreibt und dann „ungeordnet“ ausgeschaltet wird, dann lebt da ein falscher Wert drin.
-
Insgesamt finde ich es auch reichlich viel, für diese relativ unwichtigen Informationen, insgesamt fünf State-Topics zu haben. Ich denke es wäre besser, das in ein Topic zu packen und ein JSON draus zu machen. Ich weiß, das haben wir bisher nicht gemacht (hätten wir aber mal machen sollen), aber hier halte ich es für angebracht.
-
Im Code sind teilweise deutsche Kommentare drin.
-
Der PR zeigt auf master statt auf dev.
Fachlich habe ich es mir noch nicht angeschaut.
@TMHEINE Ich habe mir das Ganze nochmal angeschaut und nehme nochmal auf meine Punkte Bezug:
1: Wenn, dann müssten wir die ganze MQTT-Implementierung auf retained + LWT umstellen. Wäre ich offen für. Aber nur das Feature hier umzustellen, wäre insgesamt auf jeden Fall inkonsistent.
2: Das würde ich wie gesagt gerne ein bisschen konsolidieren, so dass es nicht zu viele Topics werden. JSON-Topics auszuparsen ist mit HA kein Problem.
3: Die müsste man ersetzen.
4: Da braucht’s ein Rebase
Dazu on top:
5: Wir haben jetzt eine gewisse Form von Code-Duplikation durch System_SleepHandler() und Mqtt_PublishSleepTimerState(). Das sollte man in einem Helper konsolidieren.
6: Clang-format muss da nochmal drüberlaufen.
Angebot: Ich kann das alles in einen PR packen und dann kannst du das testen. Ich will hier nur nicht ungefragt einen „Hijack“ deiner Idee machen. In Sachen Retained + LWT würde ich dann aber in einen eigenen PR machen, da das über dieses Thema hier hinaus geht.
Hallo,
ich war leider 2,5 Wochen auf Montage.
Sorry, das mit dem Master war ein Fehler, ich hoffe, es kommt nicht wieder vor.
Sollte in der dev landen.
Ich hoffe, ich habe dir nicht all zu viel Mühe und Sorgen bereitet.
Das mit der PR wäre eine super Sache.
Gerne darfst du damit machen, was du willst, oder wie es zum Aktuellen Release passt.
Hatte eigentlich nur ein Test mit ChatGPT und mir ein paar Code-Schnipsel implementiert zum testen. Und es hatte dann auch noch funktioniert.
Ich wollte wirklich nichts durcheinander bringen. Sorry nochmals.
Ich hoffe, du kannst mir nochmals vergeben.
Gut, dann setze ich das entsprechend um, wie ich das vorgeschlagen hatte.
Oh Gott, alles gut 
.
So, ich habe das jetzt mit folgenden Commits in dev umgesetzt:
Das Ganze funktioniert jetzt mit einem zusätzlichen Topic, welches eine JSON-Payload hat:
sleep_timer_state {"mode":"OFF","remainingMinutes":0,"remainingTracks":0}
Mode kann hierbei OFF/MINUTES/EOT/EOP/EO5T sein. Das Feld remainingMinutes ist nur gesetzt, wenn mode=MINUTES. remainingTracks entsprechend, wenn mode=EOT oder EOP oder EO5T. Die alten Topics habe ich, zwecks Abwärtskompatibilität, unverändert gelassen.
@Joe91 Bei der Gelegenheit ist mir noch ein Bug aufgefallen, den ich bisher noch nicht getriggert hatte:
Ich habs mal auf meine 4 Boxen entsprechend ausgerollt.
Bin am Testen. Bis jetzt sieht es gut aus! Danke!