Mehrere Requests mit einem HTTPMOD?

[Jahoo]

Hallo zusammen,

bevor ich meinen jämmerlichen Versuch erläutere, will ich erst mal kurz darlegen, was ich eigentlich erreichen möchte:
Ich habe eine INSTAR Kamera, welches auch ein potentialfreies Relay hat. Dieses lässt sich über http GET Requests schalten.
Beispiel:

Code Auswählen Erweitern

http://192.168.10.100/param.cgi?cmd=relayctrl&-act=on&usr=admin&pwd=password

Dieses nutze ich um mein Garagentor zu schalten. Jedoch unterstütz die Kamera kein ,,on-for-timer", so dass ich erst das Relay schließe und 1 Sekunde später wieder öffnen muss.

Was habe ich bisher gemacht:

Code Auswählen Erweitern

defmod relayTest HTTPMOD none 0
attr relayTest userattr get1Name get1URL get2Name get2URL
attr relayTest get1Name closeRelay
attr relayTest get1URL http://192.168.10.100/param.cgi?cmd=relayctrl&-act=on&usr=admin&pwd=test
attr relayTest get2Name openRelay
attr relayTest get2URL http://192.168.10.100/param.cgi?cmd=relayctrl&-act=off&usr=admin&pwd=test


Damit kann ich zumindest manuell über ,,get relayTest closeRelay" bzw. openRelay das Tor schalten.

Der einfachste Weg wäre jetzt ein Script anzulegen, der diese Funktion ausführt. Dann hätte ich quasi 2 Devices: 1x den Script, welches die 3 Befehle (close, sleep, open) ausführt und dann das HTTPMOD Device, welches die Befehle bereitstellt.

Nun kam mir die Frage, ob ich das nicht auch eleganter lösen kann:
Kann ich nicht über ein eigenes Attribut bzw. einen Command z.B. impuls die Befehlszeile direkt ausführen, ohne hierfür ein eigenen Device zu benötigen?
So dass ich set relayTest impuls aufrufen kann, und im Hintergrund die beiden get Befehle verschickt werden – ohne weitere Rückmeldung. Ähnlich wie das Schalten eines Tasters?
Ich versuche quasi einen on-for-timer 1 nachzubauen - in einem vorhandenen HTTPMOD Device

Ich bin für jede Hilfe dankbar.

[Frank_Huber]

Warum kein doif / notify / whatever?
Einfach Befehl, Pause, befehl2
Dafür gibt's die httputils.

[Beta-User]

O. readingsProxy? Der kann auch on-for-timer...

[MadMax-FHEM]

EDIT: sorry!! Nicht wirklich genau (genug) gelesen... So ein "on-for-timer", hmmm, das könnte mit dem Modul schwierig/unmöglich werden...


Warum nimmst du nicht das IPCAM-Modul!?

Soweit ich mich erinnere ist INSTAR dort brauchbar "integriert" bzw. gibt es Threads und Wiki wo so einiges zu finden ist/sein sollte...
...dort kannst du auch "eigene" Kommandos hinterlegen...

https://wiki.fhem.de/wiki/IPCAM

https://wiki.fhem.de/wiki/IPCAM#Parameter_f.C3.BCr_INSTAR_Full_HD

Ansonsten habe ich auch einen Thread im Kopf, wo (unterstützt von INSTAR) eine MQTT-Anbindung "erarbeitet" wird...

Gruß, Joachim

[amenomade]

Code Auswählen Erweitern

define alias1 cmdalias impuls AS get relayTest closeRelay;;sleep 60;;get relayTest openRelay

Aufruf einfach mit:

Code Auswählen Erweitern

impuls

Oder mit variabler Zeit:

Code Auswählen Erweitern

define alias1 cmdalias impuls .* AS get relayTest closeRelay;;sleep $EVENT;;get relayTest openRelay

Aufruf mit:

Code Auswählen Erweitern

impuls 10


HTTPMOD kann das selbst nicht.

[Jahoo]

Vielen Dank für die Antworten.

