Alternativ hätte man eine Szenenaktion erstellen können, die das automatisch macht und dem Nutzer die Möglichkeit gibt, sie zu programmieren, wann er möchte…
Vorteile: Der Nutzer kann sie programmieren, wann er möchte, das ist mächtig
Nachteile: Weniger „plug-and-play“
Ich denke, dieser Teil sollte schlüsselfertig sein. Andererseits könnte man auch einen Szenenauslöser haben, um die Leistung beizubehalten?
Bei den Benachrichtigungen stimme ich zu, es sollte eine einzige Benachrichtigung für alle Geräte geben, die weniger Batterie haben.
Schließlich habe ich festgestellt, dass einige Aquara-Sensoren von 100% auf 0% fallen oder sich sogar bei 100% abschalten. Sie aktualisieren also nie den Batteriestand.
In diesem Fall machen wir die Funktion schlüsselfertig 
Wenn es mehr Nachfrage gibt (ich denke ehrlich gesagt nicht), werden wir es tun
das können wir leider nichts machen, der Benutzer erhält die Benachrichtigung zu spät (oder nie…)
Geht es darum, eine MQTT-Nachricht zu senden?
Da man jede MQTT-Nachricht abhören kann, wäre das ein Kompromiss. Aber es stimmt schon, man sollte es so einfach wie möglich halten, statt Zeit mit unwichtigen Dingen zu verschwenden.
Machen wir es einfach!
@pierre-gilles: Hier das Ergebnis im „box“-Modus für den Systemkonfigurationsbildschirm
Was hältst du davon?
Ich habe den Cron auf jeden Samstag um 9 Uhr morgens gesetzt. Und ich habe diesen Hinweis in der Beschreibung hinzugefügt
Ich finde das super sauber!
Hyper sauber @Lokkye !
@pierre-gilles
Der PR ist bereit:
Danke für das PR
Ich habe eine Review gemacht: Add warning system for battery level by callemand · Pull Request #1936 · GladysAssistant/Gladys · GitHub
@pierre-gilles: Ich hatte keine Zeit, die Änderungen vorzunehmen. Du hast den Branch bereits gemerged. Mach ich ein kleines PR mit den Mikro-Änderungen?
Hallo, Fehler auf meiner Seite, ich habe dann zurückgesetzt! Du kannst die gesamte PR wieder öffnen!
@pierre-gilles: Ich konnte das PR nicht wieder öffnen, also habe ich gerade ein neues erstellt:
Danke!
Ich habe ein kleines Problem beim Verwenden, das Feld ist etwas seltsam in der Handhabung, es verliert den Fokus bei jeder Eingabe eines Zeichens. Beispiel, um von 10% auf 20% zu wechseln:
Ja, ich habe das auch bemerkt, aber wie bei den anderen Feldern auf derselben Seite verhält es sich genauso. Ich habe nicht mehr Zeit darauf verwendet.
Das Problem kommt vom setState, der einen Neudraw erzwingt und wir verlieren den Fokus.
Ich werde das Problem etwas genauer untersuchen.
Ach Mist, stimmt, ich habe das gleiche Problem mit „Frist bis zum Ablauf eines Status“!
Halte mich auf dem Laufenden
Also, das Problem kommt von der Eigenschaft „disabled“, die an den Zustand der Wertesicherung gebunden ist. Im Moment ist alles in Ordnung, wenn man diese Bindung entfernt, aber es gibt keine Rückmeldung auf Seiten der Sicherung. Aber ich habe den Eindruck, dass die anderen Komponenten, die keine Eingabe verwenden, auch keine Rückmeldung von der Sicherung haben.
Passt es dir, wenn wir die Bindung entfernen?
Mmm so wie das ist, ist es schwer zu wissen, wie es aussieht, sieht es gut aus?
Ich habe den Code commit/push gemacht Das wird klarer sein
Ok tatsächlich ist es viel besser!
Noch etwas, dadurch wird die Validierung so komisch, aber ich weiß, dass es an anderen Stellen in Gladys genauso ist (z. B. auf dem Dashboard, um den Namen eines Geräts zu bearbeiten).
Beispiel: Wenn ich 20 habe und 30 eingeben möchte, passiert das, wenn ich das 20 mit „Backspace“ zweimal lösche (eine 0 wird eingefügt).
Ich weiß nicht, was wir tun könnten, um die Validierung von der Eingabe zu trennen. Ein längerer Debounce?
