Beiträge von Joker

Zitat von pahenning

Erst einmal ziehe ich iButtons den RFID-Tags vor - die iButtons kann man eben nicht im Vorbeigehen auslesen, die öffnen bei mir schon Hoftür und Garagentor.

iButtons kenne ich jetzt nicht. Wenn das mit dem "nicht im Vorbeigehen auslesen" in Richtung Sicherheit abzielt, ist das bei mir nicht wirklich relevant. Der Türsummer den der DoorPi ansteuert ist am Gartentürchen, nicht an der Haustür. Und da ich keine mannshohen Zäune habe ist es sicherlich einfacher über den Zaun zu klettern als sich die Mühe zu machen meine Tags auszulesen.

Zitat

Der Haupangriffspunkt für Sabotage ist immer die Frontplatte - die sollte also aus Metall sein. Bei der Schaeffer AG kann man sich diese in beliebiger Komplexität selbst designen und online bestellen - inklusive Bolzen für die verdeckte Befestigung.

Doofe Frage, aber ich frag sie trotzdem da ich es mir nicht so recht vorstellen kann: Was bringt denn eine verdeckte Befestigung im Hinblick auf Verhinderung ungewollten Eindringens? Man sieht die Schrauben nicht, OK, aber sie sind ja trotzdem da. Ein Einbrecher würde also sinnvollerweise die Schrauben ausfindig machen und sie herausschrauben, das geht sicher schneller und unauffälliger als die gewaltsame Entfernung der Frontplatte. In dem Hinblick finde ich eine Kunststoffplatte auch nicht wesentlich unsicherer als eine Metallplatte.

Zitat

Wichtiger als ein Sabotagekontakt erscheint mir die Kopplung an den internen Watchdog des Raspberry Pi - und eine regelmäßige Überprüfung in der Hauszentrale, ob DoorPi erreichbar ist.

Nur zum Verständnis, warum findest du das wichtiger? Das eine ist der Schutz gegen ungewollten Zugriff, das andere ist die Überprüfung der Funktion. Meinst du das so, dass es mehr Sinn macht die Funktion sicher zu stellen als die (relativ unwahrscheinliche) Sabotage zu verhindern?

Mein Doorpi kommt in ein Aufputzgehäuse. Ich werde es vermutlich so machen dass ein Mikroschalter auslöst sobald man die Frontplatte abnimmt. Und das immer, es sei denn ich aktiviere vorher einen "Wartungsmodus". D.h. ich werde über irgendeinen Weg (vermutlich per HTTP-Request aus FHEM) die Abfrage des Mikroschalters totlegen, wenn ich das Gehäuse selbst öffnen möchte.

Was hier noch interessant sein könnte, falls du irgend eine Art von Hausautomation nutzt: Ich würde den Manipulationsversuch an das Hausautomatisierungs System schicken, und dort weitere Aktionen auslösen.
Dann kann man zentral z.B. eine Mail schicken, Licht anschalten etc. Oder eben auch eine Sirene einschalten, die nicht am DoorPi hängt. Weil wenn der DoorPi selbst den Ton abspielt, braucht man ja nur schnell alle ankommenden Kabel durchzwicken und das wars.

Alles richtig, hat aber nix mit dem Thema hier zu tun (Anbindung an FHEM).
Bitte nicht in einem Thema über unterschiedlichste Sachen diskutieren

Ja die Section für Gong1 muss prodystem_OutputPins heißen (nicht prodsystem_OutPins).

Ich habe noch gar nix dran, die obigen Bilder zeigen den Ist-Stand des Aufbaus. Bei mir kommt vermutlich eine Plexiglasplatte dran, die für Lautsprecher und Mikrofon 2mm Bohrungen im 1cm Abstand erhält (so der aktuelle Plan).

Ich habe oben alles aktualisiert, nun sind Bilder von der neuen Befestigung meiner RFID-Antenne auf der neuen Halterung aus Plexiglas drin.

Könnte man vielleicht so umgehen, dass man die Drähte vom Türsummer nicht direkt in den DoorPi führt, sondern innen an einem Schaltaktor anbringt. Und dann den DoorPi beim enstprechenden Event ein Kommando z.B. an FHEM absetzen lässt, das den Schaltaktor bedient. Wenn man sowas nutzt

Bei mir ist das weniger kritisch, weil der DoorPi am Gartentürchen hängen wird, und den Türsummer von selbigem bedienen wird.
Somit käme ein etwaiger Einbrecher höchstens in den Garten. Aber da ist es sicher einfacher einfach über den Zaun zu klettern.

