HTTPMOD mit DEVSTATE und neuen settings

Begonnen von JoWiemann, 14 April 2015, 09:57:23

Vorheriges Thema - Nächstes Thema

JoWiemann

Hallo Stefan,

zunächst einmal vielen Dank für Dein klasse Modul. Ich habe mir erlaubt folgende Ergänzungen, die ich selber brauche, hinzuzufügen. Die Ergänzungen sind kommentiert mit: # new jowiemann ... # end new jowiemann. Ich hoffe sie finden den Weg in Deine offizielle Version. Danke Dir.

Neu DEVSTATE:


  • initialized -> das Device ist definiert, es wurde bisher allerdings noch kein Request auf das HTTP Interface durchgeführt
  • active ->  der Timer ist aktiv
  • stopped -> der Timer wurde angehalten
  • disabled -> das Attribut 'disabled' wurde gesetzt

Neue set ...


  • interval -> ein neues Abfrageintervall wird gesetzt. Bleibt nur bis zum nächsten Neustart erhalten
  • stop -> der Timer wird angehalten (wird nur bereit gestellt, wenn DEVSTATE == active oder initialized)
  • start -> der Timer wird wieder gestartet (wird nur bereit gestellt, wenn DEVSTATE == stopped)
  • reread -> ein Devicedurchlauf wird gestartet. (wird nur bereit gestellt, wenn DEVSTATE != disabled)

Über die neuen set ... kann ich nun per 'at' das device über Nacht anhalten, oder bei gesetztem 'stopped' die Regular Expressions testen, in dem ich diese verändere und über 'reread' einen neuen Durchlauf anstoße.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

StefanStrobel

Hallo Jörg,

Ich werde es ins nächste Release übernehmen. Allerdings muss ich wohl noch ein steuerndes Attribut a la enableControlSet zum Aktivieren der neuen Funktionen einbauen, damit es nicht zu Konflikten kommt wenn Anwender bereits ein Set mit Namen start, stop o.ä. definiert haben.

Gruss
     Stefan

JoWiemann

Hallo Stefan, gute Idee mit dem zusätzlichen Attribut und danke Dir.


Grüße Jörg

Gesendet von iPhone mit Tapatalk
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

StefanStrobel

Hallo Jörg,

ich habe gerade eine neue Version gepostet, in der ich den wesentlichen Teil Deiner Vorschläge eingebaut habe:
http://forum.fhem.de/index.php/topic,38401.0.html
Die Einschränkungen bzw. Abhängigkeiten der sets vom Timer-Status habe ich nicht übernommen, da es z.B. durchaus sinnvoll sein kann, mit set start den Timer zurückzusetzen, auch wenn er schon läuft.
Die Semantik des Attributs disabled wollte ich nicht ändern um keine Kompatibilitätsprobleme zu bekommen. Der Timer läuft daher bei disabled wie bisher weiter, nur die automatischen Abfragen werden unterbunden.

DEVSTATE habe ich nicht übernommen, da man den Status des Timers ja auch gut an TRIGGERTIME ablesen kann. Wenn der Timer gestoppt ist, ist TRIGGERTIME jetzt 0. Zudem fand ich die Vermischung von Status des abzufragenden Geräts, Timer und Attribut problematisch.
Ob ein Gerät erfolgreich abgefragt werden konnte, kann man bisher z.B. über das Attribut showMatched sichtbar machen.

Den Status von disabled sieht man ja mit AttrVal.

Ich hoffe die Erweiterungen sind auch für Dich so verwendbar.

Gruss
   Stefan

JoWiemann

Hallo Stefan,

danke Dir und passt schon.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM