[gelöst] HM-sec-sc-2 Briefkastenüberwachung

[Knallfrosch]

Hallo,

ich möchte mit einem Hm-sec-sc-2 den Briefkasten überwachen.

Mein Plan:

Der Sabotagekontakt überwacht den Briefeinwurf mit Microkontakt am Deckel.
Der Reed signalisiert mir die Entnahmetür.

Ich lasse mir jetzt experimentell das einlegen der Post und die Entnahme per Mail senden.

Soweit so gut.

Die Mail wird also beim öffnen des Briefkastendeckel beim einlegen von Post gestartet. Beim schließen habe ich keine Reaktion.

Selbiges wird beim öffnen der Entnahme veranlasst.

Das zugehörige Icon ändert aber ja wieder seinen Zustand wenn das Einlegen oder die Entnahme beendet ist, also der Kontakt wieder geschlossen ist.

Und nun zu meiner Frage:

Wie schaffe ich es das der Kontakt zum Einlegen erst zurück gesetzt wird wenn die Post entnommen wurde.

Also Post einlegen (Sabotagekontakt schaltet EIN), ICON wird Rot, und wird erst wieder grün wenn der Reedkontakt, also die Entnahme geöffnet wurde.


Vielen Dank für eure Hilfe.

Grüße

[Beta-User]

Das Problem dürfte folgendes sein:
Wie erkennst du, dass eine Öffnung zur Entnahme stattgefunden hat? Wenn es derselbe Kontakt ist, ist das m.E. nicht so einfach, man muß das irgendwie "manuell" zurücksetzen, wenn es nicht z.B. mit einem Zeitfenster oä. geht (oder mit dem "eigentlichen" Kontakt, der ja auch da wäre)...

Vorschlag für eine "manuelle" Lösung:
Bau noch eine sequence, die auf den Kontakt aufpaßt. Wird nur einmal geöffnet, war es der Briefträger, öffnet jemand 2x in kurzem Abstand (aber so, dass der Kontakt das auch mitbekommt), war es jemand, der den Kontakt zurücksetzen wollte. Dann ein entsprechendes neues Reading auf den Kontakt anlegen (bzw. durch die notifys auf die sequence-Ereignisse - triggerpartial usw. - setzen) und dann ein anderes stateFormat verwenden.

Viel Erfolg,
Beta-User

[connormcl]

Eine andere Möglichkeit ist es, Sensor und Anzeige zu trennen...

Also einen Dummy zur Anzeige nehmen, den du in Abhängigkeit von den Sensorwerten bzw. Abläufen setzt...

Bspw.:
Notify 1: wenn Sabotage kommt, geht der Dummy auf rot.
Notify 2: wenn Reed kommt und vorher Sabotage war, dann geht der Dummy auf grün

[Knallfrosch]

Ach ein Dummy.....ja das müsste ich doch lösen können.

Danke für den Gedankenanstoß!

[Beta-User]

...darauf hatte ich eigentlich nur gewartet, dass hier jemand auf die Idee kommt, dafür ein eigenes Anzeigedevice vorzuschlagen...

Solange alle Angaben aus demselben physischen Device kommen, finde ich das mit stateFormat deutlich eleganter. Die eigentliche Info ist ein schlichtes weiteres Reading. Was spricht denn gegen diese Konstruktion (außer "Reading?!? Was ist das?? - Dummy kenne ich...")?

Just my2ct...

[Knallfrosch]

@beta-user,

ich verstehe nicht was du hier schreibst. Sorry.
Kannst du das etwas deutlicher ausformulieren?

Also ich habe ja zwei Schaltkontakte, sabotage:on soll sagen "Brief ist da" (Briefsymbol=rot) und erst wenn der contact:on soll der "Brief zurückgesetzt" werden (Briefsymbol=grün)

Mit dem Dummy ist es mir klar. Den kann ich ja mit dem Notify füttern das mir sowieso die Mails verschickt.

Bin aber auch an einer eleganteren Lösung interessiert.

Grüße

[Wuppi68]

Notify Deckelauf setzte Reading Pest ist da
Notfy Türauf setzte Reading nix im Kasten

und die Readings kannst Du auch in Deinen FK setzen

[Beta-User]

