[gelöst] Sonoff "absent"

[dev0]

Zum Posten von Code/Logs bitte die Code Tags verwenden (# Button) und keine Definitionen posten, sondern ein "list" des Device. Siehe angepinnte Beiträge im Anfägerbereich.

Wo ist mein Denkfehler?

Die alten/anderen Devices kannst Du löschen, sie weden nicht mehr benötigt. Es wird nur noch das Device "Sonoff_S20_1" genutzt. Die entsprechen Readings werden in diesem neuen Device angelegt/aktualisiert.

[dev0]

Um einfacher erkennen zu können, ob das combinedDevices Attribut greift, habe ich gerade eine neue Version ins svn eingechekt, die das (ab verbose level 4) im Log protokolliert. Ab morgen 8:00 Uhr via FHEM update verfügbar.

[schizo]

Es funktioniert jetzt
Mein Fehler war noch, dass das Sonoff-Gerät selbst nur "S20_1" heißt, ich in der Bridge aber "combineDevices Sonoff_S20_1" geschrieben hatte.
Das habe ich nun korrigiert, und jetzt konnte ich die danach automatisch erstellten Devices "Info", "Relais" und "Button" löschen.
Die Readings werden jetzt wie gewünscht im Device "ESPEasy_S20_1" gesammelt und ausgegeben.
Vielen Dank!

[cs-online]

wir haben das in einem anderen Thread auch schon mal diskutiert, ich habe für das absent-Problem einfach folgende Lösung:

Code Auswählen Erweitern


attr ESPEasy_WLAN_Dose_6_PUMP Interval 180
attr ESPEasy_WLAN_Dose_6_PUMP pollGPIOs 12

damit wird der GPIO mit dem Relais in dem Intervall (hier alle 3 Minuten) abgefragt und das Reading aktualisiert. Läuft seit Monaten stabil. Wenn ich das Dinge aus der Steckdose ziehe, erscheint nach kurzer Zeit absent, wenn wieder rein ist schnell wieder online...

Grüße

Christian

[dev0]

Das Pollen von GPIO Zuständen ist unnötig und kontraproduktiv, auch wenn Du es (immer noch) nicht glauben magst und es (noch) funktioniert.

[cs-online]

Das Pollen von GPIO Zuständen ist unnötig und kontraproduktiv, auch wenn Du es (immer noch) nicht glauben magst und es (noch) funktioniert.

sorry, hab ich noch nicht verstanden, magst du das mal erklären, warum das nicht gut ist ?

[sbiermann]

Mal ein etwas hinkender Vergleich. Du gehst ja auch nicht alle 3 Minuten in die Küche und guckst ob du noch Milch im Kühlschrank hast. Sinnvoller ist es wenn der Kühlschrank dich benachrichtigt das die Milch alle ist. Sprich mit pollen tust du jede Menge unnötige Arbeit.

[dev0]

@cs-online: Wie sbiermann schon schrieb, ist pollen generell keine gute Idee, besonders dann, wenn es eine bessere Alternative dazu gibt. Der Pollingmechanismus im Modul nutzt zudem auch keine offizielle ESP Easy Schnittstelle, um einen Status, über den "normalen" Weg,  anzufordern (gibt es nämlich nicht), sondern nutzt die JSON Antwort auf eine HTTP Anfrage. Dieses JSON wertet das Modul, dann eher schlecht als recht, aus. Sobald sich an diesem JSON etwas ändert, wird das nicht mehr, ohne Änderungen am Modul, funktionieren. Wenn das passiert, dann werde ich vmtl. das Attribut ganz aus dem Modul entfernen, da es unnötig ist den Zustand zu pollen, denn:

Mittels "Switch Input" Device sendet ESP Easy den Status der GPIOs nicht nur bei Änderungen, sondern auf Wunsch auch in einem konfigurierbarem Intervall (Delay). Damit benötigt man nichtmals mehr den Umweg über combineDevices in Verbindung mit einem zusätzlichen Wert, um das Presencefeature des Moduls nutzten zu können, dass auf dem Alter der Readings beruht. Das ist mindestens seit ESP Easy R90 so...

[cs-online]

ahso, ich verstehe. Dann macht das durchaus Sinn, daß ich mich da zwischen den Feiertagen mal beisetze und das bei meinen ändere. Ich habe hier ca. 10 S20 im Einsatz. Wie gesagt, es sah nach einem recht einfachen Weg aus und bislang war das auch super stabil, deshalb habe ich das bislang favorisiert.

Danke für die Info und ebenfalls für das Modul, das ist richtig cool !!!

Wünsche frohe Weihnachten,

Grüße

Christian

[dev0]

zwischen den Feiertagen mal beisetze und das bei meinen ändere

Ob man das jetzt direkt ändern muss, ist eine andere Frage. Bei einer neuen Installation würde es aber nicht mehr empfehlen. Daher mein veto.