Entwickeln wäre kein Problem
TOP
nur mit der Schlange hatte ich noch (fast) gar nichts zu tun.
Nichts ist leichter als Python - schau selbst in den Quellcode, liest sich so einfach wie ein Buch...
Entwickeln wäre kein Problem
TOP
nur mit der Schlange hatte ich noch (fast) gar nichts zu tun.
Nichts ist leichter als Python - schau selbst in den Quellcode, liest sich so einfach wie ein Buch...
Klingt gut wobei ich gar nicht weiß ob motom001 pull requests noch zulässt.
Macht er bestimmt...
Hab mir jetzt nicht den ganzen Text durchgelesen sondern möchte eher was zu dem generellen Herangehen sagen.
Möglichkeit 1 "die externe Lösung":
Es läuft ein externes Script wie wie im #2 von sgaechter
Durch das client.loop_forever() am Ende wird der Thread für immer "gesperrt" und kann nicht sauber (als Action) in DoorPi integriert werden.
Es macht meines Erachtens dann keinen Sinn über das "virtuelle Keyboard" zu gehen - ich würde dann den Weg über den Webservice wählen. Das Script könnte dann eine URL aufrufen wie:
http://door:pi@doorpi_server/control/trigger_event?event_name=OnKeyPressed_file.dooropen&event_source=mqtt
Möglichkeit 2 "Action pollt über Event":
Eine Action erzeugen, die sich die MQTT Einträge abholt und darauf direkt reagiert. Diese Action wird dann an ein OnTime* Event gebunden und pollt am MQTT Broker. Beispielhaft ist hier die Action statuswatchdog Größter Nachteil, wenn es zu einem Timeout kommt (dauert i.d.R. mindestens 2 Sekunden) bleibt DoorPi solange stehen und wartet auf das Ergebnis.
Möglichkeit 3 "Keyboard MQTT":
Eine Anbindung kann auch mittels der Keyboard-Vorlagen erzeugt werden (auch wenn ich den Namen Keyboard dafür bis heute schlecht gewählt finde). Im Grunde genommen ist es genau diese Darstellung vom Script in #2 als Integration in DoorPi. Beispielhaft hier einfach die Integration von PN532 (NFC-Lesegerät)
Ich sehe häufig die Lösung 1, da google am meisten hilft ein fertiges Standalone-Script zu finden. Die Lösung klappt und ich finde es super, wie Ihr Euch Gedanken macht und gegenseitig helft. Aus Systemsicht / Programmiersicht würde ich Euch auf Dauer den Weg 3 empfehlen.
Ich bin am überlegen, ob die Struktur des Forums noch gut ist.
Habt Ihr Vorschläge für eine bessere Organisation der Bereichen und Themen?
Eventuell ist es an der Zeit einen Cut durchzuführen und alte Themen nur noch lesend zur Verfügung zu stellen.
Laut Anleitung gibt es mehrere Möglichkeiten - ich denke aber g zu 7
Klemmenbelegung
11 Mikrofon Mi
12 Lauthörkapsel Ls
9 Bezugspunkt für Mi und Ls
11.1 Mikrofon Mithörgesperrt
12.1 Lauthörkapsel
Mithörgesperrt
1 Impuls Mithörsperre
c Bezugspunkt Rufsignale
b Versorgung Gong
7 Ansteuerung für Türruf
10 Ansteuerung für Etagenruf
G Ansteuerung für Gong
6.1/I Kontakt Türöffner-Taste
6.2/II Kontakt Licht-Taste
oder der Türsprechanlage einfach kurz 15 Sekunden den Strom für den Lautsprecher wegnehmen
Lexikon ist noch nicht migriert in die neue Version - deshalb danke für Deine Hilfe.
Ansatz für die Installation ist auch beim Test mit Travis (automatische Erstellung als Code-Test) zu finden:
https://travis-ci.org/motom001/DoorPi
z.B.: https://travis-ci.org/motom001/DoorPi/jobs/520705666
als RAW-Log: https://api.travis-ci.org/v3/job/520705666/log.txt
genutzt werden die Installscripte von hier:
Anrufen (DoorPi zu Fritzbox) hat nichts mit dem Video (Client holt von Kamera) zu tun - die Anfragerichtungen dazu sind unterschiedlich.
Klingel 1 wird gedrückt
call Aktion mit einer Nummer wie "600@192.168.0.1" sollte die entsprechende Fritzbox und Nummer anwählen
Client (Tablet o.ä.) rufen das Bild an der Kamera ab -> kann auch parallel von beiden erfolgen und hat nichts mit dem Telefonat zu tun
Hallo,
zur Zeit stecke ich voll im Umbau meines eigenes Hauses. Aus einer Renovierung ist eine Kern-Sanierung geworden. Mittlerweile habe ich sämtliche Medien neu gezogen und bin dabei die ganze Elektrik neu zu verlegen. Das kostet nebenbei etwas Kraft und wird sich noch bis zum Frühjahr ziehen.
Die Aufgaben rund um DoorPi sind so viele, dass ich das allein auch nicht alles schaffen werde. Aber ich bleibe dran und gebe das Thema nicht auf. Technologisch hat sich viel getan und eine Integration von Drittanwendungen wird immer wichtiger.
Anfang des Monats hatte ich noch einen Ausfall auf meinem Server, der aufgrund von mangelndem Speicherplatz den Dienst eingestellt hat. Kein Speicherplatz ist auch der Grund, warum seit einer Woche keine konsistente Sicherungen mehr erzeugt wurden. Den Umstieg auf das neue WBB hatte ich schon lange geplant und hab den Anlass gleich genutzt. Jetzt gilt es Restarbeiten durchzuführen.
Kurz um - ich werde DoorPi definitiv weiterentwickeln und mich auch Python3 und allen anderen Themen stellen. Auch eine Virtualisierung mittels Docker hatte ich in einer Teststellung abgeschlossen. So wäre der Installations- und Update-Vorgang klar definiert.
Diese und nächste Woche brennt bei mir noch ein wenig die Luft, danach werde ich einfach mal mit den einzelnen, die hier geantwortet haben, Kontakt aufnehmen und wir machen uns einen gemeinsamen Plan. Gerade in Zeiten von Ring oder ähnlichen Cloud-Produkten wird die Privatsphäre aus meiner Sicht immer wichtiger.
Do you authorize me to write the article?
Feel free to do what you want...
Das wird so schnell nicht passieren - auch wenn ein Update wieder mal gut tun würde...
Bei so vielen Mitgliedern fällt es mir schwer zu glauben, dass niemand programmieren kann und will.
[lexicon]Start von DoorPi im Trace-Modus[/lexicon]
Hallo Gemeinde,
gestern kam es zu einem Systemausfall, auf Grund dessen ich die MySQL Datenbanken in einem inkonsistenten Zustand vorgefunden habe. Leider hatte ich keine andere Möglichkeit, als die Datenbank neu aufzusetzen und das Backup vom 20.06.2018 03:02 Uhr einzuspielen. Dadurch ist ein Datenverlust im Zeitraum von 20.06. 03:02 Uhr bis 21.06. 18:00 Uhr entstanden.
Ich bitte um Entschuldigung für die Unannehmlichkeiten und hoffe mit einem enger gefassten Backup-Plan das Problem in Zukunft verbessern zu können.
Programmiere ich in PHP, MySQL sowie ein wenig Javascript
Und ab heute auch Python um den Quellcode von DoorPi zu unterstützen?
Ich möchte jetzt wenn es irgendwo länger als 25 Sekunden klingelt das es automatisch überall klingelt ausser es war schon jemand ran gegangen.
Das ist Aufgabe der Telefonanlage und ist nicht innerhalb von DoorPi abgebildet. Da der Anruf sync ist, gibt es auch Probleme mit call - sleep - call
Bei einer Fritzbox kann das z.B. mittels Gruppenanruf umgesetzt werden
Firma Voice INTER connect aus Dresden
Da kann ich ja direkt vorbeifahren - ist eigentlich mein täglicher Arbeitsweg, dort entlang zu fahren...
Anfangs fände ich es schon ganz "lustig" wenn jemand Klingelt, mir das Alexa aktustisch und optisch (mittels dem Leuchtring) signalisieren könnte?
Sollte gehen - Aufwand für Programmierung überschaubar und wenn ich Alexa hätte innerhalb von einem Wochenende umgesetzt:
This interface does not provide the content for a notification, it only provides the audio and visual indicators that are used to inform the user that new content is available. For example, the product may flash a yellow LED and play an audio file, at which time a user can retrieve any pending notifications by asking, “Alexa, what did I miss?” or “Alexa, what are my notifications?”
Das Sprechen mit Alexa ist etwas komplizierter, da die Arbeitsweise von Alexa, so wie ich es verstanden habe, nicht auf ein Duplex-Gespräch ausgelegt ist. Meint sow viel wie: Entweder ich rede oder der an der Sprechanlage spricht. Beide Richtung wie beim Telefon hab ich bisher nicht gefunden...
Merker: SpeechRecognizer Interface und SpeechSynthesizer Interface bzw.
Das optimum wäre noch, wenn man Alexa bitten könnte, die Haustür zu öffnen.
Das sollte auch möglich sein - siehe ein Absatz weiter oben...
Vielleicht wäre das auch ein Weg mehr Entwickler zu finden, die sich beteiligen...
Tot ist doorpi nicht, und sterben wird es auch noch eine ganze weile nicht...
Wem die Entwicklung zu langsam geht, kann ja gern mitmachen...
Siedle HTS 711-01
Theoretisch würde DoorPi nicht Dein Haustelefon, sondern die Klingel-Anlage ersetzen.
Ansonsten kann DoorPi (theoretisch) auch parallel angeschlossen werden, da:
– Parallelschaltung von max. 2 Telefonen ohne internen Sprechbetrieb
Du würdest DoorPi also als "Telefon" betreiben und müsstest die Spannung für Licht und Öffner durch Relais steuern (siehe z.B. PiFace2)
Was normalerweise der Höre ist, wäre Mic-Eingang und was normalerweise Mikrofon ist wäre Lautsprecher-Ausgang. Eventuell brauchst Du eine Soundkarte mit Line-In, da die Signale an Dein Mic schon vorverstärkt ankommen und übersteuern würden.
Wen/was die wohl meinen??
Würde mich sehr wundern, wenn es um DoorPi geht. Sonst hätte es wohl vorher einen Kontakt zu mir gegeben, den es aber nicht gab.
Schade, wird wieder eine andere Lösung genannt - wie schon oft auch in anderen Zeitschriften.