Man braucht keine 2 zusätzlichen Readings (Pest/nix), sondern nur eines: "Briefkasten".

Das kann dann zwei Werte annehmen, nämlich z.B. "Nachsehen, ob was da ist!" oder "Wurde geleert" (darfst auch "true"+"false" oder "leer"+"voll" ... nutzen).

Die weiteren Angaben zum notify bzw. der Aktion sind unter "setreading" in der commandref zu finden, der Ausführungsteil würde dann lauten: 

Code Auswählen Erweitern

setreading <name des kontakts> Briefkasten "Nachsehen, ob was da ist!"

Weiterer Hinweis: man kann dazu auch ein einziges notify nutzen, dass dann halt rausfinden muß, ob jetzt der sabotage:on-Fall oder der contact:on-Fall eingetreten war und dann den Readinginhalt entsprechend definiert. Ist aber für Fortgeschrittene...

[Knallfrosch]

Uff.... 

Also ich habe es jetzt mal so gelöst:

Dummy angelegt mit dem Namen Briefkasten und der HM-SEC-SC2 heißt Briefkasten_Kontakt.

Dazu dann 2 Notivy:
Briefkasten_Kontakt:open {exmail('XXXXXXX,YYYYYYYY', 'FHEM Warnung-Briekasten geleert', 'Die Post wurde entnommen!')} ; set Briefkasten off
und
Briefkasten_Kontakt:sabotageError:.*off {exmail('XXXXX,YYYYYe', 'FHEM Warnung-Post eingeworfen', 'Es wurde Post eingeworfen!')} ; set Briefkasten on

Im Briefkasten dann: devStateIcon on:message_mail_open@red off:message_mail@green

Das funktioniert für einen Anfänger auch.

Ich verstehe nur nicht wie ich das schlanker bekommen kann?

[Beta-User]

Zum einen: Glückwunsch! Es ist doch schon mal was, wenn du deine dir gestellte Aufgabe gelöst bekommen hast!

Ich verstehe nur nicht wie ich das schlanker bekommen kann?

Das ist dann eben der Punkt, wo der Anfänger zum User wird, und das wolltest du doch möglichst schnell, oder?

Die Stichworte liegen eigentlich alle schon da, es geht jetzt darum, die Zusammenhänge zu verstehen. Das zerfällt in zwei Teilaspekte:

a) Reading vs. STATE
b) Ein notify statt zwei

a) Grundsätzlich steht alles, was FHEM intern speichert in einem "Reading", wobei das Reading "state" eine Sonderrolle hat: Zum einen werden dessen Events in der Regel nicht ausgewertet (=> doku zu notify), zum anderen wird "STATE" normalerweise aus "state" abgeleitet. Setzt man irgendein Device auf irgendeinen Wert, wird - etwas verkürzt gesagt - "state" mit dem Wert gefüllt .
Beides kann man (wie fast alles in FHEM) ändern, für letzteres ist stateFormat da. Ist nur leider nicht so gut dokumentiert, aber einen Versuch mit "attr <HM-sec...> stateFormat Briefkasten" hättest du machen können, in Verbindung mit "setreading <HM-sec...> Briefkasten on" (bzw. off)...

Ist damit hinreichend erläutert, warum man kein extra Device braucht, um die Anzeige so zu machen?

b) Was komplexere notify angeht, benötigt man etwas Perl und Regex-Erfahrung. Startpunkte vielleicht: https://wiki.fhem.de/wiki/Notify#Beispiele und https://regex101.com/
Das mag zwar auf den ersten Blick "too much" sein, aber hier könnte man auf beide Events dasselbe notify loslassen (da hilft der Event-Monitor, der in dem Wiki-Artikel auch beschrieben wird). Es müßte bei entsprechend beschränkter Auslöser-Regex genügen, $EVENT eq "open" anzufragen und den anderen Fall mit "else" abzufackeln.

Viel Spaß beim Einarbeiten, und keine Angst: Rom wurde nicht an einem Tag erbaut.

Gruß, Beta-User

[Knallfrosch]

Danke für deine Erläuterung.

Damit werde ich mich mal auseinander setzen.

Ich könnte damit wahrscheinlich sogar einiges in meiner "Anlage" schlanker machen.




Grüße

[peterk_de]

