[Gelöst] Aktivieren der Alarmanlage änder jedesmal die Konfiguration

[DarkT]

Hallo zusammen,

ich habe das Alarmanlagen-Module integriert.
Es funktioniert soweit auch alles ganz gut.

Über einen Button schalte ich die Alarmanlage nun scharf, was dazu führt das die folgenden Änderung in der fhem.cfg geschrieben wird

Code Auswählen Erweitern

attr AAA level0xec armed

Dadurch wird meine Konfiguration geändert .... (rotes Fragezeichen erscheint neben dem Save config Button)

Ist das so gewollt?

Das log meldet das folgenden:

Code Auswählen Erweitern


2017-12-04 16:18:28 Global global ATTR AAA level0xec armwait
2017-12-04 16:18:28 at alarm0.arm.dly Next: 16:18:38
2017-12-04 16:18:28 Global global DEFINED alarm0.arm.dly
2017-12-04 16:18:28 dummy alarmState 'Arming'
2017.12.04 16:18:28 3 : [Alarm 0] will be armed from alarmSensor alarmSwitch with event trigger, delay 0:10
2017.12.04 16:18:28 3 : alarm0.arm.N return value: [Alarm 0] will be armed from alarmSensor alarmSwitch with event trigger, delay 0:10
2017-12-04 16:18:28 dummy alarmSwitch trigger
2017-12-04 16:18:38 Alarm AAA level0: armed
2017-12-04 16:18:38 Global global ATTR AAA level0xec armed
2017-12-04 16:18:38 dummy alarmState 'Armed'


[Beta-User]

Vielleicht hilft das weiter: https://fhem.de/commandref_DE.html#setreading

Btw.: Sicher, dass so viele dummy-Devices erforderlich sind?

[Esjay]

Hallo zusammen,

ich habe das Alarmanlagen-Module integriert.
Es funktioniert soweit auch alles ganz gut.

Über einen Button schalte ich die Alarmanlage nun scharf, was dazu führt das die folgenden Änderung in der fhem.cfg geschrieben wird

Code Auswählen Erweitern

attr AAA level0xec armed

Dadurch wird meine Konfiguration geändert .... (rotes Fragezeichen erscheint neben dem Save config Button)

Ist das so gewollt?

Das log meldet das folgenden:

Code Auswählen Erweitern


2017-12-04 16:18:28 Global global ATTR AAA level0xec armwait
2017-12-04 16:18:28 at alarm0.arm.dly Next: 16:18:38
2017-12-04 16:18:28 Global global DEFINED alarm0.arm.dly
2017-12-04 16:18:28 dummy alarmState 'Arming'
2017.12.04 16:18:28 3 : [Alarm 0] will be armed from alarmSensor alarmSwitch with event trigger, delay 0:10
2017.12.04 16:18:28 3 : alarm0.arm.N return value: [Alarm 0] will be armed from alarmSensor alarmSwitch with event trigger, delay 0:10
2017-12-04 16:18:28 dummy alarmSwitch trigger
2017-12-04 16:18:38 Alarm AAA level0: armed
2017-12-04 16:18:38 Global global ATTR AAA level0xec armed
2017-12-04 16:18:38 dummy alarmState 'Armed'