Ich mache mir da mehr Sorgen dass jemand wenn er den DoorPi öffnet prinzipiell Zugang zu meinem LAN hat. Da könnte man aber auch was bauen- z.B. einen Taster der von der Frontplatte gedrückt gehalten wird. Wenn er losgelassen wird, könnte man wiederum einen Befehl an FHEM schicken. Das LAN-Kabel was zum DoorPi geht hängt man an einen Switch, und wenn der FHEM-Befehl kommt, schaltet man dem Switch die Spannung ab.

Kennst Du smartvisu? Das benutze ich als Visualisierung. Die Buttons sind einfach vom Typ basic.button, und das Item ist der doorBellTarget dummy in FHEM. Der eine Button setzt den state auf internal und der andere auf external.

Zitat von pula001

das kann ich mir wohl abschminken :-

Das kann man so sagen
@fraeggle, mir war das prinzipiell schon klar mit dem Metall. Deswegen hatte ich von Anfang an geplant die Antenne hinter einem Kunststoffteil wo Name und Straße drauf steht zu machen. Ich hatte nur unterschätzt dass HINTER der Antenne auch kein Metall sein darf. Da reichte bei mir auch nicht 1cm Abstand ringsum, bei 2 wäre es gegangen (habe ich mit einem Reststück Metall getestet), aber soweit konnte ich die Metallplatte nicht ausschneiden weil ich mir sonst die Halterungen von meinen ganzen Platinen weg geschnitten hätte.

@pula001, also ich werde entweder ein entsprechend großes "Beschriftungsfeld" machen wo die Antenne dahinter kommt, oder die ganze Platte aus Plexiglas. Ich tendiere fast zu letzterem. Wieso Einbruchsschutz? Mit roher Gewalt kriegt man alles weg, also wenn jemand da rein kommen will kommt er auch rein, egal ob Kunststoff oder Metall.

Mittlerweile ist wieder über eine Woche vergangen, und ich wollte kurz was zum aktuellen Status schreiben (falls jemand einen ähnlichen Aufbau verfolgt und somit auf ein ähnliches Problem stoßen wird):

Ich hatte oben im Ausgangspost ja geschrieben, dass ich mit dem Metall hinter dem RFID ein Problem habe. Leider kann ich dies nicht so lösen wie gedacht- ich müsste rings um die Antenne ca. 2cm Abstand zum Metall lassen damit es ordentlich funktioniert, und den Platz habe ich nicht. Daher werde ich die Metallplatte verwerfen, und die gleiche Platte nochmal aus Kunststoff fertigen. Das ist aktuell in Arbeit (Arbeitsfortschritt könnt ihr in meinem Worklog bei we-mod-it sehen).
Wenn ich den neuen Aufbau fertig habe aktualisiere ich hier wieder den ersten Post.

Wenn ich das richtig verstehe brauchst du 4 Eingänge und 4 Ausgänge oder?

Eingänge sind erstmal alle Taster. Die kannst du einfach an GPIOs des PI anschließen und über DoorPi auswerten.
Und dann brauchst Du 4 (oder 5) Ausgänge, die deine Relais schalten.
Dafür kannst du so eine Schaltung verwenden wie hier beschrieben.

Wie hast du das jetzt gemacht, wie in dem obigen Thread beschrieben durch Änderung der HTML-Seite?

OK, ich habe ungefähr die selben Kriterien. China wär zwar in Ordnung, aber ich will jetzt nicht 4 Wochen warten.

Ich glaube ich werde hier bestellen. Kommen zwar mehr Versandkosten drauf als was das Ding kostet, aber ich denke ich werde gleich zwei nehmen und noch was anderes finde ich bestimmt auch noch

Ich hoffe wirklich dass meine Probleme auch an dem Kabel lagen, denn das ist bisher zweimal völlig aus heiterem Himmer aufgetaucht.

Wo hast du das Kabel bestellt? Ist es die "normale" Länge von etwa 20cm?
Ich brauche für meinen Aufbau ein längeres mit etwa 30cm, und bin mir noch unschlüssig wo ich es bestellen soll.

Zum Thema: Bei mir hat die Kamera mal insofern den Dienst quittiert, dass der mjpeg-streamer Stream nicht mehr geöffnet werden konnte. Ein Standbild abspeichern mit raspistill ging aber. Ein Neustart vom mjpeg-streamer hat nicht geholfen- wohl aber ein shutdown, Kabel an- und wieder abstecken und ein reboot. Ich habe es auch erstmal aufs Kabel geschoben- aber muss das noch weiter beobachten wenn ich das eh benötigte längere Kabel habe.

