Neues Modul für Alarmanlage

Begonnen von Prof. Dr. Peter Henning, 08 September 2014, 20:43:06

Vorheriges Thema - Nächstes Thema

sxx128

Hallole

ja eigentlich immer. Ist das falsch ? Also dann ist


00:01


1 Sekunde richtig ? 

Grüße
sxx128
Hardware: Raspberryy PI 4
CC1101-USB-Lite 868MHz/Culfw-1.66
HM-MOD-RPI-PCB
Komponenten: Homematic/Homematic IP/Zigbee
PiVCCU

gamauf

Zitat von: sxx128 am 25 November 2016, 15:47:06
Hallole

ja eigentlich immer. Ist das falsch ?
Ganz im Gegenteil!
Zitat von: sxx128 am 25 November 2016, 15:47:06
Also dann ist


00:01


1 Sekunde richtig ? 
Richtig!
Zitat von: sxx128 am 25 November 2016, 15:47:06
Grüße
sxx128

...dann weiß ich auch nicht warum es bei Dir nicht klappt!
Poste vielleich nochmal Diene Konfig!

LG
Rainer

sxx128

Hallole

vielen Dank für deine Hilfe ... das ist die Konfig aus der fhem.cfg


define alarm0.off.N notify (n_mySchalter1_off:off) {main::Alarm_Exec("AAA",0,"$NAME","$EVENT","off")}
attr alarm0.off.N group alarmNotifier
attr alarm0.off.N room Alarm
define alarm0.on.N notify (wz_schreibtischlampe:on) {main::Alarm_Exec("AAA",0,"$NAME","$EVENT","on")}
attr alarm0.on.N group alarmNotifier
attr alarm0.on.N room Alarm


werden noch andere Informationen benötigt ?

Grüße
sxx128
Hardware: Raspberryy PI 4
CC1101-USB-Lite 868MHz/Culfw-1.66
HM-MOD-RPI-PCB
Komponenten: Homematic/Homematic IP/Zigbee
PiVCCU

sxx128

Hallo zusammen,

ich habe jetzt mal fhem neu gestartet jetzt funktioniert es... Danke für die Hilfe an alle

Grüße
sxx128
Hardware: Raspberryy PI 4
CC1101-USB-Lite 868MHz/Culfw-1.66
HM-MOD-RPI-PCB
Komponenten: Homematic/Homematic IP/Zigbee
PiVCCU

gamauf

freut mich, daß es jetzt funktioniert!

Noch eine Anmerkung zu Deinem vorigen Post:
Ich nehme an
n_mySchalter1_off
ist kein Schalter sondern ein notify. Da sollte der Schalter rein!

LG
Rainer

Prof. Dr. Peter Henning

#710
Aber hier

define alarm0.off.N notify (n_mySchalter1_off:off) {main::Alarm_Exec("AAA",0,"$NAME","$EVENT","off")}

steht doch wieder ein doppeltes notify drin - und nichts von der Schreibtischlampe. Also jetzt ganz langsam zum Mitschreiben:

1. Sensor ist die Schreibtischlampe. Also muss in das Notify on Regexp-Feld dieser Zeile des Alarmmoduls eingetragen werden: wz_schreibtischlampe:off
2. In dieselbe Zeile: Welcher Alarmlevel soll getriggert werden (sagen wir 0), was soll geschehen (Auswahlfeld auf Raise)
3. Aktor ist das Radio. Also muss in das Set Action Felddieser Zeile des Alarmmoduls eingetragen werden: set wlan_radio play
4. In dieselbe Zeile: Bei welchem Alarmlevel soll dieses ausgeführt werden (0)

Resultat wird sein: Radio geht an, wenn die Lampe ausgeht.

Wenn nicht: Es gibt Warnungsmeldungen im Log.

LG

pah

Edit: Das hat sich jetzt mit 2 Posts überschnitten, egal. Allerdings kann man die Behauptung, dass alles erst nach einem FHEM-Neustart funktioniert habe, getrost im Reich der Sagen und Märchen verorten.

RobinTT

Hallo PAH,

ich muss noch einmal auf Dich zukommen, denn meine Meinnung nach ist noch nicht alles so, wie es sein sollte, nachdem Du das Alarm-Modul gestern neu eingecheckt hast.
Ich habe, wie bereits vorher geschrieben, keine Wait-, Arm- oder Disarm-Actions gesetzt und entsprechend auch den Delay-Timer auf 0:00.
Augenscheinlich klappt mit der neuen Version alles, wie es sein sollte. Nach dem Setzen des Arm-Hakens wird auch der zugehörige Readings-Level auf armed gesetzt.
ABER, wenn der Alarm dann einmal ausgelöst wird, steht anschließend in dem Reading der Name meines Sensors.
Ist das ein Bug oder ist das beabsichtigt und ich kann nur den Grund nicht erkennen?

