Frage: Einbindung zoneminder

[delMar]

Lieber nur die EventID schreiben, und dann später funktionen bereitstellen

Die Funktionen zum Abruf der Streaming URLs machen Sinn. Mir sind die Readings eh auch zu viel.

Dann kann man z.B. zwischen Trigger (Force Alarm) und echter Alamierung unterscheiden.

Ob das mit dem State so detailliert möglich ist, weiß ich nicht, ich reiche da eigentlich nur Informationen weiter.
Wenn du da bessere Infos (Links zur Doku, Forum, etc) hast: sehr gern.

Den Namen könntest du auch mit auslesen, und ggf. beim anlegen der Devices verwenden.

Hatte ich auch schon dran gedacht. Macht also +1
Zumindest als Alias setzen.

Bei den URLs, also bei allen habe ich ein Backslash zu viel: http://192.168.0.12//zm/.

Fällt unter 'aufräumen'. Kommt noch, funktioniert in der Zwischenzeit trotzdem (bei mir zumindest  )

Function oder Enable oder Alarm wird normalerweise immer klein geschrieben.

Ich wollte damit zeigen, dass es sich um die ZoneMinder-internen Bezeichnungen handelt (um nicht zB mit dem gängigen 'enabled' in FHEM verwechselt zu werden)
Es ist aber sicher besser, sie klein zu schreiben und statt 'enabled' (die Wurzel des ganzen) eine bessere Bezeichnung zu wählen.

In der Dokumentation sollten...

Ja, die liebe Doku.

Und ich weiß nicht, ob ich da jetzt zu pingelig bin

Keine Sorge, ich kann da ganz gut filtern.
Was ich für sinnvoll halte, setze ich gern um.

Wie lange planst du noch in der Beta Phase zu bleiben, bevor das Module im SVN landet? Ein Update Kontrollfile wäre nicht schlecht, wenn es noch länger im Git verbleibt.

Wie in einem vorigen Post schon geschrieben, hab ich den SVN Zugriff schon. Ich plane, am Wochenende *alles* umzusetzen, was noch offen ist 

Übrigens: Zwecks Streaming-URL, du kannst als Workaround den Teil, der aus ZM_PATH_ZMS kommen sollte auch an die pubStreamUrl dranhängen. Ist dann zwar redundanz zum Wert aus der ZM-config, aber zumindest solltest du eine gültige Streaming-URL kriegen.

schöne Grüße
Martin

[Florian_GT]

1)
Der Stream wird bei mir jetzt sauber angezeigt, warum Plötzlich müssten wir uns nochmal genauer anschauen. Manche URLs sind erst seit einem Alarm gesetzt, wenn ich das richtig sehe. Ich nutze statt dem Stream iFrames:

Code Auswählen Erweitern

# 18 - Arbeitszimmer
define SecurityCAM_arbeitszimmer weblink iframe http://192.168.0.12/zm/cgi-bin/nph-zms?mode=jpeg&scale=100&maxfps=30&buffer=1000&monitor=18&user=fhem&pass=fhem
attr SecurityCAM_arbeitszimmer htmlattr width="660" height="500"
attr SecurityCAM_arbeitszimmer room SecurityCAM

Bei deinem Stream wird jede Sekunde ein Request an den ZM Webserver geschickt, bei dem iFrame nicht.

2)
Mehr Daten oder funktionen bekommt man laut https://github.com/ZoneMinder/ZoneMinder/blob/master/scripts/zmtrigger.pl.in wohl leider nicht raus. Schade, zumal deutlich mehr verfügbar wäre. Jetzt bin ich in zwei gesplalten, mache ich mein MQTT Client weiter oder schreibe ich gar am zmtrigger herum... hmm...

[delMar]

wird der NPH_ZMS Teil jetzt richtig aus ZM ausgelesen, oder hast du's bei pubStreamUrl angehängt?

Mehr Daten oder funktionen bekommt man laut https://github.com/ZoneMinder/ZoneMinder/blob/master/scripts/zmtrigger.pl.in wohl leider nicht raus. Schade, zumal deutlich mehr verfügbar wäre. Jetzt bin ich in zwei gesplalten, mache ich mein MQTT Client weiter oder schreibe ich gar am zmtrigger herum... hmm...

