Migrationstrouble IN-8015 -> IN-8815

4K Kameras IN-8815 4K
1

Hallo Instar-Team.

eigentlich wollte ich, nachdem Instar endlich auch 4K Kameras hat, meine IN-8015 auf die Schnelle erneuern durch eine IN-8815. Die Kamera wird aus einer Node-RED Hausautomatisierung gesteuert.

Erstes Problem: Die neue FW erzwingt Passwörter mit Sonderzeichen. Eigentlich eine sinnvolle Idee. Aber in diesem Fall landen die PW in http Requests. Und da sind Sonderzeichen doch etwas tricky.

Zweites Problem: Der User muß mindestens fünf Buchstaben haben. Tja ´Gast´ geht da nicht mehr.

Drittes Problem: Die Aufrufe für Streams, MJPG, Images usw. wurden scheins geändert. Die Authentisierung innerhalb des http-Requests macht Probleme. Einen bisher funktionierenden ´http requst´ NR-Node bekomme ich nur mit zusätzlicher Basic-Auth in Gang.

Lt. Doku sollte eigentlich gehen, tut aber nicht:

http://192.168.x.x/snap.cgi?chn=12&user=Admin&pwd=xyz#

Die ´schnelle Migration´ hab ich jedenfalls abbrechen müssen und debugge mich jetzt durch Doku und NF-Fows.

Grüße

Ingo

2

Ist weiterhin möglich - müssen nur entpsrechend kodiert werden. Siehe URL-Encoding:

Sollte genauso funktionieren - solange das Login entsprechend URL-sicher ist:

http://192.168.x.x/snap.cgi?chn=12&user=admin&pwd=password

Was kommt denn für eine Fehlermeldung, wenn man diesen Befehl in die Adresszeile des Browsers eingibt?

3

Das ist der einzige Punkt, der mich bei den neuen Instar-Produkten so richtig ärgert. Aber so richtig, bis hin zu „ich-kaufe-kein-Instar-mehr-richtig.“

Das ist MEINE Kamera. Wenn ICH beschließe, daß mein Passwort „Geheim“ lauten soll, dann ist das §$%-nochmal so. Diese Bevormundung empfinde ich als anmaßend und unerträglich!

Ich habe dies bereits mehrfach und in deutlicher Form mit dem Support besprochen. Antwort war jeweils, daß diese Maßregelung aufgrund einer CberSec-Richtlinie erfolgen würde.

Ich habe nachgesehen - ja, in dieser Norm steht tatsächlich etwas dazu. Ob Instar die Vorgaben zu eng auslegt ist wohl Interpretationssache.

Aber dann muß (muß!!) es im Menüsystem irgendwo eine Option geben „Einfache Passwörter zulassen (nicht mehr Norm-konform)“. Macht es wie ihr wollt, aber lasst mich in Frieden mit dem Unfug!

Ich würde es sehr begrüßen, wenn sich auch andere diesbezüglich an den Support wenden, damit dieser Misstand endlich behoben wird.

4

Was ist denn so unpraktikabel, wenn man bei dem Beispiel jetzt “Geheim#” wählt?

5

Geht nicht: Erstens zu kurz, zweitens immer noch keine Ziffern. Drittens entspricht es nicht dem Muster, das mein Passwort-Manager und -Generator normalerweise nutzt und benötigt deshalb extra Handarbeit.

6

Wer wird denn gleich in die Luft gehen …

Etwas arg bevormundet finde ich die PW-Policy auch. Auf die Finger hauen bei unsicherem PW ist okay, aber es wäre schon hilfreich, wenn man die Policy überschreiben könnte. Ala ´Willst Du wirklich?´, ´Ja, will ich´.

Gerade für Migration und gerade bei einem Produkt, wo das PW über CGI-Aufrufe tief in Steuerungen verborgen sein kann. Das ist unnötiger Streß, der vermeidbar wäre durch überschreibbare Policy.

Nachdem ich gezwungen war mein PW zu ändern, in allem http request zu maskieren, hab ich zumindest wieder Snapshots und Streams.

Hartnäckig problematisch ist die Ermittlung der aktuellen Helligkeit. Bisher über ´param.cgi?cmd=getsaradcstate´. Da kommt aber jetzt ein anderes Ergebnis zurück. Bei den Full-HD-Kameras konnte man mit einem simplen regex die Zahl extrahieren, weil nur eine drin war. Jetzt sind es zwei (Responscode 200) und der Regex muß umgeschrieben werden :frowning:

Helligkeit über MQTT gibt es weiterhin nicht?

Arge Herausforderung ist aber MQTT. Die einzige Doku der Topics die ich gefunden habe (https://wiki.instar.com/de/Erweitert/INSTAR_MQTT_Broker/MQTTv5_API/?series_filter=„1440p“) ist m. E. total unübersichtlich. Oder ist die Formatierung kaputt? Hab das mit diversen Browern ausprobiert.

Die Topics scheinen großflächig geändert worden zu sein. Also müssen eine Menge NR-Flows geändert werden. :frowning:

Vom externen MQTT-Brocker lesen klappt:

webcam/webcam1/status/alarm/actions/email/enable

aber an welches Topic muß ich Befehle senden? Früher war das

webcam/webcam1/alarm/actions/email

Da tut sich aber nichts. Ich schaue parallel auf der WebGUI nach Veränderungen.

Und man muß jetzt 0/1 (als String?) statt “off”/”on” senden?

Wenn ich den ganzen Zeitaufwand berücksichtige, hätte ich das vorher gewußt, wäre die 8815 vermutlich im Shop geblieben.

7

Das Beispiel

https://wiki.instar.com/de/Node-RED_Flows/MQTTv5_Alarm_Menu.json

läßt sich nicht in Node-RED importieren. Parse Error.

Die anfänglich gedachte easy Migration auf 8815 stellt sich als tagelange Recherche in der Instar Wiki heraus. Das ist leider No-Go. Da das mit der 4K Innenkamera bei Instar ja extrem lange gedauert hat, hatte ich längst Reolink im Einsatz. Und werde den Weg auch weitergehen.

8

Am besten einmal den MQTT Explorer mit der Kamera verbinden:

Die MQTT API ist nach der Weboberfläche strukturiert. D.h. wenn man in der Oberflächen eine Schaltfläche findet, dann liegt das entsprechende MQTT Topic auch an der entsprechenden Stelle.

aber an welches Topic muß ich Befehle senden?

Im MQTT Explorer sieht man zuerst nur die STATUS Topics. Aus diesen muss dann das status/ entfernt werden, um zum BEFEHL Topic zu kommen:

Und man muß jetzt 0/1 (als String?) statt “off”/”on” senden?

Im MQTT Explorer sieht man direkt den aktuellen Wert. Wenn man den Explorer verbunden lässt und sich durch die WebUI Klickt sieht man die Updates dort auch gleich reinkommen.