Notify "get Image" macht bei IPCAM Probleme

[Alcamar]

Neben meinen bisherigen INSTARs will ich nun auch AXIS als Überwachungskameras einsetzen. Ich nutze IPCAM.
Auch wenn die INSTAR-Kameras nicht ausdrücklich unterstützt werden, funktionieren sie bisher ohne Probleme.

Funktionsweise:

• Ein Bewegungsmelder löst mittels notify den Befehl "get CameraXX image" aus
• danach werden die erzeugen Bilder per Email versendet

Was bei INSTAR bisher geht, will bei der AXIS nicht funktionieren. Probleme gibt es an einer Stelle, die ich überhaupt nicht nachvollziehen kann und zwar beim notify n_Snapshot_Erstellen, der die Bilder generieren soll:

Code Auswählen Erweitern

Bewegungsmelder_4:motion {get Cam03 image}

bringt den Fehler im Log:

Code Auswählen Erweitern

n_Snapshot_Erstellen return value: Unknown command Bewegungsmelder_4:motion, try help.

Dabei habe ich auch diese Varianten ausprobiert:

Code Auswählen Erweitern

Bewegungsmelder_4:motion {fhem("get Cam03 image")}

Code Auswählen Erweitern

Bewegungsmelder_4:motion {erstelleBild ("Cam03")}
mit einer eigenen Routine:

Code Auswählen Erweitern

sub
erstelleBild($)
{
my ($myCam) = @_;
fhem "get $myCam image";
}

Eigenartig finde ich, dass wenn ich die eigene Routine erstelleBild("Cam03") aufrufe, alles funktioniert. Die Bilder werden erstellt und versendet. Auch im fhem-FrontEnd kann ich ein "get Image" auslösen und bekomme prompt die Bilder als Email-Attachment. Nur der notify will bei Axis nicht die Routine aufrufen bzw. den Befehl ausführen. Bei INSTAR macht der notify keine Probleme.

Hast jemand eine Idee?

[Alcamar]

Verwendet ich statt des notify ein DOIF gibt es keine Probleme.
Trotzdem bleibt für mich das Verhalten von notify ein Rätsel.
Ist DOIF das bessere notify?

[Alcamar]

eines ist noch unschön:

Mein DOIF ist wie folgt definiert:

Code Auswählen Erweitern

([bewegungsmelder_4:?motion]) ( {erstelleBild("Cam03")} )

Wird der Bewegungsmelder ausgelöst, bekomme ich Bilder. Aber leider auch vier Minuten später erneut.
In R-minInterval ist 240 eingetragen, was vermutlich mit dem Verhalten etwas zu tun hat.

Aber wieso löst DOIF eine zweites Mal aus?

Es gibt sehr viele Bespiele für DOIF in der Referenz, aber ich konnte daraus nichts für mich ableiten.
Irgendwo konnte ich lesen, dass :?motion veraltet ist und nicht mehr verwendet werden sollte.
Weiss jemand Rat?

[Sirel]

Hallo Alcamar,
mit [...:?motion] fragst Du Events ab, welche von dem Device kommen und das Wort "Motion" beinhalten. Könnte mir vorstellen, dass der Bewegungsmelder einmal "Motion on" und einmal "motion off" versendet. Daraufhin löst das DOIF 2x aus.

Frag doch lieber den Status direkt ab:

Code Auswählen Erweitern

([bewegungsmelder _4:motion] eq "on") (get Cam03 image) DOELSE

Danach wir nur noch im "On-Fall" ein Bild von der Kamera geholt.

Viele Grüße,
Max

[Alcamar]

Ich hatte auch gelesene, das es besser wäre das Event abzugreifen und nicht den Status zu prüfen. Die ?-Variante ist auch schön kurz und übersichtlich. 
Wenn ich keine elegantere Lösung habe, werde ich wohl über die Status-Abfrage gehen.

[Sirel]

Hi Alcamar,
ich frage i.d.R. den Status der Devices ab. Es gibt aber Situationen, wo es besser/notwendig ist, das Event abzugreifen.

Dem Modul ist es aber egal

Viele Grüße,
Max

[Alcamar]

Deine Lösung hatte ich zwischenzeitlich mal. Die löste nur einmal aus. danach nicht wieder.
Dann habe ich das attr "always" entdeckt.  Aber irgendwie fanch dich das 'Fragezeichen' besser. Muss heute Abend schauen, ob ich auch Deine Variante wieder hinbekomme.

[Brockmann]

Wird der Bewegungsmelder ausgelöst, bekomme ich Bilder. Aber leider auch vier Minuten später erneut.
In R-minInterval ist 240 eingetragen, was vermutlich mit dem Verhalten etwas zu tun hat.