ich glaube, das eigentlich richtige interface wäre SharedMem. (hab irgendwo gelesen, dass das einer API, die alles kann am nähesten kommt).
Aber dafür müsste ich mich in perl besser auskennen. keine ahnung, wie man das machen müsste, damit man die libs hat, ohne ZM auf der selben maschine installiert zu haben...

[Florian_GT]

wird der NPH_ZMS Teil jetzt richtig aus ZM ausgelesen, oder hast du's bei pubStreamUrl angehängt?
ich glaube, das eigentlich richtige interface wäre SharedMem. (hab irgendwo gelesen, dass das einer API, die alles kann am nähesten kommt).
Aber dafür müsste ich mich in perl besser auskennen. keine ahnung, wie man das machen müsste, damit man die libs hat, ohne ZM auf der selben maschine installiert zu haben...

pubStreamUrl habe ich nicht gesetzt. Warum es jetzt plötzlich passt, kann ich mir nur so erklären, dass irgendwo erst Daten gesetzt werden, wenn ein Event o.ä. erfolgt ist. Muss ich mir nochmal inruhe anschauen.

SharedMem ist die Schnittstelle zu Zoneminder. Der zmTrigger bzw. mein MQTT Client ist dann somit eine Zwischenstelle um FHEM mit ZM zu verbinden. Beide arbeiten sehr ähnlich, und das geht nur auf der Maschine, auf der auch ZM läuft. Da die lib direkt auf den Speicher zugreift. Das hat den Vorteil, dass es sehr viel last vom System nimmt.

Der zmTrigger wurde seit einiger Zeit nicht mehr weiterentwickelt, ich tendiere aktuell dahin, dass ich den MQTT weiterentwickeln könnte, Steuerung ermöglichen und Timing Problem lösen. Dann hätte der mehr Features und würde auf moderner Technik basieren. Ich glaube, die Webschnittstelle ist dann sogar nur noch für den Zugriff auf die Streams notwendig.

Für dein Module würde sich in sofern nur ändern, dass statt auf Info vom zm Device warten, auf Info vom MQTT warten,

Was hälst du davon?

[delMar]

Der zmTrigger wurde seit einiger Zeit nicht mehr weiterentwickelt, ich tendiere aktuell dahin, dass ich den MQTT weiterentwickeln könnte, Steuerung ermöglichen und Timing Problem lösen. Dann hätte der mehr Features und würde auf moderner Technik basieren. Ich glaube, die Webschnittstelle ist dann sogar nur noch für den Zugriff auf die Streams notwendig.

Für dein Module würde sich in sofern nur ändern, dass statt auf Info vom zm Device warten, auf Info vom MQTT warten,

Was hälst du davon?

Da das Modul ja aus einem physischen Teil (70_ZoneMinder) und einem logischen Teil besteht (71_ZM_Monitor), sehe ich kein Problem darin, wenn du zB ein physisches ZoneMinder_MQTT Modul schreibst, und ebenfalls das ZM_Monitor Modul nutzt.

Grundsätzlich müsste man aus dem jetzigen ZoneMinder Modul schon zwei machen, weil die Connection auf TCP 6802 und die HTTP-API eigentlich schon zwei verschiedene physische Connections sind. Find ich aber übertrieben, weil für mich schon im Vordergrund steht, das so einfach und schmerzlos wie möglich installieren zu können.

Man könnte nun argumentieren, doch auch MQTT hier mit rein zu nehmen. Allerdings verwende ich selber MQTT nicht und es ist auch eine Komponente außerhalb von FHEM, die man aufsetzen muss. Deshalb bleib ich bei meinem Eingang erwähnten Vorschlag, einfach ein ZoneMinder_MQTT Modul zu bauen, das ZM_Monitor mit verwendet.
Dafür muss ich übers Wochenende noch etwas aufräumen, damit hier die Gewaltentrennung stimmt

[rudolfkoenig]