Ich glaube ich suche einfach eine Funktion, die FHEM so nicht bietet, oder ich habe einfach das Konzept von FHEM nicht ganz verstanden 

Ich habe in meinem Haus mehrere Geräte (15 Rollläden, 10 Schalter/Taster, usw). Da wird FHEM sehr schnell sehr unordentlich, trotz der sauberen Arbeit mit Räumen usw.
Insbesondere, wenn man dann noch per defmod und at Aktionen zu bestimmten Bedingungen ausführt (z.B. Rollladen runterfahren, usw).

Daher habe ich immer ein gewisses Bedürfnis die Geräte zu reduzieren, damit mir die Räume nicht überquillen und es irgendwie noch halbwegs sauber bleibt.

So kam der Wunsch auf, "Garage" als Gerät zu definieren, und open/close Relay als Funktion und zusätzlich ein on-for-timer sozusagen.

Bei meinem Schiebetor habe ich einen homematic schalter: Da kann ich einfach ein "impuls" schicken, welches ein on-for-timer ist und fertig.
Das macht es eben sehr einfach und ordentlich.

Ich habe jetzt einen Script gemacht, den ich dann halt immer ausführen muss. Schön geht anders - aber gut. Man wird sich daran gewöhnen müssen.

Ich hatte eben gehofft, dass man irgendwie seine eigene Set Methode implementieren kann, die dann wiederum eine Befehlskette aufruft.


@amenomade: vielen Dank. Funktioniert, jedoch habe ich dann in FHEM einerseits mein Device (HTTMOD) und andererseits den Alias.
Gewünscht hätte ich mir einfach ein Device (z.B. Garage) zu haben, die dann eine Methode anbietet "impuls", wie oben beschrieben.
PS: Der Schlaf vor Mitternacht ist der erholsamste 


@MadMax-FHEM: Danke - das hatte ich auch am laufen. Aber da war kein on-for-timer. Außerdem bietet es viel zu viel Funktionen von der Kamera.
Mehr als ich in FHEM nutzen wollte. Da auch meine Frau das Front-end verwendet, wollte ich es relativ minimalistisch halten.

@Frank_Huber, Beta-User: Haben beide den Nachteil, dass man wieder mehrere "Devices" in FHEM hat.

[MadMax-FHEM]

Du musst ja nicht JEDES fhem-Device in einen Raum stecken!

Und das was du willst leistet ein simpler dummy, der hat, wenn man setExtensions aktiviert sehr wohl on-for-timer...

Und auch readingsProxy bietet genau das: eigene set-Funktionen...

Vermutlich solltest du etwas nachlesen wie fhem so funktioniert

EDIT: leider/"Gott sei Dank" bietet fhem halt viele "Varianten"/"Möglichkeiten" etwas umzusetzen...

Statt diverse at und notify gibt es auch noch DOIF (bin ich zwar kein Freund von aber bevor man ettliche at und notify etc. kombiniert)...
Es gibt auch noch mSwitch-Modul (oder gab es mal!?)...


D.h. du brauchst doch wirklich nur das Device in einen Raum stecken, welches auch "Bedien-relevat" oder "Informations-Relevant" ist.
Mache zumindest ich so...

Alle anderen Devices haben entweder GAR KEINEN Raum...
...oder sind in System o.ä.


D.h. um bei dem (nicht schönen aber funktionierenden) Beispiel mit dummy zu bleiben:

dummy mit setExtensions -> da geht mit einem Klick on-for-timer
Den in den Raum Garage

Dann ein notify was eben auf on(-for-timer) und off reagiert und je nachdem eben den jeweiligen Befehl absetzt (fhem-Kommando, Perl, bash-Script, ..., ..., ..., ...)

EDIT: mal den Eventmonitor öffnen (Filter setzen) und dann sehen was bei einem Klick kommt https://wiki.fhem.de/wiki/Event_monitor / man kann sich auch notify/DOIFs anlegen lassen / was ein Device "kann" bzw. "anbietet" (per Klick) lässt sich auch z.B. per webCmd oder cmdalias etc. "anpassen"...


Dann noch bzgl. NAME und alias:

