Das mit der Brennweite ist echt nochmal ein Argument. Ich hatte auch irgendwie übersehen, dass die 9008 keinen Zoom hat.
Ich kann dir die Frage zwar nicht beantworten, wie das funktioniert, aber es scheint zu funktionieren, wenn ich die Instar Homepage richtig interpretiere:
Kann das jemand bestätigen oder dementieren?
Du hast es doch eigentlich schon selbst zitiert:
Das heißt, dass bei Benutzung der PTZ-Funktion die beiden Alarmerkennungsfunktionen (Bewegungserkennung und PIR) deaktiviert werden sollten, um Fehlalarme zu vermeiden.
Ja, wer lesen kann ist klar im Vorteil 
Danke @ch.krause
Wenn ich das aber hier richtig verstanden habe, kann ich die Alarmerkennung per Webhook ausschalten, dann schwenken und wieder einschalten?
So ist es
Die starren Kameras können sich natürlich auch gegenseitig
überwachen. Außerdem habe ich bei einer beweglichen Kamera
eventuell das Problem, dass sie nicht zur richtigen Zeit auf den richtigen
Ort schaut, zumindest beim aufzeichnen. Andererseits habe ich bei einer
beweglichen Kamera den Vorteil, dass ich zumindest wenn ich manuell
eingreife sicherlich ein größeres Spektrum abdecken kann.
Das sich gegenseitig überwachen läßt sich eigendlich besonders gut mit PTZ Kameras bewerkstelligen.
Normalerweise rate ich immer von der Anschaffung einer PTZ Kamera ab, wenn man noch nicht 100%ig weiß, ob man die Beweglichkeit braucht oder nicht. Die erste Woche ist die Kamera das neue Spielzeug mit dem man sich ständig verbindet. Danach bleibt die Ausrichtung dann häufig unverändert und eine starre Kamera hätte es auch getan.
Anders sieht es aus, wenn man ein Smarthome System wie homee einsetzt und eine Anwendung für einen automatischen Schwenk sieht. Dem Nachteil, daß die Bewegungserkennung beim Schwenken anschlagen würde, kann man - wie bereits erwähnt - per Automatisierung entgegenwirken.
Das Alarmserver Update ist jetzt im Auto-Updater verfügbar (für Full HD Kameramodelle):
D.h. man muß jetzt nicht mehr im homee Webhook die lokale IP des homee Gateways eintragen. Es spricht aber natürlich nichts dagegen dies dennoch zu tun.
Der Nachteil der Nutzung der lokalen IP ist, dass sich die Kamera und das Gateway im gleichen Netzwerk befinden müssen. Außerdem kann sich die IP Adresse von Geräten im Netzwerk mit der Zeit ändern (wenn DHCP aktiv) und man somit die Verbindung verlieren. Wenn man den homee Domännamen nutzt, ist man davor geschützt.
Der Vorteil der Nutzung der lokalen IP ist, dass man kein Internet braucht um den Webhook zu kontaktieren.
Hallo,
Ich habe da mal eine möglicherweise dumme Verständnisfrage: warum geht der PIR Sensor erst anzuschalten, wenn die Kamera Alarm gibt? Siehe
9008er Model.
Ich sehe das ja eher anders herum: der PIR meldet Bewegung und dann gehen die IR Dioden an und die Kamera schaut sich das Ganze an und entscheidet anhand der eingestellten Kriterien, ob es ein Alarmfall ist. Damit bleibt die Kamera längstmöglich “unsichtbar”, da die IR Dioden nicht dauerhaft an sind.
Vielleicht ist das ja bereits so, nur ich habe die Konfiguration diesbezüglich noch nicht verstanden.
Hallo @tpheine,
das wäre dieser Anwendungsfall:
Vielen Dank für die schnelle und detaillierte Antwort!
Wissen Sie den Hintergrund, warum das nicht in der Software der Kamera selbst zu konfigurieren geht? Mein paranoides Ich hat gerade ernsthafte Bedenken das so mit Homee als Trigger umzusetzen, da man sich so neue Angriffsvektoren oder Fehlermöglichkeiten eröffnet.
Die Kameras werden von uns ständig erweitert. Programmierbare Touren, unterschiedliche Alarmbereiche je nach Tageszeit, usw - alles häufig nachgefragte Funktionen die wir in den letzten 12 Monaten hinzugefügt haben.
Der Grund warum wir uns - und speziell ich mich - nach Smarthome Lösungen umgesehen habe, ist das wir einfach nicht flexibel genug sind. Die Firmware ist für Sicherheitsprodukte geschrieben, die für den Dauereinsatz ausgelegt sind und das mit robuster Hardware, die recht widrige Umfeldern eingesetzt werden kann und dabei so wenig Strom wie möglich verbraucht.
Wir können all das was oben beschrieben ist so umsetzen - aber nur mit festen Vorgaben dazu, welche Einstellungen verändert werden und wie lange der Alarmzustand anhalten wird. Und ich kann mir sehr gut vorstellen, dass das auch in Zunkunft in die Firmware einfließt, wenn genügend Kunden daran interessiert sind. Eine starre Lösung, die für die meisten Probleme ausreichen wird.
Mit homee, als Stellvertreter für Smarthomes, ist das anders - hier kann jeder alles so zusammensetzen wie er es gerade braucht. Man kann in der Regel zu einer perfekten, smarten, individuell auf das Problem abgestimmten Lösung kommen.
potentiell fehleranfällige Komplexität vs unflexible aber sichere Simplizität
Es gibt für beides Anwendungen - am besten ist es immer beide Optionen zu haben.
Aber es gibt hier im Forum ja mittlerweile einige die dahin gehend Erfahrung sammeln konnten. Wie schaut der Dauereinsatz einer IP Kamera gesteuert durch das homee Gateway aus? Bedarf es da gesunder Paranoia? Und hat eventuell schon jemand Anwendungen bzw. Verbesserungen gefunden, die wir in unserem Wiki nicht beschrieben haben?
Ich übe keine Kritik an INSTAR, im Gegenteil. Ich bin seit vielen Jahren treuer und mehr als zufriedener Kunde und ihr schafft es mit jedem Update aufs Neue, mich zu überraschen und zu begeistern.
Meine Fragen hier sind tatsächlich meinem Interesse geschuldet, das Maximum an euren Produkten für meinen Anwendungsfall heraus zu holen und natürlich euer Produkt in Gänze zu verstehen.
Und wie ihr schon sagt, sind eure Produkte für sehr hohe Sicherheit, Robustheit und Langlebigkeit konzipiert. Eben genau das Gegenteil von Homee - was keine Kritik an Homee sein soll. Daher scheue ich mich, die Sicherheit von INSTAR primär einem unsicheren System zu überlassen und es damit unsicher zu machen.
Mein Anwendungswunsch zur Erklärung: die IR Dioden sind nachts sichtbar und verraten den Standort, ziehen auch Insekten an etc pp. Daher würde ich die gern erst anschalten, wenn der integrierte PIR getriggert wird. Die IRs sollen also nicht unnötig lang an sein. Das würde neben dem Vorteil der Nichtsichtbarkeit bei Nacht auch noch mehr Strom sparen und die Haltbarkeit verbessern.
Ich habe einfach nur Angst, dass wenn homee sich mal wieder verschluckt und Webhooks nicht triggert, oder das Netzwerk aus ist (Strom gekappt bspw), dass die Kameras eben nichts Aufzeichnen, weil die Dioden nicht angeschalten werden und die damit nichts sehen.
Im Prinzip eine gute Idee. Allerdings würden dann die x sek. Dunkel bleiben, die vor der Bewegungserkennung ebenfalls aufgezeichnet werden. Und die sind oft entscheidend.
Aber insgesamt ein durchaus brauchbares Feature. Stealth Mode sozusagen. 
Danke. Und durchaus sinnvolle Einwände zum Stealth Mode . Und ja, man kann sich sicherlich auch über eine abschreckende oder gar anziehende Wirkung von IR Dioden streiten.
Habe es bei mir so umgesetzt. Seit dem keine Spinnen mehr.
Ich denke das Sie Gefallen an der INSTAR MQTT API finden werden, die wir gerade in unsere Full HD Kameras integrieren. MQTT ist ein Maschine-zu-Maschine (M2M) Kommunikationsprotokoll, das speziell für den Einsatz in IoT entwickelt wurde. Genau das Problem, dass bei HTTP Anfragen gelegentlich verschluckt werden, wurde hier über ein PubSub (Publish/Subcribe) Modell behoben. Hierfür gibt es beim MQTT einen zentralen Server (Broker), bei dem sich alle eingebundenen Geräte melden (Publish), wenn sie etwas zu sagen haben (bzw. im regelmäßigen Intervall, wenn sie auf eine Nachricht warten).
Jeder Klient muß beim Server alle Informationen abonieren (Subscription) die ihn interessieren und bekommt sofort alle Updates ge-pushed, wenn er das nächste mal online kommt. D.h. es gibt keine Zeitüberschreitungen mehr mit denen Informationen verloren gehen.
Der einzige Schwachpunkt dieses Protokolls ist die Zentralisierung durch den MQTT Broker. Wenn dieser ausfällt, ist das gesamte Netz offline. Verloren gehen die Daten natürlich dennoch nicht, da die Klienten erst aufhören sie zu senden, wenn sie die Empfangsbestätigung durch den Broker haben.
In der Praxis schaut das so aus - wenn man z.B. Sensoren über MQTT in eine Smartphone App eingebunden hat - sobald man mit dem Handy online geht, springen sofort alle Anzeigen auf den aktuellen, zuletzt empfangenen, Wert. Und das ohne das man Anfragen an alle einzelnen Geräte senden muß - die Sensoren müssen in diesem Moment noch nicht mal online sein (was bei IoT Geräten häufig der Fall ist um Strom zu sparen). Was das ganze dann auch noch sehr schnell macht.
Wie hast du es genau umgesetzt?
Das klingt vielversprechend und ich werde mich damit mal auseinandersetzen. Vielen Dank für die Geduld, Einsichten und Lösungsvorschläge!
Ein Hinweis zum letzten Update der Full HD Kameramodelle.
pushhostalarm Befehl mit einem PTZ Befehl kombiniert hatte, würde jetzt der Alarm durch die Pan&Tilt Bewegung maskiert werden:/param.cgi?cmd=pushhostalarm&cmd=preset&-act=goto&-number=1
Man kann die Alarmunterdrückung aber auch unter Features/PTZ in der WebUI der Kamera wieder deaktivieren.
getscheduleex jetzt in einer BackUp Variable getbackupschedule. Bei einem kurzeitigen deaktivieren des Alarms wird dann beim aktiven Alarmzeitplan alles deaktiviert - mit "N"s überschrieben. Beim aktivieren des Alarms wird dann der Zeitplan wieder gemäß der BackUp Variable hergestellt.Wenn man über homee - wie es bisher in der Anleitung stand - den Alarmzeitplan deaktivert, funktioniert das weiterhin. Man sieht die Änderung aber nicht in der WebUI der Kamera. Um das zu verhindern, kann man in homee einfach beide Zeitpläne gleichzeitig switchen. Der kombinierte CGI Befehl ist in der Übersicht hinzugefügt wurden.
Wenn man die Kamera WebUI nicht nutzt, braucht man nichts zu ändern.
Wir hatten gerade noch eine Support Anfrage bzgl. des Aktivieren der IR LEDs durch das homee Gateway, wenn der PIR Sensor eine Bewegung erkennt. Dieser Anwendungsfall ist in der Anleitung nur skizziert dargestellt. Wir haben daher jetzt eine Schritt-für-Schritt Anleitung in unsere FAQs aufgenommen.