Türstatus abfragen

Tabularasa · 5. September 2016

Ich habe mir einen Reedkontaktschalter an die Tür montiert um den Status der Tür abzufragen. Nun wollte ich, wenn die Tür sagen wir mal 3 Minuten offen steht, dass dann noch eine Push Nachricht kommt und sich nach 3 Minuten nochmals wiederholt solange bis die Tür zu ist. Im Moment sieht es so aus.

Code

[EVENT_OnKeyDown_prodsystem.4]
10 = os_execute:/usr/local/etc/DoorPi/scripts/TuerZu.sh


[EVENT_OnKeyUp_prodsystem.4]
10 = os_execute:/usr/local/etc/DoorPi/scripts/TuerOffen.sh

Telegram sendet einfach nur Tür zu oder Tür auf.
Wie könnte ich das denn einbinden? Gibt es da ein extra Event für? Danke

P.S. Falls möglich würde ich das gern noch zeitlich begrenzen. Eventuell von 22 - 6 Uhr.

Edit: Mir ist gerade noch eine Szenerie eingefallen. Ich wollte, wenn die Tür geöffnet wird, eine Seite draußen am Display anzeigen wo man wählen kann ob man abwesend sein wird wenn ich die Tür von innen öffne. Draußen ist der Bewegungsmelder. Kann ich irgendwas erstellen das mir die Seite nur anzeigt wenn das Türevent VOR dem Bewegungsmelderevent ausgelöst wird? So kann ich sicher gehen, dass ich auch von innen nach außen gehe.

**pahenning** · 5. September 2016

Hm. Das werden aber viele Funktionalitäten - und das jeweils durch Editieren der doorpi.ini zu ändern, ist ein wenig umständlich.

Vorschlag: lieber noch einen FHEM-Server installieren (sollte, für den Anfang, auf demselben Raspberry Pi gehen). Und dort mit Hilfe des Alarm-Moduls das Ganze per Web bedienbar machen. Stammt - nicht ganz zufällig - von mir. Siehe hier:

http://www.fhemwiki.de/wiki/Modul_Alarmanlage

LG

pah

motom001 · 5. September 2016

Für mich klingt das auch stark nach Hausautomatisierung anstelle von Türsprechanlage auch wenn die Grenze oft fließend ist...
Eine Hausautomatisierung, und nichts anderes ist z.B. FHEM, sollte genau diese Punkte abbilden können.

// EDIT \\

So ist das, wenn man 5 Minuten zum Schreiben brauch...

**pahenning** · 5. September 2016

Klarer Fall: Zuviel Urlaub gehabt

LG

pah

Tabularasa · 5. September 2016

ja das blöde ist wenn man einmal "Blut geleckt" hat will man mehr. Ideen hab ich viele, aber FHEM ist glaube eine Nummer zu groß für mich. Habe jetzt auch über 8 Wochen und 115 Posts gebraucht um die Grundkonfiguration zu erstellen und leider noch nicht ganz funktionsfähig(Verstärker). Dafür habe ich einfach den falschen Beruf gewählt

**pahenning** · 5. September 2016

Och nee. FHEM hat eine Community von > 15.000 Nutzern, da gibt es noch viel mehr Hilfe, als hier.

Sehr gute Anfängerdoku hier: http://fhem.de/Heimautomatisierung-mit-fhem.pdf

LG

pah

Tabularasa · 5. September 2016

Ja die hatte ich mir damals schonmal als Feierabendlektüre vorgenommen jedoch war ich etwas überfordert. Vielleicht sollte ich sie mir ja nach dem DoorPi Projekt( wo ich ja doch so einiges gelernt habe wovon ich vorher 0 Ahnung hatte) nochmals zu Gemüte führen

motom001 · 5. September 2016

Zitat von pahenning

da gibt es noch viel mehr Hilfe, als hier.

Mehr Hilfe als hier kann nur Chuck Norris liefern.

**Nea** · 5. September 2016

Das könnte man relativ leicht mit einem Script lösen. Wenn da dann noch einen Schleifenzähler gearbeitet wird würdest Du das bekommen was Du benötigst.

**pahenning** · 6. September 2016

Zitat

Mehr Hilfe als hier kann nur Chuck Norris liefern.

Einzeln ja. Aber in der Vielzahl sind sogar Ameisen stärker als Chuck Norris.

LG

pah

Tabularasa · 6. September 2016

Zitat von Nea

Das könnte man relativ leicht mit einem Script lösen. Wenn da dann noch einen Schleifenzähler gearbeitet wird würdest Du das bekommen was Du benötigst.