Ich bin der Meinung das das so "gewollt" ist, geschweige denn auf pah`s liste steht das zu ändern.

Grüße

[marvin78]

Deshalb empfiehlt das Wiki auch ein save nach der Aktivierung. Irgendwie gruselig Aber es ist ja auch nur ein Hilfsmodul bzw. eine Oberfläche.

[DarkT]

Deshalb empfiehlt das Wiki auch ein save nach der Aktivierung. Irgendwie gruselig Aber es ist ja auch nur ein Hilfsmodul bzw. eine Oberfläche.

Es geht doch nicht um die Oberfläche zur Alarmanlagensteuerung. Wenn ich da was ändere ist das ja auch OK, wenn ich eine Save danach aufrufen muss.

Ich verstehe aber nicht, warum ich nach dem aktivieren der Alarmanlage (also sozusagen dem einschalten) ein Save machen muss.

Eventuell habe ich da ja auch was falsch verstanden.

Szenario:

1. Alarmanlage ist aus (Standard)
2. Alle Leute verlassen jetzt das Haus und ich möchte die Alarmanlage aktivieren
3. Ich triggere also über den Button die Alarmanlage (der Button ist wie im Bild integriert)
4. Jetzt stellt sich die Alarmanlage scharf und meine Konfiguration ist geändert worden.

Jetzt habe ich das Problem, dass ich die Konfiguration speichern muss, oder noch viel schlimmer:
Ich starte das FHEM neu (oder z.B. der Watchdog meinen raspi) und dann ist der Alarm nicht mehr aktiviert

[fhainz]

Eventuell habe ich da ja auch was falsch verstanden.

Nein hast du nicht. Das ist (leider) so.

Du könntest dir einen Dummy anlegen mit dem du nun die Alarmanlage scharf/unscharf schaltest. Ein notify das durch den dummy ausgelöst wird in dem du dann das attr in dem Alarm Modul setzt und anschließend gleich config speicherst.

[DarkT]

Nein hast du nicht. Das ist (leider) so.

Du könntest dir einen Dummy anlegen mit dem du nun die Alarmanlage scharf/unscharf schaltest. Ein notify das durch den dummy ausgelöst wird in dem du dann das attr in dem Alarm Modul setzt und anschließend gleich config speicherst.

Danke

[JoWiemann]

Hm, was ich bei einigen Modulen nicht verstehe ist, dass ein permanenter Zustand, der ja durch ein Attribut definiert wird, für einen solchen Prozess herhalten muss, weil ein nützliches Set nicht implementiert worden ist.

Hier würde ein set device alarm on/off echt helfen.

Ist aber meine persönliche Meinung.


Gesendet von iPhone mit Tapatalk

Grüße Jörg

[marvin78]

Es geht doch nicht um die Oberfläche zur Alarmanlagensteuerung.

Doch darum geht es. Es handelt sich bei dem Modul nur um eine Oberfläche, welche benötigte Hilfsdevices anlegt (im Ursprung) . Die Steuerung erfolgt über Attribute. Das alles funktioniert auch ohne das Modul. Die Oberfläche vereinfacht es nur. Works as designed.

[DarkT]

Doch darum geht es. Es handelt sich bei dem Modul nur um eine Oberfläche, welche benötigte Hilfsdevices anlegt (im Ursprung) . Die Steuerung erfolgt über Attribute. Das alles funktioniert auch ohne das Modul. Die Oberfläche vereinfacht es nur. Works as designed.

Was ich nicht verstehe, warum man eine Konfigurationsänderung benötigt um die Alarmanlage scharf zu schalten. Das hat nichts mit der Oberfläche zu tun, sondern ist Teil der internen Implementierung.

Alles andere ist völlig in Ordnung.

[Prof. Dr. Peter Henning]

Auch das ist völlig in Ordnung. Wie schon oben geschrieben: Works as designed.


Und wer sein FHEM unbeabsichtigt durch einen Watchdog neu starten lässt, hat sowieso irgendwo einen Fehler drin...


LG

pah

[DarkT]

Auch das ist völlig in Ordnung. Wie schon oben geschrieben: Works as designed.


Und wer sein FHEM unbeabsichtigt durch einen Watchdog neu starten lässt, hat sowieso irgendwo einen Fehler drin...


LG

pah

Ich bezweifele ja gar nicht, das das works as designed ist.
Ich behaupte ja nur, dass ich es nicht verstehe.
FHEM ist noch recht neu für mich. In meinem Verständniss von FHEM gibt es Konfiguration und Zustände.
Was einen Alarm auslösen kann ist Konfiguration, ob aktuell überwacht werden soll ist ein Zustand.
( Ich öffne ja auch nicht die Motorhaube um das Auto zu starten  - zumindest heutzutage )

Zum Thema Watchdog:
Wenn wir von einem hochverfügbaren System sprechen, dann müssen wir auch mit Fehlern umgehen können. Nicht ohne Grund ist ein Watchdog-Chip auf dem raspi.

Wie gesagt: es ist wie es ist und die Diskussion dient eher meinem Verständniss. Also Danke an alle und vor allem an pah für das tolle Modul.

[Prof. Dr. Peter Henning]

Nicht ohne Grund ist ein Watchdog-Chip auf dem raspi.

Ein Raspberry Pi hat mit FHEM so viel zu tun wie ein Fahrrad mit einem Schnitzel.


pah