Allerdings verwende ich selber MQTT nicht und es ist auch eine Komponente außerhalb von FHEM, die man aufsetzen muss.

Nicht zwingend, siehe https://forum.fhem.de/index.php/topic,90135.0.html

[delMar]

Nicht zwingend, siehe https://forum.fhem.de/index.php/topic,90135.0.html

Cool, danke für die Info.
Da werfe ich definitiv einen Blick drauf, das kommende Wochenende is aber schon verplant

[delMar]

Bei deinem Stream wird jede Sekunde ein Request an den ZM Webserver geschickt, bei dem iFrame nicht.

Sorry, das konnte ich jetzt nicht reproduzieren. Chrome und FF machen einen Request und streamen dann.
Edge zeigt sowieso nur ein Bild anstatt eines Streams (nein, das überrascht uns nicht. aber können ja so tun, als ob)
Ist aber egal, da ich das sowieso rausgebe. Dann hast du den Stream nicht mehr in der Detailansicht.

Mehr Daten oder funktionen bekommt man laut https://github.com/ZoneMinder/ZoneMinder/blob/master/scripts/zmtrigger.pl.in wohl leider nicht raus. Schade, zumal deutlich mehr verfügbar wäre. Jetzt bin ich in zwei gesplalten, mache ich mein MQTT Client weiter oder schreibe ich gar am zmtrigger herum... hmm...

Was würde dein MQTT-client anders machen, um an mehr Daten zu kommen? (ohne etwas an ZMTrigger zu ändern)
ZMTrigger erweitern und dann nach ZoneMinder einen Pull-Request machen wäre mMn die beste Lösung. Manuelle Änderungen werden ja mit jedem ZM-Update wieder überschrieben.
Und eins hab ich nach 10 Jahren nicht-sehr-smarter Bastlerei am SmartHome gelernt: koch nie dein eigenes Süppchen, sonst ersäufst du darin.

Lieber nur die EventID schreiben, und dann später funktionen bereitstellen

Tja, hier bin ich nun am Überlegen.
Eins ist sicher: wenn ich die Streaming-URL haben will, will ich sie mir nicht aus zig verschiedenen Readings oder Internals oder was auch immer zusammenbauen müssen. Ich will einen Ansatzpunkt haben: derzeit die Readings.
Man könnte die Readings nur für die einzelnen Details nehmen (event-id, authHash, ...) und die ganze URL zB per 'get liveStreamUrl' ausliefern.
Allerdings weiß ich jetzt nicht, ob das nicht - trotz technischer machbarkeit - dem grundsätzlichen Konzept der 'get' Funktionalität widerspricht?
Es wäre ja dazu gedacht, Werte von ZoneMinder zu holen. Nicht dazu, Kalkulationen durchzuführen, oder?

Manche URLs sind erst seit einem Alarm gesetzt, wenn ich das richtig sehe

Du hast recht, bisher werden eventIds und eventtimestamp, etc nur geschrieben, wenn ein event reinkommt. dh wenn fhem neu gestartet wird, sind diese Readings erstmal leer. Die Readings könnte man initial natürlich auch aus der fhem-api befüllen, bzw auch manuell ein 'get lastEventData' implementieren (hier würde es passen).
Grunsätzlich find ich das Setzen auf Basis von Events richtig, weil ich dann nicht regelmäßig die ZM-API pollen muss.

[delMar]

Das Setzen von Modes funktioniert jetzt, ich hatte das Verbose Logging nur im Device, nicht in der für den Zoneminder Server gesetzt. Danach konnte ich sehen, dass der User fhem nicht genug Rechte hat und das korrigieren. Jetzt hat der Fhem User genau so viele Rechte, wie der admin User, ob das so super ist, ich weiß ja nicht...

Mich würde die konkrete Meldung interessieren, die du hier gesehen hast.
Ich hab jetzt einen API user angelegt, der nur für "Stream" und "Monitors" das Recht "View" hat.
Alles andere steht auf "None".
Und alles, was das Modul machen kann, macht es auch: Monitor devices anlegen und Streams darstellen. (Event Triggers laufen ja ohnehin nicht über die Web API)

