Beiträge von motom001

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.

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?

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.

Zitat von mamue

mit Blick auf kleine Kinder ... auch lieber wenn wir ein ganz klassisches Klingel-Tableau nutzen könnten.

Dann dürfen aber die Kinder nur in den ersten drei Stockwerken wohnen - alles was drüber hinaus geht ist für Kinderarme unerreichbar

Ich kann den Wunsch der großen Wandtafel mit vielen Klingelknöpfen verstehen, allerdings ist das bei 30 Wohneinheiten schon recht groß und vor allem nicht erweiterbar.
Alles hat sein Vor- und Nachteile und sollte vielleicht als Test-Stellung aufgebaut und betrachtet werden. Bei den für Euch zu erwartenden Kosten sollten eine Test-Stellung nicht mehr so riesig ins Gewicht fallen.

Ich denke, DoorPi macht bei einer vollständigen Modernisierung wie bei Euch nur dann richtig Sinn, wenn weitere Punkte mit betrachtet werden.
Ein Tablet als Innenstation kostet z.B. mehr Geld als die Innenstation einer "normalen" Türsprechanlage. Wenn aber weitere Themen wie digitale Stromzähler etc dazukommen ist der Mehrwert für ein Tablet schnell erreicht. Aber auch dort sollte in einem so großen Gebäude geklärt werden, wie Updates reguliert werden.

DoorPi ist meistens nur bei Ein-, Zwei oder wie bei mir Drei-Familie-Haus eingebaut. Dadurch sind die Auswirkungen überschaubar. Bei 30 Wohnungen ist die Chance für Wartungsfenster schon stark eingeschränkt. Auch zu klären ist, wer sich drum kümmert wenn die Klingel nachts um 2 Uhr ausfällt. Warten bis zum nächsten Tag oder sofort reagieren. Natürlich sind das auch Fragen an eine "normale" Türsprechanlage, allerdings fragt dort niemand nach genau den Punkten. Bei OpenSource sind die Fragen aufgrund von gesundem Misstrauen schnell da. Das ist auch der Hintergrund meiner Frage eventuell IT'ler von Euch im Projekt einzubinden. Damit wachsen Kompetenzen vor Ort und das Vertrauen.

PS: Tag der offenen Tür klingt super, aber Mannheim ist mir von Dresden aus zu weit. Ich wünschte mir aber, dass solche Projekte wie bei Euch viel öfter in DE umgesetzt werden. Sowohl vom Thema Nachhaltigkeit bestehender Gebäude als auch das Thema Gemeinschaft.

Zitat von Joseph

wie das Verschießen und Scharf schalten funktionieren soll.

?!? In Deinem Eingangspost ging es nur um Sensoren und nun redest Du über Aktoren ?!?

Du springst mir ein wenig zu schnell in den Themen. Ich würde gern eine Frage beantworten bevor Du zwei neue stellen kannst.
Oder ich bin zu langsam und verstehe das Gesamt-Thema nicht - möchte ich nicht ausschließen...

Zitat von pahenning

Da kann man mit "Überbrücken" nichts erreichen.

Der RFID-Reader von DoorPi ist so gebaut, dass man auch dort mit überbrücken nichts erreichen kann. Es werden die RFID-ID's übertragen und innerhalb von DoorPi ausgewertet. Erst wenn die stimmen, dann wird eine Aktion ausgelöst und der Türöffner betätigt. Selbst das Überbrücken der 2 Kabel zum Türöffner bringt nichts, denn dort liegt keine Spannung an bis DoorPi den Ausgang schaltet.

Zurück zum Thema "Wiegand-Steuerung":
Welchen Vorteil hat es das Wiegand Protokoll zu unterstützen und passende Hardware zu kaufen, anstelle gleich Hardware zu kaufen, die sich auch ohne Wiegand Protokoll einbinden lässt?

Zitat von bahnuhr

Lösung:
Nach dem Gespräch die Datei löschen.

Aber er brauch die Datei doch gar nicht - das ist ein Garagentor

Also Key einfach leer lassen und gut ist...

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.