Dann mal her damit . Aber im Ernst. Scripts alleine erstellen, das wird bei mir nix

motom001 · 6. September 2016

Zitat von Nea

relativ leicht mit einem Script lösen

Richtig, das kann man damit auch lösen, allerdings würde ich davon abraten. Die Erkennung Tür auf / Tür zu sollte DoorPi abbilden und das an FHEM melden. Dort sollte die Logik für Eskalationen abgebildet werden.

Mit einem Script würde ein Zugriff auf GPIO etc parallel zu DoorPi erfolgen, wovon ich als Software-Entwickler nur abraten kann.

@Tabularasa Alles was Du jetzt außerhalb von DoorPi und FHEM baust, wird Dir Probleme machen, wenn sich irgendwas ändert und keiner kennt diese Scripte. Dann kann auch ein noch so guter Support / Community Dir nur noch bedingt helfen.

**Nea** · 6. September 2016

@motom001
Da muss ich dir Recht geben, die Übersichtlichkeit leidet dann sehr stark darunter.

Zitat von motom001

Mit einem Script würde ein Zugriff auf GPIO etc parallel zu DoorPi erfolgen, wovon ich als Software-Entwickler nur abraten kann.

Warum, wo liegt das Problem?

Tabularasa · 6. September 2016

Mal ne OT Frage. Was würde ich denn Hardwareseitig noch benötigen damit FHEM und DoorPi kommunizieren können? Also jetzt erstmal nur um das mit der Tür zu realisieren.

motom001 · 6. September 2016

Zitat von Nea

Warum, wo liegt das Problem?

Fehlkonfigurationen - am GPIO z.B. BOARD und BCM Nummerierung durcheinander bringen und mit dem externen Script den Pin nach dem Start von DoorPi als Ausgang definieren und dann hier im Forum schreiben, dass DoorPi den Tastendruck nicht mitbekommt und sch*** ist.

Für jemanden wie Dich kein Thema, da Du den Fehler schnell selber findest. Für Dich wäre es auch kein Problem wenn beim Update vom OS neue Restriktionen oder anderen GPIO Libs reinkommen und Du Dein Scripte anpassen musst. Aber das sind hier im Forum vielleicht 20% der Nutzer. Der Großteil kann genau das eben nicht allein. Und Du weißt selbst, dass Support für ein Scripte, welches nicht von uns stammt, extrem schwer ist und sehr viel Zeit kostet. So lange sich jemand findet,d er diesen Support gibt, ist alles okay. Aber wenn die 20% im Sommer im Urlaub sind oder keine Lust haben, dann sieht es blöd aus...

Deshalb bin ich immer daran interessiert die Komponenten in DoorPi zu integrieren oder saubere Schnittstellen zu Drittsystem zu bauen.

Zitat von Tabularasa

Hardwareseitig noch benötige

Nichts - den Reed-Kontakt hast Du, FHEM ist dank pah vorbereitet und DoorPi kann bereits in anderen Szenarien Infos an FHEM senden.

**Nea** · 6. September 2016

Die Problematik ist mir bewusst aber DoorPi bläht sich dann immer weiter auf.

Tabularasa · 6. September 2016

Zitat von motom001

Nichts - den Reed-Kontakt hast Du, FHEM ist dank pah vorbereitet und DoorPi kann bereits in anderen Szenarien Infos an FHEM senden.

Ah OK. Ich dachte ich brauche noch diesen CUL. Dann kann ich also FHEM einfach auf dem selben Pi installieren? Dann ist es ja einen Versuch wert.

Aber falls das mit dem script auch geht, würde ich es gern probieren. Zumindest zur Überbrückung bis ich mich in FHEM eingelesen habe wenn @Nea es mir bereitstellen würde.

motom001 · 6. September 2016

Zitat von Nea

DoorPi bläht sich dann immer weiter auf

individuelle und dezentral gepflegte oder zentrale Scripte in einer Versions-Überwachung - was ist da wohl besser
Wenn die Scripte ehh benötigt werden, dann sollten die Bestandteil von DoorPi sein...

@Tabularasa Wozu die CUL?

**Nea** · 6. September 2016

Hehe, ok ich gebe mich geschlagen.

Also würdest Du dann auch eine native Unterstützung für IButton und Wiegand26/32 direkt in DoorPi befürworten.

motom001 · 6. September 2016

Grundsätzlich ja auch wenn ich weiß, dass es Punkte gab, die für eine indirekte Integration (z.B. über Arduino) von iButton-Reader in DoorPi gesprochen haben.

Teilen