Wenn du hier mehr Infos für mich hättest, wie ich das Reproduzieren kann, wäre ich dir sehr verbunden.

schöne Grüße
Martin

[Florian_GT]

Hi,

der MQTT Client lief direkt auf der ZM Maschine, als gesonderte Prozess, welcher mittels systemd gestartet wird. Die Datei ist gesondert, also keine ZM Dateien werden überschrieben, so habe ich keine Probleme mit dem Update.
Ich denke ich werde aber einfach eine verbesserte Version der zmtrigger entwickeln. Zu dem vorhandenen Ausgabeformat "bastel" ich ein zusätzliches hinzu. So gibt es keine Kompatiblilitätsprobleme und nach belieben kann das neue Datenmodell genutzt werden.
Wenn ich das fertig habe, würde ich dir dazu eine Info geben. Dauert aber auch genau wie bei dir jetzt etwas länger...

Ich habe das MQTT noch hier liegen, vielleicht wenn von seiten ZM dort Interesse ist, kann man das ja später auch noch einbauen. Würde ich aber eher davon abhängig machen, wie stabil der TCP Server läuft.

Ich habe die Details Seite nochmal aufgerufen, jetzt hatte ich keine Aufrufe im Sekundentackt mehr gesehen. Nach deiner ganz neuen Version jetzt, erscheint auch kein Bild mehr.

Zum Thema Änderungen werden beim Update überschrieben, kann ich dir Automation mit Chef oder Ansible empfehlen. Ich bau damit inzwischen fast meine gesamte EDV Umgebung auf, echt ein Traum!

Zum Thema Reading (Streaming-URL) könnte ich mir auch vorstellen, dass du in der Beispielkonfig einfach die passenden Parameter mit schreibst, um halt
entsprechende überflüssige Vars aus dem Log rauszuhalten.

Die Daten die später gefüllt worden waren, hatte nichts mit den Events zu tun. Das waren aus meiner Sicht Config bzw. StreamURL dinge. Aber bin mir da nicht mehr sicher, da ich es jetzt nicht mehr nachbilden konnte. Also einfach ignorieren. Alles gut so.

Bei dem Rechteproblem hatte ich probleme die Function über FHEM zu setzen. Dazu können wir am besten nochmal gesondert, wenn du Zeit hast, testen...

Mir ist aber noch ein Problem aufgefallen, wenn kein Event da ist, und sozusagen das erste Event erzeugt wird, passiert nix. Erst bei dem zweiten Event wird FHEM tätig.
Kann an dem zmtrigger liegen, oder FHEM, müssten wa auch mal gesondert schauen, wenn mehr Zeit ist.

Thema Autodiscovery: Kann man das auch ausschalten? Ich habe so ein paar Öffentliche Kameras da drin, die schalte ich machmal als Showeffekt ein, haben aber nix in FHEM zu suchen...

Thema IPCAM: Kannst du mal schauen ob es möglich ist, eine get camerapicture oder so ähnlich zu bauen? Damit kann mann ohne zusätzliches IPCAM Device dann ein Bild von der Kamera laden, das wird lokal gespeichert, damit mann es dann wiederum z.B. per Telegram geschickt bekommt.

Code Auswählen Erweitern

define zoneminder_ipcam_18 IPCAM 192.168.0.12
attr zoneminder_ipcam_18 snapshots 1
attr zoneminder_ipcam_18 path /zm/cgi-bin/nph-zms?mode=single&monitor=18&user=fhem&pass=fhem
#http://192.168.0.12/zm/cgi-bin/nph-zms?mode=jpeg&scale=100&maxfps=30&buffer=1000&monitor=18
attr zoneminder_ipcam_18 storage /opt/fhem/data/IPCAM
attr zoneminder_ipcam_18 room SecurityCAM

Ansonsten bis jetzt echt Klasse Arbeit!

PS: Sorry, aber ich hasse diese Zitierenfunktion. Also nicht das Zitieren an sich, aber den grausamen Editor im Forum.

[delMar]

Ich beschränke mich aufs nötigste bei der Antwort