Nehme ich dann manuell den Haken heraus (disarm) und setzte ihn wieder (arm), ist auch wieder das Reading korrekt auf armed gesetzt.

Besten Dank,
Robin


sxx128

#712
Hallole zusammen, Hallole PAH

für mich hatte es dann anschein dass es nach dem Neustart von FHEM funktioniert hat. Mit dem zweiten Notify habt ihr natürlich absolut recht...

Gefühlt hatte ich alle möglichen Variationen durch..  Mit dem Code


n_mySchalter1_off


habt ihr natürlich vollkommen recht. Das wird geändert. Mir ging es eben jetzt erstmal nur darum das der Sensor in der Lage ist einen Aktor auszulösen.

Nochmals vielen Dank für die Hilfe !!!

Grüße
sxx128
Hardware: Raspberryy PI 4
CC1101-USB-Lite 868MHz/Culfw-1.66
HM-MOD-RPI-PCB
Komponenten: Homematic/Homematic IP/Zigbee
PiVCCU

Prof. Dr. Peter Henning

#713
OK, ich war durch das Schreiben des Artikels wirklich etwas abgelenkt...

Nein, das ist kein Bug, sondern so beabsichtigt und schon seit den allerersten Versionen des Moduls so: Nach der Alarmauslösung steht der Sensorname im Reading, damit dieser auch ggf. weiter verarbeitet werden kann. Nur die Readingswerte "armed" und "disarmed" deuten auf einen scharfen (bzw. unscharfen), aber nicht ausgelösten Alarm hin.

LG

pah

Grml

Zitat von: Prof. Dr. Peter Henning am 21 November 2016, 04:19:17
@Grml: Sie muss aber auch korrekt geladen werden, die alte Version steht wahrscheinlich noch im Cache.

Nochmal wegen des Abschneidens nach dem "#"... Wie würde man denn den Cache löschen? Denn ich habe das Problem weiterhin. Ich hatte die alarm.js ausgetauscht aber FHEM inzwischen auch "regulär" upgedated. Vermutlich mache ich was falsch. Nur was?

Prof. Dr. Peter Henning

Was steht denn auf der Seite

<fhem-ip>:8083/fhem/pgm2/alarm.js

Ist das Version 2.8 ?

LG

pah

RobinTT

Hallo PAH,

stimmt! War schon immer so, habe den Wald vor lauter Bäumen nicht mehr gesehen!

Alles gut, vielen Dank!!!
Robin

coolerkerl

Okay, nach vier langen Abenden habe ich es auch hinbekommen. Danke an pah dafür!
Woran hat es gehangen? Ich habe in meiner spärlichen Testumgebung festgestellt dass das Modul erst funktioniert wenn ich das Message Part I für die Action Disarm ausfülle.  Ist das gewollt? Weil alle anderen Felder sind jetzt unbefüllt, was sich ja noch ändern kann.
Und das ist reproduzierbar. Vieleicht hab ich es üüberlesen, obwohl ich das Wiki jetzt auswendig kann!
Für alle die Ähnliches erfahren , dass es nicht läuft obwohl ansonsten alles stimmt.

Prof. Dr. Peter Henning

Das stimmt mit Sicherheit nicht.

Erstens: Es gibt keinen "Message Part I" für "die" Disarm Action. Die Disarm Action steht in der oberen Tabelle "Settings" - und dort gibt es ein solches Feld nicht.

Zweitens: Die unter "Settings" eingetragene Disarm Action ist vollkommen optional - sie soll ja dem Benutzer nur mitteilen, dass die Anlage unscharf geschaltet wurde, und eventuell Weiteres auslösen.

Drittens: Man kann, muss aber nicht, einen oder mehrere Sensoren definieren, welche die Disarm Action auslösen. Diese Sensoren sind aber eben nicht gleich der Disarm Action.

Viertens: Message Part I ist optional. Bei mir ist sie für den Sensor, der die Disarm Action auslöst, leer. Und zwar schon seit Jahren. Das ist auch vollkommen richtig so - denn die oben genannte Disarm Action führt bei mir zu einer Durchsage, weitere Hinweise benötige ich nicht.

Also bitte noch mal überlegen, was hier eigentlich gemeint ist.

LG

pah

Grml

#719
Zitat von: Prof. Dr. Peter Henning am 27 November 2016, 05:38:31
Was steht denn auf der Seite

<fhem-ip>:8083/fhem/pgm2/alarm.js

Ist das Version 2.8 ?
Sorry für die verspätete Antwort, war beruflich im Ausland.

Ja, ist die Version 2.8. Habe den ganzen RPi auch gerade aktualisiert und neu gestartet. Problem bleibt bei mir bestehen.

Nachtrag: Ich sehe gerade im Abschnitt "Actors" klappt es! Da ist die Set-Action korrekt und NICHT nach dem # abgeschnitten. Im Abschnitt "Settings" bei Wait/Arm/Disarm/Cancel besteht das Problem weiterhin.