Zitat von pahenning

da gibt es noch viel mehr Hilfe, als hier.

Mehr Hilfe als hier kann nur Chuck Norris liefern.

Ganz ehrlich - ich verstehe die Anforderung nicht...
Was ist eine "Wiegand-Steuerung" und wie soll die angebunden werden?

Ich verstehe den Wunsch (RFID-Reader -> DoorPi -> FHEM) allerdings nicht den Mehrwert der neuen Lib in diesem Zusammenhang (hab aber ehrlich gesagt auch nicht alles gelesen).
@pahenning hat auf http://www.fhemwiki.de/wiki/DoorPi_und_FHEM beschrieben, wie DoorPi Daten an FHEM übertragen kann. Wenn dort erst die Auswertung erfolgen soll, dann wäre das eine Möglichkeit.

Zitat von motom001

sudo pip install linphone4raspberry python-daemon

Zitat von pahenning

sind aber noch empfindlicher gegen Umwelteinflüsse, wenn sie hinter einer (dünnen) Glasscheibe liegen

Den verstehe ich gerade nicht... Meinst Du Temperatur(-Unterschiede) und die Folgen davon?

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...

Zitat von pahenning

in verkleinerter Form hier zu posten

erledigt - @irqnet: Ich hoffe das war so okay...

Zitat von pahenning

kleinen separaten Anwendung geschehen

Oder als neues Keyboard im DoorPi - auch der Aufwand hält sich in Grenzen.

Vorab: Ich persönlich finde dieses Bauprojekt sehr gut und wäre froh, wenn ich es mit DoorPi unterstützen könnte.

Grundsätzlich kann DoorPi frei skaliert werden und eine Klingel-Anlage mit einem Eingang zu x Wohnungen bereitstellen. Die Funktion mehrere Eingänge zu bedienen liegt aktuell nicht bei DoorPi, sondern beim SIP-Server sofern einer vorhanden ist. Es wären also drei getrennt, wenn auch austauschbare, DoorPi Installationen.

Bei sehr großen Klingelanlagen wird teilweise nicht mehr jede Wohnung als Taster abgebildet, sondern ein Keypad auf dem die "Durchwahl" zur Wohnung eingegeben wird. Dazu ein Display ( pahenning hat das gut abgebildet), welches den aktuellen "Wählstatus" anzeigt.

Es müssten aus meiner Sicht einige, geringfügige Anpassungen an DoorPi als Software vorgenommen werden um das zu realisieren. Eventuell sind von den 60 neuen Mietern Programmierer_innen dabei, mit denen ich die Eckpunkte abspreche um umsetzen könnte.

Bis wann soll der Umbau abgeschlossen sein bzw. die ersten Mieter einziehen?

if self.__record_filename is '':
            logger.debug('no recorder found in config at section DoorPi and key records')
            return

Bedeutet soviel wie, lass es doch einfach leer
Wenn der #Key #records nicht gefunden wird, nutzt DoorPi den #Default-Wert
Wenn der Key records vorhanden und leer ist , dann wird der #Recorder #deaktiviert

Hoffe, dass beantwortet Deine Frage...

hab es gerade mit drei Browsern getestet und es funktioniert bei allen. Natürlich kommt ein 301 als root Aufruf, aber danach geht es direkt weiter.
Wochen Browser benutzt du, bei dem es nicht funktioniert?

Frage 1: aktuell nicht möglich, könnte aber mit ein paar Stunden eingebaut werden.

Frage 2: aktuell nicht möglich, könnte aber in noch weniger Zeit als Aktion eingebaut werden. Finde ich eine gute Idee...

Frage 3: jetzt schon möglich, wenn du das passende Event mit einer out Aktion kombinierst.

Mein doorpi heißt doorpi2500 und die passende url ist :
http://doorpi2500/help/modules…e=linphone&installed=true

Das Event OnMediaRequired wäre vielleicht passend. Grob und ungetestet sieht es so aus :

[EVENT_OnMediaRequired]
10 = out:klingel,1

Oder die Events
BeforeCallIncoming
Recorder events
...