Ich habe die Details Seite nochmal aufgerufen, jetzt hatte ich keine Aufrufe im Sekundentackt mehr gesehen. Nach deiner ganz neuen Version jetzt, erscheint auch kein Bild mehr.

Genau, muss man jetzt per Attribut einschalten.

Zum Thema Reading (Streaming-URL) könnte ich mir auch vorstellen, dass du in der Beispielkonfig einfach die passenden Parameter mit schreibst, um halt
entsprechende überflüssige Vars aus dem Log rauszuhalten.

Mit Log meinst du das Event-Log? Oder das Log-file?
Weil, wenn du keine Events willst, musst du ja nur event-on-change-reading setzen.

Bei dem Rechteproblem hatte ich probleme die Function über FHEM zu setzen. Dazu können wir am besten nochmal gesondert, wenn du Zeit hast, testen...

Du hast recht, da gibts ein Problem. Leider keines, das ich lösen könnte.
Die ZM-API verhält sich hier unterschiedlich zur ZM-UI (wo es sehr wohl mit Monitor-Edit Rechten funktioniert).
Man muss leider System-Edit Rechte haben
Quelle: https://forums.zoneminder.com/viewtopic.php?f=36&t=27102

Mir ist aber noch ein Problem aufgefallen, wenn kein Event da ist, und sozusagen das erste Event erzeugt wird, passiert nix. Erst bei dem zweiten Event wird FHEM tätig.
Kann an dem zmtrigger liegen, oder FHEM, müssten wa auch mal gesondert schauen, wenn mehr Zeit ist.

Stimmt, da läuft irgendwas noch nicht so rund. Liegt sicher nicht an ZM, das weiß ja garnix von fhem.
Ich glaube, da verschluckt das Modul noch irgendwo etwas...

Thema Autodiscovery: Kann man das auch ausschalten? Ich habe so ein paar Öffentliche Kameras da drin, die schalte ich machmal als Showeffekt ein, haben aber nix in FHEM zu suchen...

Ja, ich werde per default kein Auto-Create mehr triggern.
Ist es wirklich ein Problem, wenn die Kamera in fhem gelistet ist, obwohl du sie nicht benötigst?
Meine erste Idee wäre, dass die Kamera zwar in fhem sichtbar ist, du dort aber setInactive machen kannst und die Kamera kriegt keine Events mehr, etc.
Und auch bei einem erneuten updateMonitors würde ich sie dann einfach ignorieren.
Und rein zwecks Sichtbarkeit gäbe es auch noch den 'hidden' room.

Thema IPCAM: Kannst du mal schauen ob es möglich ist, eine get camerapicture oder so ähnlich zu bauen? Damit kann mann ohne zusätzliches IPCAM Device dann ein Bild von der Kamera laden, das wird lokal gespeichert, damit mann es dann wiederum z.B. per Telegram geschickt bekommt.

Die Frage kam auch von @Braakhekke schon
Ein Grund, warum ich fhem so Klasse finde, ist, dass es Modular ist.
Ich verwende selber auf meinen ZM-Devices ebenfalls das IPCam Modul.
Wenn jemand an der Haustür klingelt, schießt IPcam ein Foto und Pushover schickts mir aufs Handy.
Meine Antwort von damals hier https://forum.fhem.de/index.php/topic,34570.msg837043.html#msg837043

Ansonsten bis jetzt echt Klasse Arbeit!

Danke.
Wenn ich dran denke, was ich ursprünglich einbauen wollte (Events von ZM nach FHEM), und was jetzt schon alles drin ist...
Liegt wohl daran, dass so viel gutes Feedback gekommen ist

[Florian_GT]

Logging in die Datenbank, also ja, mit event-on-change-reading.

Es wäre cool, könnte man auf die IPCAM Konfiguration verzichten. Du kannst ja aus dem ZM Module heraus darauf zugreifen.

Den Bug in ZM hatte ich in meinem MQTT Client schon gefixt, werde ich dann in zmtrigger nachziehen...

Ich habe einen Bug gefunden: Wenn ich im zm Device auf updateMonitors klicke kommt ein

Code Auswählen Erweitern

