Wir wollen hier sicher keine Grundsatzdiskussion führen - natürlich soll DoorPi nicht die gesamte Hausaustomation steuern. Die verteilte Lösung macht m.E. aus Sichrheitsgründen Sinn.
Und gerade zur Einbindung in FHEM habe ich ja das entsprechende Modul geschrieben.
LG aus Stockholm
pah
Deswegen finde ich eigentlich das genau das was Thomas vorgeschlagen hat einen enormen Mehrwert hat. Ich kann überall da wo ich eine direkte Automation oder Überwachung brauche für 4$ einen Einplatinenkomputer hinbauen und habe genau das was ich dann möchte oder benötige. Für 4$ bekomme ich keine FHEM. Ich kann in meinem Pool die Vorlauftemperatur und die Rücklauftemperatur sowie PH Wert, fast, in Echtzeit überwachen genauso auch an meinem Heizsystem (Wärmepumpe). Wenn dann mal etwas defekt ist ist das doch auch schnell lokalisiert und komplexer wird das System auch nicht viel mehr und da wäre nichts was ein Pi3 nicht schaffen würde. Ich habe es doch dann relativ Wartungsfreundlich.
Gruß Nea
Das kannst Du über 1-Wire aber auch ohne die 4$ auszugeben direkt über den Pi. Letztlich muss das Signal vom Zero irgendwie zum (Door-) Pi. Das ist über UART/I2C/SPI ungleich aufwändiger als über 1-Wire. Da ist es einfacher direkt das Signal vom Sensor da hin zu führen, oder? Zumal 1-Wire ein sehr robuster Industriestandard ist. Dafür gibt es auch entsprechende Sensoren.
@Nea:
Im Prinzip haben wir doch ungefähr das gleiche gesagt oder? Ich schrieb ja auch, dass ich die Server-Client Lösung eine gute Idee finde (optional natürlich). Ich schrieb nur, dass man nicht zu viel Funktionalität hinein packen sollte- die Beispiele die @motom001 zuletzt genannt hat, sind im Grunde genau die von dir angesprochenen "Spielereien" (Garage öffnen, Licht einschalten).
Ob man sowas "braucht" oder nicht, muss jeder selbst entscheiden. Ich bin nur der Meinung das sowas nichts in DoorPi verloren hat, denn genau diese Dinge können andere Systeme (FHEM ist nur ein Beispiel) besser.
Ich halte es einfach für eine schlechte Idee, aus dem DoorPi Projekt jetzt eine universelle Steuerzentrale für allerlei Sensorik zu machen.
Ich wollte keinem hier auf die Füße treten.
mea maxima culpa
Aber lassen wir doch mal die Kirche im Dorf, wer in mein Netzwerk einbrechen kann der macht nicht halt bis jedes meiner Systeme offen ist. Da stellt sich mir aber die Frage dann warum nimmt einer soviel Arbeit in kauf.
@Joker
Aber genau das fände ich nicht schlecht...
Naja, weitere Sensoren einzubinden ist ja nicht wirklich ein Problem. Auch wenn ich drauf rumreite, 1-Wire ist für viele Sensoren super geeignet. Mit OWFS lässt sich das super einfach nutzen. Das dürfte auch einfach in DoorPi zu integrieren sein.
Audio/Video zu digitalisieren ist nicht so das Problem. Eine vernünftige Übertragung schon, selbst in leistungsfähigen, überwachten Netzwerken. Das gehört zu meinen täglichen "Sorgen". Sicher sind ein par hundert MS Latenz bei einem Wechselsprechen nicht so das Drama. Unschön ist es doch. Und es ist immer Echtzeit. Lies Dich mal ein bisschen in RTC Protokollen ein. Da wird ein ziemlicher Aufwand für Fehlerkorrektur etc. betrieben. Bei dedizierten Verbindungen ist das sicher etwas einfacher, aber allein Audio und Video über eine Verbindung zu multiplexen dürfte nicht ganz trivial sein. Ich würde hier auf standardisierte Verfahren zurückgreifen.
Ich wollte keinem hier auf die Füße treten.
Hast Du nicht, zumindest nicht mir. 
Ich stelle das auch nicht grundsätzlich in Frage. Es gibt für alles Anwendungsfälle. Die Frage ist nur, lohnt der Aufwand? Oder kommt man einfacher zum Ziel? Und so etwas zu diskutieren halte ich für wichtig. Ich habe in den letzten 3 Wochen mind. 10x mein DoorPi Projekt geändert....
Hast Du nicht, zumindest nicht mir.
Mir auch nicht, keine Sorge 
Ich werde eine solche Ausbaustufe im Auge behalten, aber mich wieder mehr auf die Grundfunktionen fokusieren.
Das halte ich für eine sehr gute Idee. Meiner Meinung nach ist DoorPi das einzige verfügbare (Open-Source) Projekt, dass wirklich Potential hat im Türsprechanlagen Bereich. Dennoch - und das meine ich nicht als Kritik - hat es noch einige Schwächen, und die sollten zuerst verbessert werden, bevor man immer mehr Funktionalität rein packt. Ich entwickle seit vielen Jahren beruflich Software, und ich habe schon einige Projekte den Bach runter gehen sehen, weil man sich nicht auf den Kern konzentriert hat, sondern immer mehr Funktionalität rein gepackt hat, die dann nur halbherzig funktioniert (das angesprochene Thema Ressourcen ist da natürlich ein Hauptthema). Deswegen gehen da bei mir alle Alarmglocken an
Ich möchte auch keine DoorPi Installationsanleitung die beginnt mit "installiere FHEM".
Falls es so rüber gekommen ist, dass ich sowas favorisieren würde, dann ist das ein komplettes Missverständnis. Im Gegenteil, es sollte eine klar definierte Schnittstelle zwischen beiden System geben, und ansonsten beide System völlig autark sein.
Wenn es jemanden gibt, der eine Verbindung herstellt bin ich sehr froh und werde versuche das aktuell und in Zukunft zu unterstützen. Aber Zwang soll das nicht werden.
Das mit dem Zwang sehe ich genauso, siehe oben. Es sollte die Schnittstelle geben, und ob das jemand nutzt oder nicht ist jedem selbst überlassen. Genauso sollte es aber generell sein- auch das Client-Server Thema sollte optional sein, eine prinzipielle Umstellung auf Client-Server halte ich für falsch.
Das kann ich uneingeschränkt unterstützen. Doorpi sollte ein spezialisiertes (d.h. Türsprechstellen-) System bleiben und nicht zu einer universellen Haus- oder Sicherheitslösung werden.
Lg
Pah
Alles anzeigen@AndyGR42
Dann kann ich laut deiner Aussage das doorpi Projekt stoppen, denn ohne eine Übertragung von Audio und Video über ein Netzwerk hat das ganze keinen Sinn.
Und dann wäre VoIP grundsätzlich auch sinnfrei...
Natürlich hab ich das jetzt stark überspitzt ausgedrückt, aber ob die Signale von Pi3 über Netzwerk an die Innenstelle gehen, oder von Zero an Pi3 ist aus meiner Sicht doch die gleiche Netzwerk-Belastung...
...vorausgesetzt das nicht Pi3, Zero und Client am gleichen Switch hängen...
Oder reden wir gerade soweit aneinander vorbei?
Teilweise.
Wenn ich das richtig sehe hat der Zero keine LAN/WLAN Schnittstelle. Du hast selbst I2C oder SPI als mögliche Verbindung angeführt. Da wäre die Übertragung von A/V dann eine prioritäre Eigenentwicklung, die echt aufwändig wird. Du verwendest mit DoorPi (und linphone) SIP und RTC. Das sind standardisierte IP Protokolle, welche die meiste Arbeit für dich machen. Wenn der "Slave" die auch nutzen würde, wäre das auch ok. Nur benötigt das LAN/WLAN. Wenn man dem Zero nun einen WLAN Stick spendiert, könnte man durchaus weiter kommen. Das würde auch eine direkte Kabelverbindung zwischen Pi und Zero unnötig machen. Allerdings müsstest Du vermutlich ein Protokoll für die Kommunikation der Komponenten untereinander bauen, welches idealerweise ausreichend verschlüsselt ist. Kein Hexenwerk aber mit Aufwand verbunden. Ich würde in jedem Fall bei Standard Schnittstellen bleiben. UART für reine Steuerung und/oder IP für A/V
BTW, hat jemand eine Bezugsquelle für die neue Version des Zero gefunden? Ich finde nur Händler wo das Teil ausverkauft oder (noch) nicht lieferbar ist.
