Hi!
Ich bin leider mit manchen Item-Feldern immer noch nicht ganz glücklich:
Ausgangslage: Onewire-Binäreingang (gott sei dank mein letzter...) auf Basis DS2401 / iButton - sporadisch schlägt der ca. alle 5,x Sekunden ausgeführte Read fehl und damit wird "False" zurückgegeben. Beim nächsten Durchlauf wird das Ding wieder gefunden und alles ist gut. Leider ist das in Vergleich zu den 100% zuverlässigen KNX-Eingängen ärgerlich wenn man daran den "Alarm" hat.
Idee dahinter: Wenn im letzten Zyklus der gleiche Wert gelesen wurde übernimm ihn, sonst behalte den aktuellen Wert.
Problem: Trotz gesetzten "enforce_updates" hat "prev_value" immer den negierten Wert, da es nur bei einem "echten" Wechsel aktualsiert wird. Das macht solche schönen Lösungen unmöglich und ich frage mich: Wem hilft das?
Die "Leistung-aus-Arbeit-durch-Zeit"-Fraktion (zu der ich auch gehöre) würde:
Was spricht dagegen, "prev_value" bei "enforce_updates" mit zu aktualisieren?
Annahme: wenn ich "enforce_updates" setze, möchte ich das JEDES update genau so behandelt wird, als wenn sich der neue Wert vom alten unterscheiden würde. Eben ein "enforce updates". Alles, wo nur ein Teil dieser Annahme folgt, stiftet doch Verwirrung?
Eine Lösung wäre natürlich
Einerseits kann man so natürlich auch 3 Lesezyklen zur Bedingung machen, andererseits ist man dann eben abhängig von den Leseintervallzeiten und der Code ist "komplizierter".
Nebenbei: Wer nutzt im sh.py Universum iButtons? Habt ihr nie Fehldetektionen? Ansonsten würde es evtl. lohnen, im Onewire-Plugin ein "wenn nicht gefunden, versuche es in x < cycle noch mal" eizubauen.
Grüße
Robert
Ich bin leider mit manchen Item-Feldern immer noch nicht ganz glücklich:
Ausgangslage: Onewire-Binäreingang (gott sei dank mein letzter...) auf Basis DS2401 / iButton - sporadisch schlägt der ca. alle 5,x Sekunden ausgeführte Read fehl und damit wird "False" zurückgegeben. Beim nächsten Durchlauf wird das Ding wieder gefunden und alles ist gut. Leider ist das in Vergleich zu den 100% zuverlässigen KNX-Eingängen ärgerlich wenn man daran den "Alarm" hat.
Code:
[Kinderbad] [[Fenster_verriegelt]] type = bool cache = true knx_dpt = 1 knx_send = 6/2/105 knx_reply = 6/2/105 eval_trigger = Kinderbad.Fenster_verriegelt.Raw eval = value if (value == sh.Kinderbad.Fenster_verriegelt.Raw.prev_value()) else self() [[[Raw]]] type = bool enforce_updates = true ow_addr = 01.241E29150000 ow_sensor = B
Problem: Trotz gesetzten "enforce_updates" hat "prev_value" immer den negierten Wert, da es nur bei einem "echten" Wechsel aktualsiert wird. Das macht solche schönen Lösungen unmöglich und ich frage mich: Wem hilft das?
Die "Leistung-aus-Arbeit-durch-Zeit"-Fraktion (zu der ich auch gehöre) würde:
- eh nicht enforce_updates setzen wenn der Zählerstand übertragen wird weil sonst zusätzliche Leseanfragen das ganze durcheinander bringen
- wenn nur der Impuls übertragen wird (mit enforce_updates) ist es egal, da letzter und dieser Wert ja gleich sind (sonst bräuchte es "enforce_updates" ja nicht).
Was spricht dagegen, "prev_value" bei "enforce_updates" mit zu aktualisieren?
Annahme: wenn ich "enforce_updates" setze, möchte ich das JEDES update genau so behandelt wird, als wenn sich der neue Wert vom alten unterscheiden würde. Eben ein "enforce updates". Alles, wo nur ein Teil dieser Annahme folgt, stiftet doch Verwirrung?
Eine Lösung wäre natürlich
Code:
eval = value if ((sh.now()-sh.Kinderbad.Fenster_verriegelt.Raw.last_change()).total_seconds() > 10) else self()
Nebenbei: Wer nutzt im sh.py Universum iButtons? Habt ihr nie Fehldetektionen? Ansonsten würde es evtl. lohnen, im Onewire-Plugin ein "wenn nicht gefunden, versuche es in x < cycle noch mal" eizubauen.
Grüße
Robert
Kommentar