Undefined subroutine &main::ZoneMinder_API_ReadMonitors called at ./FHEM/70_ZoneMinder.pm line 516.
und Fhem crashed, restarted.

Außerdem hatte ich vorhin wieder eine unauthorized Meldung, als ich die Monitor function ändern wollte. Nach dem crash ging es aber wieder:

Code Auswählen Erweitern

018.09.29 15:09:08.572 4: method: changeMonitorFunction, monitorId:21, Function:Monitor
2018.09.29 15:09:09.359 1: PERL WARNING: Use of uninitialized value $enabled in concatenation (.) or string at ./FHEM/70_ZoneMinder.pm line 398.
2018.09.29 15:09:09.359 4: ZM_Monitor (zm) - ChangeMonitorState callback data: {"message":"Saved"}, enabled:


[delMar]

der aktuelle Stand auf GitHub ist nicht stabil, sorry.
werde in zukunft einen branch machen, aber bisher war niemand so schnell wie du
ich schreib hier rein wenns wieder ein stabiles update gibt

[Florian_GT]

der aktuelle Stand auf GitHub ist nicht stabil, sorry.
werde in zukunft einen branch machen, aber bisher war niemand so schnell wie du
ich schreib hier rein wenns wieder ein stabiles update gibt

Habe deine neue Version eingebunden:

Code Auswählen Erweitern

2018.09.30 21:08:53.146 1: PERL WARNING: Use of uninitialized value $enabled in concatenation (.) or string at ./FHEM/70_ZoneMinder.pm line 453.


Code Auswählen Erweitern

2018.09.30 21:09:21.140 2: ROOMMATE set rr_Florian home
2018.09.30 21:09:25.563 2: ZoneMinder (zm) - ChangeMonitorState callback err: read from http://192.168.0.12:80 timed out
2018.09.30 21:09:25.564 2: ZoneMinder (zm) - ChangeMonitorState callback err: read from http://192.168.0.12:80 timed out
2018.09.30 21:09:25.564 2: ZoneMinder (zm) - ChangeMonitorState callback err: read from http://192.168.0.12:80 timed out
2018.09.30 21:09:25.564 2: ZoneMinder (zm) - ChangeMonitorState callback err: read from http://192.168.0.12:80 timed out
2018.09.30 21:09:25.564 2: ZoneMinder (zm) - ChangeMonitorState callback err: read from http://192.168.0.12:80 timed out


[delMar]

So, neue Version auf GitHub. Sollte wieder stabil sein.

Änderungen:

• Der letzte Parameter beim Define (zm console url) fällt weg.
• Stattdessen gibt es jetzt das Attribut publicDomain, welches auch zum Erstellen der Console-URL verwendet wird. Dort kann man zB https://meine.domain.xy:11234 reinschreiben, und das Modul hängt automatisch /zm dran
• Monitore werden nicht mehr automatisch angelegt. Dafür gibts jetzt get autocreateMonitors
• davon unabhängig gibt es get UpdateMonitorConfig, welches die Config aus ZM holt
• Load vom ZoneMinder Server wird jetzt in den ZoneMinder device Readings richtig angezeigt
• set Befehle sind jetzt klein geschrieben
• Generell wurde die ganze Code-Struktur überarbeitet

Bekanntes Problem ist, dass nach dem Löschen eines ZM_Monitor devices diverse Fehlermeldungen auftauchen können, dass dieses nicht gefunden wurde.
Das muss ich erst prüfen, wo ich da noch nacharbeiten muss.
Nach einem Neustart von fhem sind diese Meldungen nämlich weg.
Wer Warnings im Log findet, darf sie behalten
Die ignoriere ich so lange, bis wir im SVN sind.

Ich würde die neue Version als grob Inkompatibel mit der vorigen bezeichnen.
Bitte alle ZoneMinder und ZM_Monitor devices löschen, bevor die neue Version ausprobiert wird.

Commandref ist leider immer noch nicht fertig.
Das Wiki muss ich auch noch auf den neuesten Stand bringen.
Deshalb noch kein SVN commit.
Wird sich wohl noch einige Tage hinziehen.

schöne Grüße
Martin