Ich mache das seit Jahren erfolgreich mit einem HM-SCI-3-FM und einem DOIF - aber das Prinzip ist exakt das, was du dir vorstellst, und geht auch mit dem Türkontakt, wenn du Regulären ausdrücke anpasst:

- wohnung.briefkasten.deckel ist der Kontakt am Deckel (zum Post entnehmen)
- wohnung.briefkasten.schlitz ist der Kontakt am Einwurfschlitz. Hier habe ich ein Reed-Kontakt und einen starken Magneten verwendet, bei dem HM-SEC-SC-2 könntest du ja sogar den eingebauten Reeadkontakt verwenden, nur hätte das Ding in meinem (Blech-)briefkasten keinen Empfang
- wohnung.briefkasten ist ein Dummy, in den ich alle Zustände (Voll/Leer/Zeitpunkt der letzten Leerung/Zeitpunkt des letzten Einwurfes) packe. Die nutze ich, um auf einem Tablet-PC den aktuellen "Füllstand" etc. anzuzeigen und separat über ein Notify (mit vielen weiteren Bedingungen, z.B. ob jemand zu Hause ist) Benachrichtigungen auszulösen.

Code Auswählen Erweitern

defmod di_briefkasten_fuellstand_bestimmen DOIF ([wohnung.briefkasten.deckel:".*open.*"]) ()\
DOELSEIF ([wohnung.briefkasten.deckel:".*closed.*"]) (setreading wohnung.briefkasten voll nein,setreading wohnung.briefkasten letzteLeerung {(TimeNow)} )\
DOELSEIF ([wohnung.briefkasten.schlitz:".*(open|closed).*"] and [?wohnung.briefkasten.deckel:state] eq "closed" and [?wohnung.briefkasten.deckel:state:sec] > 10) (setreading wohnung.briefkasten voll ja,setreading wohnung.briefkasten letzterEinwurf {(TimeNow)} )
attr di_briefkasten_fuellstand_bestimmen wait 0:0:5

(Code zum direkten Einfügen in "Raw Definition")

Da bei mir der Schlitz im Deckel integriert ist, beachtet mein DOIF das auch entsprechend (d.h. wenn man den Briefkasten aufschließt, wird kein "Einwurf" signalisiert, obwohl auch der Reedkontakt am Schlitz mit öffnet)

[Knallfrosch]

Hallo,

ja ich benutze den Reedkontakt für die Tür zur Entnahme der Post, der Sabotagekontakt überacht den Einwurfdeckel.

Zur Sicherheit habe ich die Antenne nach oben aus dem Gehäuse geführt, das Gehäusedes HM-Sec musste ich ja sowieso anbohren um den Sabotagekontakt anzapfen zu können.
Die Antenne selbst ist aber innerhalb des Edelstahlbriefkasten und funktioniert bisher bei allen Tests.
Langzeiterfahrung steht natürlich noch aus.

[Beta-User]

Danke für deine Erläuterung.

Damit werde ich mich mal auseinander setzen.

Ich könnte damit wahrscheinlich sogar einiges in meiner "Anlage" schlanker machen.

Danke für die Rückmeldung!

Ist mir auch so gegangen, dass ich erst mal copy/paste vieles zusammengeschustert habe (war auch Perl-Novize und im Kern nur mal TurboPascal an der Schule gelernt, lang' ist's her...) und mich hinterher darüber geärgert habe, dass das nicht besser strukturiert war.
2. Phase war dann Umbau/Generalisierung usw.. (Dazu auch mal den myUtils-Wiki-Artikel lesen und das ggf. mal austesten ).

Aus dieser gemischten Erfahrung kommt meine Motivation, das wenigstens ein klein wenig an andere weiterzugeben .
Und meine Abneigung gegen DOIF. Verstößt gegen das Prinzip "Eine Aufgabe => ein Tool" und selbst die DOIF-Erfinder sind - frei interpretiert - mittlerweile auf dem Trip, den Geist wieder etwas einzufangen und den Usern zu empfehlen, Perl zu lernen, wenn sie wirklich komplexe Aufgaben zu lösen haben. (Die Attribut-Orgien lösen bei mir immer nur Kopfschütteln aus, angefangen bei "do always").
Mein Motto: Dann lieber gleich das Original...