Es wäre schön, wenn homee den Weg der offenen Standards weiter beschreiten und lokale cloud-freie
Systeme/Produkte stärken würde.
ONVIF definiert in mehreren Profilen Standard-Schnittstellen für Zutrittskontrollsysteme und Videosysteme. Schaut’s euch doch Mal an und denkt drüber nach.
Bei konkreten Produkten denke ich dabei an die INSTAR Kameras und den Axis A1001 Door Controller.
Gerade bei Kameras fehlt eine Alternative zur proprietären, Cloud-basierten Netatmo Welt. Und die Instars sind bereita sehr beliebt.
Bei den “Zutrittskontrollsystemen” fehlt ebenso eine batterielose, verdrahtete Alternative zu Nuki (und Danalock).
Welchen Nutzen erwarte ich mir davon?
Mit der Implementierung einer Standard-API viele neue kompatible Geräte für homee. Die Usecase sind vielfältig.
Bewegungserkennung, (automatische) Türöffnung, Anwesenheitserkennung, Alarmanlage, …
Ich habe neben Instar noch weitere Anbieter im Gebrauch, die diesen Standard nutzen. Bspw. unter Android gibt es bereits Apps die sich diesen Standard zu Nutze machen und man kann Herstelleruebergreifend auf seine Cams zentral zugreifen.
IMHO sind die oben angedachten Use Cases vor allem im Bereich der Bewegungserkennung interessant.
Wir nutzen in der Firma diverse Events, die über die ONVIF-Schnittstelle geschickt werden, um z.B. bei BOSCH-Kameras neben der Bewegungserkennung auch die erweiterten Funktionen, wie Intrusion-Detection, Brandfrüherkennung usw. die von entsprechenden Modulen auf der Kamera erkannt werden, anzuzeigen und weiter zu verarbeiten.
das Problem mit klassische IP Kameras ist der Videostream. Im Gegensatz zu Cloud Kameras - wie Netatmo usw. - läuft der Videostream nicht über einen externen Server bevor man ihn sich anschauen kann. Man hat stattdessen direkt lokalen Zugriff auf die Kamera.
Wir finden das gut, da es bedeutet, dass man Videostream im eigenen Netzwerk „einsperren“ kann und so nicht um seine Privatsphäre bangen muss.
Aber das bedeutet auch, dass man den Videostream nicht so ohne weiteres in Webseiten/Web-Apps (wie dem homee Dashboard) einbinden kann. Um das zu tun ist eine von zwei Dingen notwendig:
Man legt eine Portweiterleitung im Router an und bindet die Kamera über Ihre DDNS Adresse ein. Damit hat man dann auch von außerhalb direkten Zugriff auf den Kamerastream. Aber es bedarf etwas Netzwerk-Wissen und ist somit nicht optimal.
Man muß den Stream aktiv zum entsprechenden Server pushen – was nicht ganz so trivial ist. In der Regel wird für dieses Setup der JPG anstatt der h.264 Stream verwendet. Ein Beispiel ist da OpenHAB2 (und auch ein Hersteller aus den Niederlanden mit verwirrend ähnlichen Namen). Diese kommen mit einem Online Dashboard in dem man das Live Bild der Kamera einbinden kann. Dafür muss die lokale Installation des Smarthome Gateways einen Schnappschuss von der Kamera abgreifen und raussenden, sobald jemand auf das Dashboard zugreift. Wenn dieser eingetroffen ist wird sofort der nächste gesendet. Man erhält damit eine Bildwiederholungsrate von ca. einem Bild alle 3-10s. Was nicht optimal ist, aber funktioniert und mit allen IP Kameras umsetzbar ist. Und man kann natürlich auf den lokalen ONVIF Stream switchen sobald die App merkt, dass sie im gleichen Netzwerk ist wie die Kamera.
Ein großes Projektfeld für uns bei INSTAR ist das Umsetzen von offenen Standards, um das Einbinden in Drittanbieter Anwendungen so einfach wie möglich zu machen. Wir haben bereits die umfangreiche und dokumentierte HTTP API (CGI Befehle), ONVIF Support, RTSP/MJPEG/JPG Videostreams, usw.
Aber es gab auch noch ein paar Schwachstellen, die wir jetzt nach und nach ausbessern. So gab es ursprünglich ja das Problem, das wir das homee Gateway nicht per HTTPS ansprechen konnte um einen Alarm zu melden – weshalb dort nur der Zugriff über die lokale IP (mit HTTP) möglich war. Wir werden dafür die Tage ein Update (für Full HD Kameramodelle) veröffentlichen, wo der dafür verwendete Alarmserver aktualisiert wurde und jetzt auch HTTPS und POST Request unterstützt.
Ein weiteres Feature an dem wir jetzt schon eine Weile arbeiten und das kurz vor dem Release steht, ist ein MQTT Interface (MQTT ist… sagen wir einmal… das kabelgebundene Äquivalent zu Z-Wave, Zigbee & Co.). MQTT lässt sich ja bereits jetzt mit Hilfe von Node-RED mit dem homee Gateway koppeln und macht das Einbinden von Kamerafunktionen zum Kinderspiel. Sobald wir die finale Version haben, werden wir dafür umgehend eine Anleitung bereitstellen.
Wir sehen Smarthome als Team Sport – offene Standards sind der beste Weg nach vorne. Mit der herrausragenden und intuitiven Dashboard UI und der Unterstützung von so diverser Drittanbieter Sensor & Aktor Hardware ist homee + INSTAR ja schon jetzt eine äußerst solide Lösung. Wir sind am Ball, damit das auch so bleibt
Eure instar Kameras funktionieren (was die Anzeige auf dem dashboard angeht) auch super einfach mit home Assistant. Man tippt in die config Datei 2 Zeilen Code rein und tada…
Wir sind auch gerade dabei unsere Anleitungen für Home Assistant zu aktualisieren. Das ist die Smarthome Lösung die am meisten vom neuen Alarmserver und dem MQTT profitiert. Habe ein Test System hier für die Anleitung aufgesetz, dass die gesamte MQTT API + Live Video eingebunden hat.
War ein Kinderspiel mit der neuen Software. Der aktualisierte Alarmserver kommt die nächsten Tage. Das MQTT braucht eventuell noch ein wenig Zeit - läuft auf den Testsystemen jedoch schon stabil.
Könntet ihr den Stream Nichteinhaltung der Kamera in ein m3u8 ( als ts ) umwandeln so das in der Index Datei alle Daten geschrieben werden und über homee genutzt werden können.
Bei der Netatmo wird es genauso gemacht und Streams laufen auch lokal darüber.
Dann könnte man die Sache recht schnell einbinden.
Es gibt Bestrebungen Änderungen am Stream vorzunehmen. Welche Verbesserungen davon letztendlich umsetzbar sind, dazu kann ich leider noch nichts sagen.
Aber Kompatibilität ist uns generell sehr wichtig.
Edit:
Ich habe gerade mal nachgehört - etwas in der Richtung steht bereits auf der Liste. Aber ich kann leider noch keine Details dazu nennen.