Aber wieso löst DOIF eine zweites Mal aus?

Code Auswählen Erweitern

define di_lamp DOIF ([BM:state:sec] < 5) (set lamp on-for-timer 300)
attr di_lamp do always

Bei HM-Bewegungsmelder werden periodisch Readings aktualisiert, dadurch wird das Modul getrigger, auch wenn keine Bewegung stattgefunden hat. Der Status bleibt dabei auf "motion". Mit der obigen Abfrage lässt sich feststellen, ob der Status aufgrund einer Bewegung tatsächlich upgedatet wurde.

[Alcamar]

([BM:state:sec] < 5)
habe ich leider nicht ganz kapiert. Heißt es, dass 5 Sekunden auch Stillstand ist, bis getriggert wird?


Wegen der Register, die sich updaten, hatte ich auch mal ein
Event-On-Change-Reading benutzt. Beim BM würde es genügen, wenn er triggert, wenn sich Count um eins erhöht. Den anderen Traffic des BMs brauch ich gar nicht. Mein Idee war also, dass nur ein Event generiert wird, wenn sich ein bestimmtes Reading ändert. Das ging aber auch nicht. 

[Brockmann]

([BM:state:sec] < 5)
habe ich leider nicht ganz kapiert. Heißt es, dass 5 Sekunden auch Stillstand ist, bis getriggert wird?

Die Homematic-BM haben permanent den State motion, selbst wenn keine Bewegung erkannt wurde. Ob eine Bewegung erkannt wurde, kann man daran feststellen, dass das State-Reading aktualisiert wurde. Der obige Trigger löst also immer aus, wenn das State-Reading innerhalb der letzte 5 Sekunden aktualisiert wurde, sprich tatsächlich eine Bewegung erkannt worden ist. Das DOIF aus dem Beispiel wird also jedes Mal getriggert, wenn eine Bewegung erkannt wurde (und nur dann). Was ja das ist, wann Du möchtest, oder?

[Alcamar]

ja, aber Deine erste Annhame kann ich nicht bestätigen.
Bei Bewegung bekommt der BM den Status "motion". Nach 240 Sekunden ändert sich der Status auf "noMotion". Dann würde es wieder 2x auslösen, oder? Das entspricht für mein Empfinden dem was Sirel geschrieben hat.

Ich habe das eben mit
trigger BM motion ausprobieren wollen. Ging nicht. Muss heute Abend mal am BM vorbeilaufen.

[Sirel]

Hi Alcamar,
wenn der Status von von Deinem Device zwischen "Motion" und "noMotion" wechselt, dann kannst du es so machen, wie ich es beschrieben habe. Wichtig ist, dass Du das DOELSE setzt, denn sonst kann das Modul den Status nicht wechseln. Dann passiert genau 1x Mal etwas, danach nicht mehr.

Code Auswählen Erweitern

define deindoif DOIF ([bewegungsmelder _4:motion] eq "on") (get Cam03 image) DOELSE

Probiere es einmal aus und berichte danach...

Viele Grüße,
Max

[Alcamar]

Ich habe es gelöst.

• event-on-change-reading auf trigger_cnt des Bewegunsmelders
• es DOIF prüft nur noch dieses Event mit  [Bewegunsmelder_4:?trigger_cnt]
• es DOIF hat always als attr

Der BM erhöht bei jeder Bewegung den Counter. Auf diesen wird getriggert. Damit reduziert man wohl auch Last, die gerade Bewegungsmelder generieren. Ich meine, dass Martin mir mal den Tipp gegeben hat. Nur damals habe ich es nicht ganz verstanden, mir aber trotzdem gemerkt. 

[Alcamar]

@Sirel Sorry, das Forum war down (relativ oft in letzter Zeit) und ich habe Dich zu spät gelesen. Deinen Vorschlag probiere ich trotzdem aus, auch wenn ich denke, dass die Reduktion der Events einige Vorteile hat.

Es sollte doch genügen, wenn ich event-on-change-reading mit Komma getrennt um motion erweitere. Weiss nicht, ob ich das heute noch schaffe.

[Sirel]

Hi Alcamar,

kannst sonst auch noch hier mal schauen:
http://fhem.de/commandref_DE.html#DOIF_checkReadingEvent

Dann hast nachher nicht das Problem, dass wenn du ein anderes Reading Deines BM abfragen möchtest, nichts passiert. Das Device triggert jetzt ja nur noch auf/bei dem Reading, welches Du definiert hast. Klar kannst das weitere Reading dann noch hinzufügen, nur dann wird dein DOIF auch wieder getriggert. 

Cheers,
Max