Meinen aktuellen Lösungsansatz stelle ich mal an den Anfang, damit dieser nicht in der doch länglichen Diskussion untergeht:
- Mechanik (Aussenteil):
- Am Liebsten hätte ich das Gira-106, das sieht richtig gut aus. Allerdings ist hier das proprietäre Busprotokoll nicht dokumentiert und die kapazitiven Tasten wird man vermutlich nicht anderweitig abfragen (GPIO) können.
- Also werde ich wohl auf Gira tx-44 zurückgreifen müssen. Bei Weitem nicht so elegant wie Gira-106, aber (zumindest auf den Bildern) nicht so grausam wie die Atomreaktor-Bedienteile aus den 1950er der anderen Anbieter. Die Elektronik mit dem proprietären Bus kann ich nicht brauchen, wird also fachgerecht entsorgt. Lautsprecher, Mikro und Tasten werden (entweder analog oder als USB) an ein Innenteil geführt.
- HW (innen): Raspi mit entsprechender Hardware (USB-Soundkarte (wegen Mikrofon+Lautsprecher), Verstärker, TÖ-Relais) wird im inneren (gesicherten) Bereich verbaut. Zur oben genannten Mechanik gehen lediglich Lautsprecher, Mikro, Verstärker-Spannungsversorgung. Oh, und natürlich Klingeltasten. Ob Audio analog oder als USB nach aussen geht dürfte reichlich egal sein.
- Bei Tastendruck wird zB linphonec aufgerufen (das ist die Kommandozeilen-Version von Linphone). Diese wählt fest vorgegebene interne Nummer(n).
- Linphone hat Config-Optionen zur Echo-Cancellation, also sollte das Rückkopplungs-Thema zumindest theoretisch lösbar sein. Gibt auch HW-Lösungen, ist aber teurer und benötigt zusätzlichen Platz. Erster Ansatz wäre also auf SW-Ebene.
- Weiterhin gibt es bei Linphone auch die Möglichkeit der DTMF-Erkennung: damit ein Relais zu schalten sollte also möglich sein.
- Bei Linphone gibt es auch die Möglichkeit einen Equalizer einzubinden. Damit sollte es möglich sein eventuell am Aussenteil eingespeiste DTMF-Signale wegzufiltern.
Soweit ich erkennen kann würde das alle meine Anforderungen erfüllen.
Das einzige Problem scheint mit zu sein, dass der Anruf auf eine Go-box (wegen DECT) gehen muss. An der Go-Box können sich leider keine anderweitigen SIP-Telefone anmelden.
Meine VOIP-Kenntnisse sind sehr spärlich, aber ich glaube ich würde hier eine interne PBX benötigen? Diese interne PBX würde sich beim Provider anmelden, und sowohl Go-Box als auch Raspi/Linphone würden sich an dieser internen PBX anmelden.
Alternativ könnte ich die Go-Box durch eine Fritzbox ersetzen, diese können ja sowohl SIP als auch DECT? Das sollte dann auch ohne interne PBX gehen und sollte auch einfacher zu verwalten sein als zB ein Asterisk?
Passt der Gedankengang in dieser Form halbwegs?
Nun zur Diskussion:
Deine eierlegende Wollmilchsau gibt es nicht.
Wo bitte habe ich geschrieben, dass das Ding Eier legen oder Wolle/Milch/Schnitzel erzeugen soll?
Meine (funktionalen) Anforderungen gehen nur wenig darüber hinaus, was bereits seit Jahrzehnten existiert:
- Taste wählt vorprogrammierte (interne) Nummer: Das gab es bereits zu Zeiten von Inspektor Columbo. Nannte sich damals Kurzwahltaste.
- Gespräch führen wenn der Ruf angenommen wird: das sollte doch eine Grundfunktion von Telefonie sein?
- Aktion ausführen wenn auf angerufenem Telefon bestimmte DTMF-Folge eingegeben wird. Das mag nun keine Grundfunktion eines hundsgemeinen Telefons sein. Aber unzählige Telefon-Menu-Systeme beweisen, dass das funktioniert, indem sie uns mit endlosen Menus nerven anstatt direkt zu einem Mitarbeiter zu verbinden.
Wo bitte ist das Ei? Wo die Wolle? Wo die Milch? Wo das Schnitzel?!?
Alles Grundfunktionen der Telefonie, oder nicht? Oder sollte ich mich verlaufen haben? Ich bin doch hier in einem Telefonie-Forum?
Wird das jetzt zu einer eierlegenden Wollmilchsau nur weil es so verpackt werden soll dass man (als Besucher) nicht unmittelbar Brechreiz bekommt wenn man das Aussenteil sieht?
Das ist nicht deine Anforderung, das ist vielleicht die gewünschte Funktionalität.
Und diese ist eigentlich sehr übersichtlich, siehe oben.
Anforderungen (oder im Softwareentwicklungssprech "Akzeptanzkriterien")
"nichtfunktionale Requirements" nennt man das bei uns (Hint: bin auch Entwickler, allerdings nicht im TK-Gewerk).
Oh, und es gibt durchaus "nichtfunktionale Requirements" die nicht explizit aufgeschrieben werden müssen sondern als Selbstverständlichkeit angesehen werden. Bei uns nennt sich das dann "Default-Requirements".
Und ja: in manchen Firmen werden die "default Requirements" durchaus ebenfalls dokumentiert, aber "global" und nicht explizit bei jedem Projekt. Ein Projekt übernimmt automatisch alle Default-requirements, die es nicht explizit (mit Begründung) ausschliesst.
Und als allererster Punkt steht in (unseren) Default-Requirements, man soll den gesunden Menschenverstand einschalten. Ja, hier gibt es eine wachsweiche Grenze.
Genau. Dafür gibt es Standards/Schnittstellen. zB a/b oder auch SIP/VOIP oder WasAuchImmer.
Dabei ging es mir um den proprietären Bus des Gira-106. Das 106 hätte ich echt gerne verwendet, macht optisch echt was her! Dummerweise zeigt der Hersteller keinerlei Interesse an der Fehlerbeseitigung des Gateways, mit dem man auf (wieder proprietäres?) SIP/VOIP kommt. Siehe verlinkten Thread im KNX-user-Forum.
Sorry, aber das sehe ich nicht als Option. Da nehme ich lieber die Türglocke aus Scary-Movie oder irgendwas anderes was es schon vor 200 Jahren gab. Das funktioniert immer.
keine ausgewachsene TK-Anlage
Wo bitte ist der Kontext!? Wieso benötigt man für eine TKS eine ausgewachsene TK-Anlage?
BTW: meine TK-Anlage ist Sipgate (ist Cloud, ich weiss). Soll ich diese jetzt entsorgen? Oder nur für die TKS eine zweite anschaffen?
Möglicherweise werde ich eine interne PBX benötigen, weil man an der Go-Box ja keine SIP-Telefone anmelden kann. Das muss aber doch nicht zwingend eine ausgewachsene TK-Anlage sein? Eine ausgemusterte Fritze kann doch auch SIP+DECT, das (oder etwas ähnliches) sollte es doch auch tun?
Ja!
In der Tat fehlt mir derzeit die Phantasie mir vorzustellen, wofür eine Cloud bei der TKS gut sein sollte.
Das Ding soll klingeln+quatschen+türöffnen. Und das bitte NICHT von irgendwoher auf der Welt sondern ausschliesslich lokal (und ja, Du darfst das gerne als ein neues Requirement ansehen falls das bislang noch nicht klar gewesen sein sollte...)
Also nochmal kurzgefasst: wenn es klingelt und ...
- ... ich bin zuhause: dann wird gequatscht und evtl die Tür geöffnet. Evtl macht man die Tür auch direkt ohne Gequatsche auf (zB weil man Besuch erwartet oder man zufällig gerade neben der Tür ist)
- .. ich bin NICHT zuhause: die Tür BLEIBT ZU! Quatschen unnötig! Wer quatschen möchte, der kennt meine Telefonnummer. Wer meine Nummer nicht kennt, mit dem WILL ich nicht quatschen!
Wie genau hilft mir eine Cloud hier weiter?
generell nicht "zu teuer"
Du siehst also den Preis von knapp 2000.- für die oben erwähnte eher schlecht als recht funktionierende Gira ohne Video als gerechtfertigt an? Für das Bisschen an "Grundfunktionalität" das ich oben erwähnt habe?
Das Haus habe ich schon, ich brauche nur noch eine (funktionierende) Klingel dazu...
keine in die TFE integrierte Kamera
Ja!
Habe keine Lust und auch keine Veranlassung die Eingangstür des Nachbarn zu filmen.
Nebenbei bemerkt, sieht das der Gesetzgeber auch so.
Wenn man mal mit offenen Augen durch die Strassen geht dann stellt man fest, dass in den allermeisten Gebäuden eine in die TKS integrierte Kamera nur sehr sehr selten (wenn überhaupt) gesetzeskonform umsetzbar ist.
Das hindert freilich niemanden daran, sich so ein Teil zu installieren. Es muss sich aber nur ein einziger Passant beschweren, dann ist das Ding schneller demontiert als es montiert wurde. Und nein: ein einfaches deaktivieren reicht definitiv nicht.
Anbindung externer Schaltfunktionen...).
?? Ich glaube hier verwechselst Du was., ich wollte keine "externen Schaltfunktionen".
Vielmehr wollte ich, dass Schaltfunktionen nicht vom Aussenteil initiiert werden können. Vereinfacht ausgedrückt: Ein beliebiger Passant soll nicht das Aussenteil abschrauben/abreissen und den Türöffner durch Überbrücken (oder Anlegen einer Spannung oder WasAuchImmer) betätigen können. Das sollte IMHO "CommonSense" sein.
Zusatzanforderung: Es soll niemand durch Diebstahl des Aussenteils zB WLAN-Passwort oder sonstige Zugangsdaten aus dem Speicher auslesen können (das wäre zB bei dem weiter oben im Thread genannten WLAN-TKS möglich). Zugangsdaten in einem Gerät zu speichern das sich in einem ungesicherten Bereich befindet und einfach mitgenommen werden kann... Das kann doch nicht ernst gemeint sein?
Du sagst zwar, aus deiner Sicht sei das alles selbstverständlich
Es gibt Sachen, die sollten einfach selbstverständlich sein, ohne das mühsam diskutieren zu müssen. Beispiele siehe oben.
aber die Realität ist eben zumindest einmal, dass es nicht so selbstverständlich ist, dass es entsprechende Produkte am Markt gibt.
Die Situation muss man also als gottgegeben hinnehmen?
Nur weil ich nicht bereitwillig Scheunentore in alle Richtungen bieten will, wird mir unterstellt eine eierlegende Wollmilchsau haben zu wollen...
Und die logische Konsequenz ist: Akzeptanzkriterien aufgeben, Kompromisse eingehen
Ja genau. Den Türöffner lege ich gleich auf einen Knopf im Aussenteil, da muss der "Besucher" dann wenigstens nicht das Aussenteil abreissen wenn er die Tür öffnen möchte.
oder selber bauen (lassen).
Damit kann ich leben. Wäre nicht das erste Projekt bei dem ich mich mangels vernünftiger Alternativen für einen Selbstbau entschieden habe.
Und nein: mir geht es dabei definitiv NICHT um die $$$$. Oben erwähntes Gira-106 für 2kEur hatte ich durchaus ernsthaft in Betracht gezogen bevor ich darüber gestolpert bin wie der Hersteller mit Qualitätsproblemen umgeht.
Gigaset [ ... ] Die sind ja auch nicht "übernommen" worden im Sinne von "aufgekauft", sondern sie waren schlichtweg insolvent und VTech hat die Teile gekauft, an denen sie interessiert bzw. bei denen sie - mit entsprechenden Synergieeffekten™ - eine Zukunft sehen (asset deal).
Wenn die also die Insolvenzmasse aufgekauft haben, dann ist es nur eine Frage der Zeit, wie lange es noch Updates gibt.
Es ist also wohl höchste Zeit, sich nach Alternativen umzusehen.
Wer kann da was empfehlen?
"Die Leute" wollen Zeug das einfach einzurichten ist / out of the box funktioniert. Und sich ggf. auch von überall einsehen/steuern lässt. Das lässt sich - einfach - über eine zusätzliche Instanz realisieren, die über das Internet erreichbar ist.
[ ... ]
Wenn man irgendwas vom Internet aus erreichbar haben möchte, nicht über das technische Wissen verfügt und sich dann bspw. mit Portweiterleitungen auf ggf. ungepatchte Systeme tolle Umgehungsstraßen für die Firewall des Routers und Direktzugänge für Rootkits baut, ist das auch nicht besser.
Ich erinnere mich dunkel an CT-Artikel, wo Leuten die WebCams aus vollkommen unbekannten Wohnungen aufgeschaltet wurden.
Das funktioniert hervorragendst ohne irgendwelche Portforwardings, technisches Wissen oder gar Umgehungsstrassen. Dafür muss lediglich der Hersteller und/oder Cloud-Betreiber hinreichend unfähig sein. Oder jemand mit hinreichend krimineller Energie eine Lücke im System finden.
Ich gebe Dir aber recht: das interessiert den OttoNormal einen feuchten Hundekehricht...
Aber ist das das Mass an dem man sich messen will? Und ist das die Richtung in die man marschieren will? Muss man das wirklich als gottgegeben hinnehmen?
BTW: Schon mal geschaut, was zB so ein Dreame-Staubsaugerroboter im Netz so treibt? Der redet zwar brav mit einem in der EU positionierten Server weil das wohl eine Voraussetzung ist den TüV-Stempel zu bekommen. Aber der ignoriert den per DHCP mitgeteilten DNS-Server und befragt stattdessen einen in China positionierten DNS-Server. HIER haben wir doch das (oben erwähnte) (Kuckuks-)Ei?
Spätestens seit Trump sollten wir doch auch US-Konzernen nicht mehr blind vertrauen?
Dass das OttoNormal nicht interessiert musst Du mir nicht sagen. Aber das Fähnchen hochhalten für die derzeitige (IMHO nicht akzeptable) Situation ist doch auch nicht wirklich angebracht.
Ich bin auch kein Freund von Cloudsystemen
Warum verteidigst Du diese dann so vehement?
Abhängigkeit davon, dass wenn bei irgendeiner Firma irgendein Server umkippt oder, prominente Beispiele gibts ja genug, ein Hersteller meint, Produkt X wird einfach mal eingestellt
Sorry, aber das ist doch noch der harmlose Fall!
Eine Cloud ist nur so lange gut, wie du dem Betreiber zu 100% vertrauen kannst. Beispiel obiger Staubsauger: das Ding hat eine Kamera und will eine KI in der Cloud befragen um Hundehaufen zu identifizieren. So weit, so schön, ABER:
- Es kann jederzeit beliebig durch die Wohnung fahren, und kann zu 100% (über eine Cloud) aus China gesteuert werden.
- Es hängt (bei OttoNormal) im normalen WLAN und kann (gesteuert über die China-Cloud) an den anderen Netzwerkgeräten anklopfen oder auch das WLAN-PW nach China übermitteln.
Wenn DAS mal nicht ein tolles Kuckuks-Ei ist?
Bietet die Fritze von OttoNormal überhaupt die Möglichkeit dem Ding das NachHauseTelefonieren zu untersagen?
(aktuellstes Beispiel vielleicht Bose SoundTouch), meine Türklingel nicht mehr funktioniert,
Das Problem ist nicht dass die Klingel nicht funktioniert, da sollen die Gäste dann halt eben klopfen oder anrufen. Wo bitte ist das Problem?
Das Problem ist vielmehr dass der Türöffner dann funktionieren könnte wenn Du es nicht haben wollen würdest.
Warum soll sich eine dunkle Gestalt mit auffälligen handwerklichen Tätigkeiten an Deinem Fenster bemerkbar machen wenn Dein Türöffner über eine Cloud gesteuert werden kann?
Aber ich gebe Dir Recht: OttoNormal will von der Strandliege aus dem Spanienurlaub den Türöffner betätigen wenn ein (vermeintlicher?) Paketbote klingelt. WTF?!?!?
aber für den Ottonormalverbraucher ist das unterm Strich die einfachere / komfortablere und ggf. auch sicherere Lösung.
Aber sicher doch! Einfach+komfortabel+sicher! Sarkasmus muss ich jetzt aber nicht explizit hervorheben?
Deine Umsetzungsidee ist ja technisch vollständig unabhängig von der Klingelgeschichte.
Genau das ist ja auch beabsichtigt: Funktion (man sieht was vor dem Haus passiert und damit auch wer vor der Tür steht) ist gegeben ohne unnötige Komplexität in die TK einbauen zu müssen..
Die Agfeo kann mWn auch als eine Art Integrator über verschiedene Systeme / Protokolle hinweg dienen, bis hin zu herstelleragnostischen Protokollen wie MQTT. Davon ab kannst du von den Systemtelefonen aus KNX-Hardware komfortabel steuern. Das konnten die IIRC schon als KNX noch EIB war.
Hmmm... Da muss ich mich wohl noch näher informieren.
Obwohl ich eigentlich ein Fan von klar getrennten Systemen mit klaren Schnittstellen bin. Wirft man alles in einen grossen Mixer, ist die Gefahr gross sich eine "Can of Worms" einzuhandeln.
Womit wir wieder beim Punkt von oben wären: Nenne mir gern einen Hersteller von DECT-Telefonen, der auf dem deutschen Markt tätig ist, selbst entwickelt, Expertise für Privat UND Gewerbe hat und auch nur ansatzweise noch so viel für Privatkunden tut und noch einigermaßen hochwertige Geräte baut wie Gigaset.
Sorry, kann ich nicht nennen: TK ist nicht mein Fachgebiet. Ich bin ja hierher gekommen in der Hoffnung hier Fachkompetenz vorzufinden. Insofern müsste ich diese Frage an Dich (oder auch andere Teilnehmer hier) zurückgeben.
Am ehesten fiele mir noch Fritz ein, aber, wie gesagt, in sich geschlossenes System, die ganzen tollen Features hat man nur, wenn man Fritzfone an einer passenden Fritzbox betreibt. Also proprietär.
Dass das Fritz-DECT proprietär ist wusste ich nicht. Dass die DECT-Reichweite unterdurchschnittlich sein soll habe ich aber schon mehrfach gelesen. Das ist auch einer der Hauptgründe, warum ich noch bei der Gigaset Go-Box bin, obwohl mich die gebotene Funktionalität nicht wirklich überzeugt.
Es war ja jetzt auch nur ein Beispiel.
Darüber hinaus hast du nicht richtig gelesen, ich schrieb von der Auerswald TFS universal plus, was keine TFE ist, sondern ein Modul bestimmt für den Einbau in bestehende Tableaus, würde also dein "potthässlich"-Problem lösen können.
Stimmt, da habe ich zu flüchtig gelesen.
Die Technik scheint aber die gleiche zu sein wie bei den Komplett-Teilen?
Ich schließe mich ansonsten
@chrsto an: Die TFS Dialog habe ich ebenfalls mehrfach verbaut, funktioniert absolut problemlos.
Ich hatte das Teil damals (1994) zwei mal verbaut, in einem Doppelhaus. Die eine DHH hatte eine analoge TK-Anlage (ets2006, wenn ich mich recht erinnere), meine DHH hatte eine ISDN ets2008i.
In beiden Installationen gab es diese Probleme mit der Rückkopplung, aber nur im fertig montierten Zustand. Wenn man das Aussenteil nur einen Zentimeter von der Wand weggenommen hat war gut.
An der ets2006 war es nicht so krass wie an der ets2008i. Dieser konnte ich die Rückkopplung abgewöhnen, indem ich den Lautsprecher (oder das Micro?) so leise stellte, dass man es gerade noch hören konnte.
Meine Seite mit der ISDN ets2008i habe ich aber nie zur Ruhe bekommen. Und mit Verlaub: wenn ich beim Support mit einem Rückkopplungsproblem aufschlage, dann ist das letzte was ich erwarte die Aussage "wenn das Ding auf dem Tiisch leigt und Du die Hand drüber hälst dann muss es Piepsen". Hey: genau dieses Piepsen will ich NICHT haben.
Weiß nicht, inwiefern das ein Beleg für irgendwas sein soll. Es sind halt Berichte. Oder wie ein Kollege von mir immer sagt: Das Internet bietet einem jede beliebige Meinung
Die Leute die sich da beschweren sind ja keine Unbekannten im KNX-User-Forum. Ganz im Gegenteil, das sind teilweise Leute, die die Dinger als Installateure für Kunden verbauen. Sind also keine Einzelfälle. Und alle berichten übereinstimmend, dass die V1 schlecht bis gar nicht funktioniert. Erst mit V2 (seit 2024 auf dem Markt) scheint das zumindest halbwegs brauchbar geworden zu sein. Nicht überzeugend für einen Hersteller, der seit Jahrzehnten am Markt ist. Einfach mal den Thread lesen!
Ich denke, der Schluss "Das ist von Firma X und teuer, als muss ich erwarten können dass es gut ist" hat noch nie so richtig funktioniert. Jeder Hersteller baut auch mal Mist.
Jeder darf mal Mist bauen, die Frage ist wie man damit umgeht. (ja, der Spruch ist nicht neu)
2kEur für eine Türklingel die nur manchmal (und dann mit erheblichen Verzögerungen) funktioniert und der Hersteller bei Reklamation sagt, man soll doch das Nachfolgemodell (ohne Kostennachlass) kaufen?
Sorry, nicht mein Ding! Für das Geld lasse ich mir lieber die Türglocke aus Scary-Movie bauen. Die erfüllt den Zweck zuverlässig und ohne irgendwelche Verzögerungen.
Je nach Paranoia-Level: Ein WLAN das von außerhalb der eigenen Grundstücksgrenze erreichbar ist
Du hast den Unterschied nicht erkannt.
Die eine Sache ist: ein (mit gutem PW abgesichertes) WLAN ist sichtbar/erreichbar (dürfte der Normalfall sein)
Die andere Seite ist: in einem Aussengerät ist das WLAN-PW (oder andere Zugangsdaten) womöglich im Klartext abgespeichert und jeder Passant kann dieses Gerät mitnehmen und zuhause in aller Ruhe den Speicher auslesen.
Ich sehe hier einen deutlichen Unterschied. Du nicht?
Es gibt BTW auch tolle Angriffszenarien die man über KNX fahren kann
Weiss ich. Deswegen gibt es bei mir auch keine Aussenlinie. Alles ist im "gesicherten Bereich" verlegt.
Willst Du an mein KNX, musst Du erst die Aussenhaut durchdringen.
Einfach und effektiv...
Hey: und funktioniert ganz ohne Cloud!
Man kann an jedem etwas Schlechtes finden, es ist halt auch immer die Frage, was die Schutzziele sind. Ist ja nicht so als hätte die SIP-TFE eine Tastenkombination mit der sie einem ihre Zugangsdaten vorliest.
Wenn die Zugangssicherung lediglich eine Torx-10-Schraube ist und man danach beliebig Zugriff hat auf Türöffner/Ethernet/WLAN-PW/WasWeissDennIchWasSonstNoch, dann wird das Eis sehr schnell sehr dünn.
Woher habe ich die Gewissheit dass der Hersteller die Zugangsdaten so abgelegt hat dass man nicht mit einem einfachen Debugger drankommt?
Ich frage mich, ob es da wirklich "Besser" ist, einen LAN-Port "außer Haus" zu legen.
Kann mich nicht erinnern solches geschrieben zu haben.
Ganz im Gegenteil: in meinem in #8 skizzierten Bastel-Konzept befinden sich lediglich Lautsprecher, Mikrofon und Klingeltasten im Aussenteil. Alles was in irgendeiner Form eine Entscheidung trifft oder eine Aktion auslöst befindet sich im inneren Bereich.
Einfach und effektiv.
Aber zurück zur eigentlichen Fragestellung;
Wie ich es lösen würde:
- Einfache SIP-TFE (wie die von Fanvil)
- Smart Home-System nehmen, das SIP kann, das Smart Home System ist selbst SIP-Tln in der Fritzbox, gehen wir mal von Home Assistant aus (mit Symcon hab ich sowas schon umgesetzt)
- Die SIP-TFE ruft eine Rufgruppe an, die Rufgruppe enthält alle Teilnehmer die Türrufe bekommen sollen UND Home Assistant
- Home Assistant beantwortet den Ruf jedoch nicht, sondern nutzt lediglich das INVITE als Trigger um wem/was auch immer Bescheid geben zu können dass gerade geklingelt wird
- Türruf wie gehabt, einfach beantworten
- Home Assistant bekommt noch eine zweite Rufnummer. Wird es über diese angerufen, nutzt es den Zeitstempel vom Trigger, um die Tür Öffnung nur durchzuführen, wenn sie im zeitlichen Zusammenhang mit klingeln steht (kann man so implementieren, muss man aber nicht)
- Bei Anruf auf der zweiten Rufnummer wird ein Webhook von einem IP-Relais oder wasauchimmer aufgerufen, um das Relais zu schalten.
Was man auf diese Weise nicht hat, ist das Tür öffnen per DTMF, sondern man ruft dazu eben eine besondere Türöffnungsrufnummer an.
Hmm, ja. Guter Hinweis, den Türöffner über einen separaten Anruf zu betätigen hat was. Damit hat man auf jeden Fall nicht das Risiko, dass die DTMF-Filterung versagt und der "Besucher" durch entsprechendes "Pfeifen" Zugang erlangen könnte.
Wenn DTMF doch unbedingt ganz dolle wichtig ist:
Nö, ist es nicht!
Wir haben jetzt 8 Jahre ganz ohne Klingel/Türöffner überlebt. Besucher/Postboten mäckern zwar gelegentlich weil ihnen die Fingerknöchel weh tun, aber damit kann ICH leben...
Dein Vorschlag, das durch einen separaten Anruf zu machen ist mir aber durchaus sympatisch!
ein Asterisk nehmen, sähe dann wie folgt aus:
- Das Asterisk ist Tln. an der Fritzbox
- Die SIP-TFE ruft das Asterisk an
- Das Asterisk baut Rufe zu den Tür-Tln. auf und "brückt" beide Teilnehmer, lauscht aber auf DTMF
- Auf diese Weise läuft die Sprache zwischen TFE und DECT-Tln, aber durch das Asterisk wir auf die DTMF-Sequenz geachtet
In dem Fall bräuchte es für dieses Projekt dann kein Smart Home System, den HTTP-Call gegen das IP-Relais kann dann auch das Asterisk machen.
Das scheint mir komplexer zu sein als nötig. (BTW Fritzbox habe ich derzeit nicht: mein Router ist eine PfSense)
PS: UFFF! Ich finde diese Foren-Regel, dass in 24 Stunden nur ein Beitrag erfasst werden darf sehr mühselig. Das führt doch nur zu unsäglich langen Beiträgen, wo auch keine vernünftige thematische Trennung möglich ist. Zwangsweise packt man dann vollkommen unabhängige Themen in einem einzigen ewig langen Beitrag zusammen. Das scheint mir eher kontraproduktiv zu sein. Ist das wirklich beabsichtigt oder habe ich nur das Konzept nicht verstanden?
