hiya,
das problem ist ja bekanntlich, das die rauchmelder (und so wie ich das
verstanden habe alle HMS devices) nach dem einsetzen neuer batterien den code
wechseln.. nun habe ich keine lust, den jedesmal zu ändern..
ich bin gerade am überlegen, ob ich eine funktion schreibe, die aufgerufen
wird, wenn ein rauchmelder nur mittels wildcard definiert ist..
da ja im logfile der code ausgegeben wird (HMS device bae3 not defined) hatte
ich die überlegung, diesen auszuwerten und dann das entsprechende device mit
diesem code anstatt mit dem wildcard neu zu definieren.. zum testen habe ich
mir mal ein notify gebastelt; mit folgendem ergebnis:
im logfile tauchen folgende zeile auf:
2008.12.14 03:38:49 4: HMS device bae3 not defined, using the wildcard device
1003
2008.12.14 03:38:49 4: HMS Device 1003 (RM100-2: smoke_detect: off)
2008.12.14 03:39:26 4: HMS device 902a not defined, using the wildcard device
1003
2008.12.14 03:39:26 4: HMS Device 1003 (RM100-2: smoke_detect: off)
warum gelingt es mir nicht diese auszuwerten?
beispiel:
define foo notify .*HMS.*1003.* { "@ %" }
define bar notify .*HMS.*device.*not.*defined.* { "@ %" }
beide liefern nichts zurück...
define foobar notify .*actuator.* { "@ %" }
liefert z.b.
2008.12.14 03:50:09 3: EG.bz.HZ actuator: 0%
hintergrund:
ich habe drei rauchmelder in der fhem.conf definiert:
# RM100-2 Rauchmelder
define NN.xx.RM.01 HMS 1003
define NN.xx.RM.02 HMS 1003
define NN.xx.RM.03 HMS 1003
mir ist aufgefallen, das wahrscheinlich durch den wildcard lediglich der
letzte für alle gesetzt wird:
FHZ> list NN.xx.RM.01
Internals:
CODE 1003
DEF 1003
NAME NN.xx.RM.01
NR 4
STATE ???
TYPE HMS
Attributes:
comment Rauchmelder
room Haus
FHZ> list NN.xx.RM.02
Internals:
CODE 1003
DEF 1003
NAME NN.xx.RM.02
NR 5
STATE ???
TYPE HMS
Attributes:
comment Rauchmelder
room Haus
FHZ> list NN.xx.RM.03
Internals:
CODE 1003
DEF 1003
NAME NN.xx.RM.03
NR 6
STATE smoke_detect: off
TYPE HMS
Readings:
2008-12-14 03:54:34 battery ok
2008-12-14 03:54:34 smoke_detect off
2008-12-14 03:54:34 type RM100-2
Attributes:
comment Rauchmelder
room Haus
gruß martin
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-
> warum gelingt es mir nicht diese auszuwerten?
Weil es zu spaet ist :-)
> define foo notify .*HMS.*1003.* { "@ %" }
[...]
> beide liefern nichts zurück...
Doch, ein perl String, der wird aber ignoriert. Ein String ist nicht
gleich ein Kommando.
Bitte verwende "inform timer", um zu sehen, welche Events versendet
werden (und vorher Doku lesen).
Das HMS Modul verschickt z.Zt nich den urspruenglichen Device-Code,
d.h. man kann nicht in einem Notify das Geraet auf dem neuen Code
umstellen. Abgesehen davon, dass es keinen Sinn macht das automatisch
zu machen: entweder hat man ein HMS, dann ist es eh egal ob es der
wildcard ist oder nicht, oder mehrere, dann weiss der Automat aber
nicht, welches geaendert werden soll.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-
Originally posted by: <email address deleted>
Hi,
Rudolf Koenig:
> Abgesehen davon, dass es keinen Sinn macht das automatisch
> zu machen: entweder hat man ein HMS, dann ist es eh egal ob es der
> wildcard ist oder nicht,
oder der Nachbar hat so'n Ding :-P
> oder mehrere, dann weiss der Automat aber
> nicht, welches geaendert werden soll.
Doch -- man ignoriere die Meldung die ersten zwei-drei Male und nehme
dann das HMS, das in der Zwischenzeit nix gesendet hat.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: Das Zitat wurde zufällig ausgewählt. | http://smurf.noris.de
- -
Mathematiker sterben nicht, sie verlieren nur einige ihrer Funktionen!
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-
Am Sonntag, 14. Dezember 2008 schrieb Rudolf Koenig:
> > warum gelingt es mir nicht diese auszuwerten?
>
> Weil es zu spaet ist :-)
na toll :-)
> > define foo notify .*HMS.*1003.* { "@ %" }
>
> [...]
>
> Bitte verwende "inform timer", um zu sehen, welche Events versendet
> werden (und vorher Doku lesen).
worauf beziehst du dich in der doku? weiss gerade nicht was du meinst..
allerdings gibt es in der doku keinen hinweis auf "inform timer" nur [on|
off].
ABER: ich habe schon verstanden, was "inform timer" ausgibt, doch hilft mir
das hier nicht. ich kenne ja die events die ausgegeben werden.
> Das HMS Modul verschickt z.Zt nich den urspruenglichen Device-Code,
> d.h. man kann nicht in einem Notify das Geraet auf dem neuen Code
> umstellen. Abgesehen davon, dass es keinen Sinn macht das automatisch
jain.. man könnte aber über eine funktion das device mit dem wildcard löschen
und dann mit dem code neu definieren.
> zu machen: entweder hat man ein HMS, dann ist es eh egal ob es der
> wildcard ist oder nicht, oder mehrere, dann weiss der Automat aber
> nicht, welches geaendert werden soll.
und da ist meine idee so mal ins blaue geschrieben:
man definiert ein userattribut LASTDEF. notify sucht
nach .*HMS.*not.defined.*wildcard.*1003.* und kennt das device, z.b. rm01
device und string wird an funktion übergeben, funktion liest den temporären
code aus dem string, beispiel 902a ("HMS device 902a not defined,...") und
durchsucht alle rm's nach DEF 902a und LASTDEF 902a.
dann durchsucht die funktion alle STATE nach "???", bzw. wenn STATE
ungleich "???" ist, schaut er nach der letzten zeit aus reading.
wenn dann die funktion anhand irgend einer vernünftigen logik (die ich dann
noch stricken müsste) diese ganzen punkte dazu nutzt um rauszufinden, welches
gerät gerade den code gewechselt hat, dann macht die funktion ein "delete
" und ein "define HMS 902a"
damit könnte man dann für jedes device eigene weitere notify's definieren.
warum das ganze?
ich habe aktuell folgende notify's:
define RM.not.01 notify
NN.xx.RM.*:.*smoke.detect.*on.* "/usr/local/bin/fhem2mail "FEUERALARM: "
voicemail@@irgendeine_domain.com "Feueralarm wurde ausgeloest: @ %""
define RM.not.02 notify NN.xx.RM.*:.*smoke.detect.*on.* set
EG.es.SD.Licht.grp,EG.wz.SD.Licht.grp,EG.wz.DI.Decke.grp on
ich habe das mal mit .*smoke.detect.*off.* anstatt mit .*on.* getestet, da ich
nicht den rauchmelder auslösen wollte.
das klappt soweit auch. im logfile steht "HMS Device 1003 (RM100-2:
smoke_detect: off)"
die notify's erkennen das und lösen aus. voicemail@irgendeine_domain.com ist
eine weiterleitung an 1 email-adresse und 2 mail2sms-adressen. der feueralarm
müsste demnach 1x an jede adresse gesendet werden. stattdessen erhalte ich
aber 4 nachrichten je adresse.
und hier verstehe ich den zusammenhang nicht. selbst wenn alle drei
rauchmelder mit wildcard definiert sind, habe ich ja nur ein event vorliegen.
also müsste der RM.not.01 doch auch nur einmal greifen. wieso bekomme ich
aber 4 mails und 4 sms?
wenn ich nun nochmal über dein argument nachdenke, stelle ich mir gerade die
frage ob es bei mehreren rauchmeldern, die sowieso alle mit 1003 definiert
sind, diese auch alle in der config aufzuführen? demnach würde ja auch nur
ein eintrag mit HMS 1003 reichen, der dann alle rauchmelder "abbildet"?
oder wie seht ihr das, bzw. macht ihr das?
gruß martin
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-
Am Sonntag, 14. Dezember 2008 schrieb Matthias Urlichs:
> [...]
>
> Doch -- man ignoriere die Meldung die ersten zwei-drei Male und nehme
> dann das HMS, das in der Zwischenzeit nix gesendet hat.
genau das ist mein ansatz!
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-
> wenn ich nun nochmal über dein argument nachdenke, stelle ich mir gerade die
> frage ob es bei mehreren rauchmeldern, die sowieso alle mit 1003 definiert
> sind, diese auch alle in der config aufzuführen? demnach würde ja auch nur
> ein eintrag mit HMS 1003 reichen, der dann alle rauchmelder "abbildet"?
Ich habe ein aehnliches Problem mit einem Sack voll piri's. Falls
einer triggert und mir eine Nachricht schickt, dann wird eine Variable
gesetzt, und solange kein SMS mehr versendet, bis die Variable nicht
zurueckgesetzt ist.
Ob man genau wissen will wo es brennt oder nicht, haengt von vieles
ab. Eine automatische Code-Verfolgung halte ich fuer uebertrieben,
insbesondere wenn es gleich mehrere Geraete betrifft. Fuer
experimentierfreudige habe ich aber ein Event "ExactId: $odev" gerade
eingebaut.
Gruss,
Rudi
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-
Originally posted by: <email address deleted>
hatte gleiches Problem und denke ähnlich gelöst wie Rudi. Die Dummy
Variable versorge ich dann noch mit dem Verursacher. Unterschieden
wird zwischen unbedingten (Brand / Wasser) und abwesenheitsbedingten
(Kontakte) Events.
Wenn's von Interesse ist, hier die cfg:
#bei allen Brandmeldern auf jeden Fall Alarm ausloesen
define FeuerAlarm notify .*smoke.*on.* {MyAlarm("Alarm","@","%")}
#bei Tuer nur wenn Abwesend = "on" (ebenfalls eine dummy variable)
define EGTuerEingangAlarm notify EGTuerEingang.*switch.*on.* {MyAlarm
("nix","@","%")}
und hier das kleine Script im 99_...pm:
#---------- Alarm ausloesen
sub
MyAlarm($$$)
{
my $alarm = shift;
my $msg = shift;
my $msg2 = shift;
# abwesend oder unbedingter Alarm weil Feuer oder Wasser
if (( $value{Abwesend} eq "on") or ($alarm eq "Alarm") )
{
#Logbuch Eintrag
Log 1, "Alarm: $msg $msg2";
# SMS maximal 1 x senden
if ( $value{AlarmMsg} eq "off" )
{
fhz "set AlarmMsg $msg";
my $retx=`$UserDir/mailer $msg $msg2`;
#Musik einspielen
system "/opt/bin/madplay $UserDir/audio/Ueberraschung.mp3
$UserDir/audio/Terminator.mp3 -1 -q&";
}
}
}
On 23 Dez., 10:50, Rudolf Koenig wrote:
> > wenn ich nun nochmal über dein argument nachdenke, stelle ich mir gerade die
> > frage ob es bei mehreren rauchmeldern, die sowieso alle mit 1003 definiert
> > sind, diese auch alle in der config aufzuführen? demnach würde ja auch nur
> > ein eintrag mit HMS 1003 reichen, der dann alle rauchmelder "abbildet"?
>
> Ich habe ein aehnliches Problem mit einem Sack voll piri's. Falls
> einer triggert und mir eine Nachricht schickt, dann wird eine Variable
> gesetzt, und solange kein SMS mehr versendet, bis die Variable nicht
> zurueckgesetzt ist.
> Ob man genau wissen will wo es brennt oder nicht, haengt von vieles
> ab. Eine automatische Code-Verfolgung halte ich fuer uebertrieben,
> insbesondere wenn es gleich mehrere Geraete betrifft. Fuer
> experimentierfreudige habe ich aber ein Event "ExactId: $odev" gerade
> eingebaut.
>
> Gruss,
> Rudi
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-