NAME ist das was zum "Ansteuern" meist per "Automatik" (-> HeimAUTOMATISIERUNG!   ) genommen wird (werden muss).
Der sollte eben bzgl. (programmierbarer) Automatismen "gut" sein -> durchdachtes Namens-Schema!

alias ist das was man (bei fhemWeb) auf der Oberfläche sieht, also das was den Anwender "anspringt"


Viel Erfolg, Joachim

[Beta-User]

Hmm, "früher" dachte ich auch, dass alles, was irgendwie zusammengehört auch in dem entsprechenden Raum zu sein hat. Tatsächlich führt mMn. aber erst dieser Ansatz zu einer gewissen Unübersichtlichkeit.

Daher habe ich jetzt eher folgende "Raumstruktur" innerhalb FHEMWEB:
Es gibt "Haupträume", wie Wohn- oder Esszimmer. Die enthalten die eigentlichen "Bedienelemente" sowie entsprechende Info-Anzeigen (z.B. zur Raumtemperatur).
Alles andere (außer temporären Devices, sonst aber wirklich alles!) steckt in Unterräumen des Oberraumes "Steuerung". Da gibt es also z.B. "Steuerung->Logik" für alle notify, at, WeekdayTimer, THRESHOLD..., die nicht irgendeinem spezielleren anderen Unterraum zugeordnet sind, "Steuerung->CUL_HM_intern" für alle Kanaldevices, die man eigentlich aus dieser Hardware-Familie nicht braucht (z.B. für die Raumthermostate RT-DN, die 6 oder 7 Devices ergeben, gibt es nur einen (per Perl-devStateIcon erweiterten) Clima-Kanal, der im Hauptraum (Schlafzimmer) angezeigt wird, der Rest findet sich hier; zwischenzeitlich ist da auch mancher Z-Wave-Kanal gelandet...). "Steuerung->Interfaces" enthält alles mögliche, was nur zur Datenübermittlung benötigt wird usw. usf..

Die Übersicht behalte ich eher dadurch, dass ich mit "list" und "show" arbeite und mir z.B. mit

Code Auswählen Erweitern

list TYPE=notify DEF
dann alle entsprechenden Eventhandler anzeigen lasse. Bei notify versuche ich zwischenzeitlich (es gibt ein paar Altlasten...), alles in "Einzeiler" zu fassen und den Rest in Perl-Code/myUtils auszulagern, der dann in aller Regel "generisch" ist. Es gibt z.B. ein notify, das auf alle Tür-oder Fenster-Events hört und dann nur dem zu $NAME passenden Heizkörper (bzw. über ein peering im Hardwaresystem mehreren davon) die Info schickt, dass "sein" Fenster offen ist (erst nach einer Wartezeit und auch nur, wenn Heizperiode angesagt ist...).

Überhaupt: devspec (z.B. das "TYPE=notify" von eben). Das kann sehr mächtig eingesetzt werden, wenn man FILTER usw. beherrscht.

Nur mal als Denkanstoß, es gibt sicher mehr Ansätze, das eine oder andere zu vereinfachen, angefangen bei einem sinnvollen Namensschema für das genannte "devspec". Damit kann man z.B. auch sehr einfach die Brücke vom Fenster zum Heizkörper bauen (room=...). Setzt halt Grundkenntnisse auch in Perl voraus, ist aber kein Hexenwerk, das soweit zu lernen.

[MadMax-FHEM]

Bis auf die Raum- und Raum-Unterstruktur (finde ich aber interessant und packe das mal auf meine [lange   ] TODO-Liste   ) und dass ich (noch bzw. stimmt nicht, habe es bei meiner Freundin auch "entkoppelt"   ) Fenster und Wandthermostate direkt gekoppelt habe...

...mache ich es ebenso!

Und ja: ein gutes Namens-Schema hilft gewisse Dinge generisch zu machen! Und da bin ich auch ein Freund davon! Wenn etwas (wegen Namensgebung) nicht generisch machbar ist, dann kommt das SOFORT auf meine TODO-Liste

Gruß, Joachim