Item filtern/"entprellen" - prev_value sinnvoll?

[JuMi2006]

Ich denke ich habe es jetzt

items.conf

[klingel]
    [[taster]]
        type = num
        knx_dpt = 1
        knx_send = 0/0/50
        knx_reply = 0/0/50
        knx_listen = 0/0/50
        eval = sh.klingel.taster.alarm(1)
    
        [[[alarm]]]
            type = num
            knx_dpt = 1
            knx_send = 0/0/55
            autotimer = 1m = 0

logic.conf

[mail_klingel]
    filename = mail_klingel.py
    watch_item = klingel.taster.alarm

mail_klingel.py

#/logics/mail_klingel.py
#!/usr/bin/env python
# Mail bei Klingel

if trigger['value'] == 1:
    empfaenger = 'mail@provider.com'
    datum =  datetime.datetime.now().strftime("%d.%m.%Y")
    zeit = datetime.datetime.now().strftime("%H:%M:%S")

    betreff = 'Klingel betätigt'
    nachricht = 'Es wurde am ' + datum + ' um ' + zeit + ' geklingelt'

    sh.mail(empfaenger, betreff, nachricht)
    logger.info('Nachricht ' + betreff + ' gesendet')

Für die Nachwelt.

[bmx]

Wie entprellt man denn am Besten?

Ja, die nervösen Postboten oder Verwandten...
Python kann ich leider nicht so aus dem Ärmel also der Versuch:

#Logik ausgeführt bei Ding oder Dong:

if timer() == 0 and Ding:
sende Nachricht
timer(10)
break

if timer() > 0
timer(10)

Gruß,
Bernd

[callidomus]

Hi Mirko,

Aktor umprogrammieren geht nicht?

Wenn nicht, dann würde ich ein kleine Logik direkt an die GA binden.
Diese würde dann ein zweites Item (mit Autotimer) immer auf True setzen lassen.
Der Autotimer setzt es dann wieder auf False.

Bis bald

Marcus

[JuMi2006]

Wie entprellt man denn am Besten?

Folgendes Problem hier:
Klingel hängt am Binäreingang und macht im Idealfall "Ding-Dong".
Damit wird bei "Ding" eine 1 und bei "Dong" eine 0 auf die GA gesendet.

Nun möchte ich dafür irgendeine Aktion auslösen und hab das Problem mit nervösen Postboten. Die klingeln nämlich "Ding-Dong Ding-Dong". Am liebsten hätte ich noch eine Mail oder Nachricht bei Klingelbetätigung und dann bekomme ich es immer doppelt oder dreifach (je nach dem wie nervös der Bote ist). In einer Logik könnte ich natürlich erstmal 10 Sekunden warten und filtern bis eine Nachricht verschickt wird, soll aber das Telefon mitklingeln will ich den Befehl sofort absetzen und das nur einmal.

Jemand eine Idee oder schon was fertig umgesetzt?

Dank und Gruß
Mirko

[Robert]

das die Bedeutung von prev_value für ein WorksForRobert geopfert wird

Wer nutzt diese "Bedeutung" denn?

Wie oben dargelegt ist das Verhalten sinnlos:
- wenn "enforce_updates = False", wird das nur bei Änderung neu gesetzt -> ok
- wenn "enforce_updates = True" will ich doch ganz offensichtlich, dass jeder Wert "durchgeht".

Ich würde mich ERNSTHAFT über ein Beispiel freuen, wo "prev_value" in Kombination mit "enforce_updates" so wie bisher implementiert sinnvoll genutzt wird. Wenn es das gibt, bin ich sofort still. ;-)

Ich finde auch ein Entprellen passender.

Ich auch - gibt es aber nicht - und macht imho logische Fehler nicht besser. Zudem: Meine gepostete Lösung macht de-facto genau eine Entprellung...

Grüße
Robert

[callidomus]

Hi Robert,

Was spricht dagegen, "prev_value" bei "enforce_updates" mit zu aktualisieren?

das die Bedeutung von prev_value für ein WorksForRobert geopfert wird

Ich finde auch ein Entprellen passender.

Bis bald

Marcus

[greentux]

Ich fände irgendwie sowas wie eine Zeitverzögerung gut.
Also wenn Fenster länger als 10 Sekunden offen oder Temp länger als 20 Sekunden unter Wert oder sowas. Damit kann man dann auch Luxmeter entprellen (bzw. sich durchschiebende Wolken) und sowas...

[Robert]

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.

[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

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:

1. eh nicht enforce_updates setzen wenn der Zählerstand übertragen wird weil sonst zusätzliche Leseanfragen das ganze durcheinander bringen
2. 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

    eval = value if ((sh.now()-sh.Kinderbad.Fenster_verriegelt.Raw.last_change()).total_seconds() > 10) else self()

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