CGI-Script ohne Browser zur Kamera schicken

Weiß einer was wirklich an der Kamera ankommt wenn ich einen cgi-Befehl an die Kamera schicke ?

Wenn ich zum Beispiel http://192.168.178.60/param.cgi?cmd=pushhostalarm über Browser verschicke wird das im Wireshark so angezeigt GET /param.cgi?cmd=pushhostalarm HTTP/1.1\r\n

Kommt das dann auch so an der Kamera an oder wird das nochmal umcodiert.

Das würde dann so aussehen

GET%20%2Fparam.cgi%3Fcmd%3Dpushhostalarm%20HTTP%2F1.1%5Cr%5Cn

Der Grund für diese Frage ist das ich diesen Befehl über das TCP/IP-Protokoll einer Siemens-Steuerung an die Kamera senden möchte. Das HTTP-Protokoll ist dort unbekannt und ich möchte das Nachbilden. Leider fehlen mir da weiterreichende Kenntnisse :wink:

Auf der Kamera läuft ein Webserver der beim Aufrufen der URL (beliebiger CGI Befehl) einen dieser URL zugeordnete Funktion ausführt. Damit man da durch kommt muss man die URL in HTTP entweder in der GET oder POST Geschmacksrichtung aufrufen. Ein TCP Ping würde nicht reichen.

Man kann natürlich einen Pi dazwischenstellen. Der müsste irgendwas haben was auf TCP lauscht und kann die Info dann, z.B. über MQTT, zur Kamera senden.

Hallo und Danke für die Antwort.

Ich habe das über das TCP/IP-Protokoll jetzt soweit im Griff das ich eine Aufnahme über einen cgi-Befehl auslösen kann und die Aufnahme wird auf dem FTP-Server abgelegt. Soweit super und perfekt.

Mein Problem war, das nach dem cgi-Sring 2x ein CRLF gesendet werden muss. Warum auch immer.

Jetzt ist es ja so das die Kamera eine Antwort sendet. (set ok oder so ähnlich). Anschließend baut die Kamera die Verbindung ab.
Das kann man sehr schön mit der Software Hercules beobachten.

Jetzt meine Frage : Kann man diesen Verbindungsaufbau irgendwie verzögern ? Mein Problem ist das meine Steuerung die Antwort nicht verarbeiten kann wenn die Serververbindung zu schnell nach dem senden beendet wird. Das Problem ist bekannt und von meiner Seite leider nicht zu lösen.

Mir ist bewusst das dafür vermutlich in die Firmware eingegriffen werden muss. Vielleicht kann da ein Entwickler irgendetwas zu sagen. Da das ganze später sowieso im industriellen Umfeld eingesetzt werden soll wäre es auch kein Problem wenn dabei Kosten entstehen.

Bei den aktuellen Kameras kann ich mir vorstellen dass das komplizierter wird (falls es überhaupt umsetzbar ist). Die in naher Zukunft folgenden neuen Kameraserie hat einen Webserver drauf bei dem man einen keep-alive Parameter setzen kann für Verbindungen. Ob dies das Problem löst und nicht eventuell sogar neue Probleme auf der Kamera auslöst kann ich momentan nicht sagen.

Aber was spricht gegen die Raspberry Pi Lösung? Dort würde man nur ein Gegenstück für die Siemens Steuerung benötigen und könnte das dann an einen Mosquitto Broker anbinden der alles weiter an die Kamera sendet.

Beispielsweise hat der Lighttpd Server eine keep-alive Option mit einem definierbaren Timeout:

https://pimylifeup.com/raspberry-pi-lighttpd/

server.max-keep-alive-requests = 128
server.max-keep-alive-idle = 30
server.max-read-idle = 60
server.max-write-idle = 360

Dann hätte man alles unter kontrolle und kann es individuell anpassen.

Gegen einen Raspberry spricht z.B. das ich dann wieder ein Gerät in der „Mitte“ habe. Genau das will ich ja nicht. So eine Lösung gibt es schon (mit Hilfe eines PCs und eines Pyhton-Skript.

Dann bin ich mir auch nicht sicher ob ein Raspberry in den Industrieunternehmen in der ich meine Lösung einsetzen will überhaupt genehmigt werden. Die ITler sind da manchmal etwas seltsam.

Außerdem kann man dann (fast) jeden Kamerahersteller nehmen :slight_smile: Bisher kenne ich nur INSTAR-Kameras die den Namen über CGI ändern können.

Die neueren Siemenssteuerungen können auch MQTT. Dann wird wahrscheinlich vieles einfacher. Aber ich brauche auch eine Lösung für die Bestandsanlagen.

Mein größtes Problem im Moment ist zur Zeit das meine Kamera der Wahl (IN-9020) nicht lieferbar ist.

Sobald man da dann den gemeinsamen Nenner hat, wirds ein Kinderspiel werden.

Ist nicht so ungewöhnlich. Wir hatten diesbezüglich schon häufiger Anfragen. Aber direkt, ohne einen Übersetzer dazwischen ist natürlich immer besser.

Die Kameras mit dem Chipsatz werden jetzt auslaufen und ersetzt werden. Da wird allerdings im Frühjahr erstmal eine starre Kamera kommen (9008 Nachfolger). Aber wie bereits erwähnt - bei diesem Chipsatz haben wir dann auch mehr Möglichkeiten Anpassungen vorzunehmen.

Vielleicht hat das mit einem Parser zu tun, der beim ersten CR/LF aufhören würde, den String zu extrahieren und erst beim zweiten CR/LF dann das erste mit in den extrahierten String übernimmt.

Ich hoffe, das dabei die CGI-Funktionalität nicht auf der Strecke bleibt …

Du meinst beim neuen Chipsatz? Wir haben hier schon einmal angefangen die neue API zu skizzieren:

Die exakten CGI Befehle darin sind noch ohne Gewähr. Aber die Struktur der Schnittstelle ist schon mal fest. Und es wird immer noch alles per CGI Befehl einstellbar bleiben - sogar noch mehr als bei den 1080p Modellen.

hmmm.

Auf den ersten Blick sehe ich da meinen benötigten Befehl

  • setalarmsnapattr mit dem Parameter snap_name

nicht mehr.

Fehlte tatsächlich noch - in der finalen Version wird es mit drinnen sein.

Das hoffe ich doch sehr. Ich habe meine Anwendung für eine 5907HD jetzt am laufen uns es klappt genau so wie gedacht.
Wäre blöd wenn das mit den neuen Modellen nicht mehr funktionieren würde.

Was war den jetzt das Problem - bzw. die Lösung bzgl. des timeouts der Verbindung?

Was wäre denn, wenn man zu dem eigentlichen CGI-Befehl einfach noch ein paar Info-Abfragen per CGI vornimmt, nur um die Verbindung länger aufrecht zu halten? Die Steuerung müsste die Infos nicht verarbeiten.

Das wird nicht gehen. Wenn ich die Kamera über Hercules ansteuere, sehe ich das direkt nach der Antwort der Kamera die Verbindung geschlossen wird.
Um einen neuen Befehl abzusetzen muss erst wieder die Verbindung neu aufgebaut werden.

Zur Zeit kann ich die Antwort in der Steuerung nicht auswerten. Das ist aber kein Problem da mein Sendebaustein mir ein Bit über das erfolgreiche Senden gibt. Das reicht mir.
Nachdem die Kamera die Verbindung abgebaut hat baut die SPS sie sofort wieder auf. Das passiert innerhalb von einer Sekunde. Und dann ist es auch egal wie lange die Verbindung gehalten wird. Erst mit der nächsten Antwort der Kamera wird sie wieder geschlossen.