Die Besucher können auch teilweise Suchmaschinene sein, die das Board nicht erkennt.

Sehr schönes Projekt!

Die Intercom von Loxone hat ja echt nen stolzen Preis für ein proprietäres System
Eins muss man aber sagen, geil aussehen tut sie

Bin sehr auf deine Frontplatte gespannt. Wie hast du die bei Prokilo bestellt, fertigen die nach CAD-Datei oder wie läuft das? Bekommst du die für die 60€ in Edelstahl? Das wäre ja echt vergleichsweise günstig, ich habe mal eine ähnliche Frontplatte über das Tool von Schaeffer-Ag erstellt und das kommt auch auf ca. 60€, allerdings in Alu eloxiert.

Klingt ja sehr gut!

Zitat von motom001

Wenn man den Qullcode kennt, ist man im Denken manchmal etwas auf spezielle Lösungen fokussiert...

Ja, kenne ich

Zitat von motom001

Deine Idee beinhaltet aber auch wieder neue Sektionen und die Config wird noch unübersichtlicher.

Sagen wir mal so... länger wird sie, aber unübersichtlicher finde ich es nicht. Da es eine separate Sektion ist finde ich es eher übersichtlicher, das eine ist die Liste der Aktionen die ausgeführt werden soll, das andere sind die Bedingungen dafür.

Zitat von motom001

Außerdem wäre es dann nicht möglich Aktionen immer auszuführen und weitere nur in Abhängigkeit.

Wie meinst du das, also dass bestimmte Aktionen von einem Event ausgeführt werden und andere nicht? Das stimmt, die Frage wäre ob es dafür einen Use-Case gibt? In deinem Vorschlag ist es auch nur möglich, an einer Stelle komplett abzubrechen...

Ich denke mal noch ein wenig nach. Wie gesagt ist die Idee von mir bisher eher halbgar.

Englisch kann ich machen

Edit: Hier:

=============
English
=============
---------------
Introduction
---------------
Aim of the DoorPi project is the realization of a door intercom station with a single board computer like the Raspberry Pi and the communication protocol VOIP.
DoorPi is an event-action based system. There are components which fire events, and components which react on these events. That means that events like "Doorbell pressed" or "RFID chip xyz detected" shall be the trigger for actions like "call telephne xyz", "send email to xyz" or "open door".
---------------
Event-Sources
---------------
For registering these events, so-called "DoorPi-Keyboards" are used, e.g
* GPIO pins
* a PiFace
* files in the filesystem of the PI (e.g. for remote commands via SSH)
* the serial port (e.g. with an RDM6300 as NFC reader)
* web service with authentification
* VOIP phone
To every event, any number of actions can be attached, which are executed synchronously or asynchronously.
-----------------
Action-Receivers
-----------------
A non-complete list of actions is:
* VOIP call to a predefined number
* VOIP call to a number which is read from a file
* end call
* send email
* execute program
* set an output pin
* write a status file
* read values from IP-Symcon or write them back
Via the combination of events and actions, almost all combinations are possible.
-----------------
Examples
-----------------
A thinkable scenario is:
# when the doorbell button is pressed, a call is instantiated for calling a specific number (e.g. internal number of the FritzBox \*\*613, but also cell phone numbers)
# the inhabitant can talk to the outside station and on demand open the door remotely, by pressing a defined key (or sequence of keys) on a telephone (e.g. the key "#")
# the inhabitant forgets to end the call and DoorPi ends the call itself, as soon as the door was closed again
# DoorPi sends an email that there was a call, somebody opened the door and somebody walked into the house
Meanwhile there is also video support, so that a camera can be installed at the door, and the image can be watched on the inside station even before the call is accepted
-----------------
Installation
-----------------
Installations are `described here <http://www.doorpi.org/forum/board/21-installation/>`_

Also ich denke im Moment an sowas:

[CONDITION_OnKeyPressed_gpiotaster.17]
00 = not_locked

Quasi eine extra Section wo man Bedingungen hin schreibt, ob ein Event ausgeführt werden soll oder nicht. Aber ich weiß noch nicht wie man das setzen und Rücksetzen der Bedingung sauber formulieren kann. Also wie gesagt, noch nicht durchdacht
Und ich kenne auch den Code nicht, ob das überhaupt sinnvoll machbar wäre.