Originally posted by: <email address deleted>
Hallo zusammen,
Habe noch ein paar Fragen zu den Rauchmeldern von Homematic in
Zusammenspiel mit FHEM.
Habe die Melder mal erfolgreich mit FHEM gepaired state: done. Suche
nun vergeblich nach infos, welche Meldungen kommen/kommen könnten bzw.
ob ich Befehle an den Melder senden kann.
reglist und list und reg all haben mir nicht wirklich weitergeholfen,
keine relevanten Infos vorhanden. daher:
1. Drücke ich die Taste zum Testen empfängt FHEM anscheinend nichts
(inform timer - keine Reaktion) Sendet der Melder nicht zu FHEM?
Eigentlich sollte hier doch etwas daherkommen? Auch das logfile ist
leer. Bzw. kommt nichts dazu.
2. Kann ich einen test / alarm Befehl zum Melder senden? Würde gerne aus
FHEM auslösen können?!
3. Mit devicepair sollte ich doch mehrere Rauchmelder direkt miteinander
verbinden können, kann mir jemand bitte ein Beispiel geben, wie ich das
in der Fhem commandline eingeben müsste? Das Tutorial hab ich zwar
gelesen bin aber noch unsicher ob ich es ganz verstanden habe.
Also welche Namen / IDs ich hier angeben muss. bzw. wo ich die richtigen
auslese.
Einfach wäre natürlich die namen zu verwenden, aber das geht nich oder?
(will nicht experimentieren, damit ich die fhem conf nicht gleich
zerstöre *smile*
Danke nochmal für die Hilfe,
Martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hi Martin!
Also zumindest kannst du in FHEM nach klick auf smoke Detector bei "set"
"test" aufrufen und der HM sollte dir mit mehreren Signalen antworten.
Suche
> nun vergeblich nach infos, welche Meldungen kommen/kommen könnten bzw.
> ob ich Befehle an den Melder senden kann.
>
>
> 1. Drücke ich die Taste zum Testen empfängt FHEM anscheinend nichts
> (inform timer - keine Reaktion) Sendet der Melder nicht zu FHEM?
> Eigentlich sollte hier doch etwas daherkommen? Auch das logfile ist
> leer. Bzw. kommt nichts dazu.
>
> 2. Kann ich einen test / alarm Befehl zum Melder senden? Würde gerne aus
> FHEM auslösen können?!
>
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo Martin
>
>
> Habe die Melder mal erfolgreich mit FHEM gepaired state: done. Suche
> nun vergeblich nach infos, welche Meldungen kommen/kommen könnten bzw.
> ob ich Befehle an den Melder senden kann.
>
> reglist und list und reg all haben mir nicht wirklich weitergeholfen,
>
reglist zeigt, welche Register unterstützt werden
reg all zeigt die Registerinhalten an wenn sie VORHER gelesen wurden - mit
getConfig beispielsweise
viel kann man bei einem Rauchmelder nicht einstellen. Man kann aber sehen,
ob er mit der Zentrale gepairt ist.
Nebenbei sollte man ich die Peers lesenn koennen, wenn man mit sog. Teams
arbeitet
keine relevanten Infos vorhanden. daher:
>
> 1. Drücke ich die Taste zum Testen empfängt FHEM anscheinend nichts
> (inform timer - keine Reaktion) Sendet der Melder nicht zu FHEM?
> Eigentlich sollte hier doch etwas daherkommen? Auch das logfile ist
> leer. Bzw. kommt nichts dazu.
>
Generell sollte der Rauchmelder etwas senden. FHEM empfängt immer und
monitored alles - auch wenn es nicht an die Zentrale gerichtet ist.
>
> 2. Kann ich einen test / alarm Befehl zum Melder senden? Würde gerne aus
> FHEM auslösen können?!
>
fuer den SD sollte es doch das Kommando 'test' geben.
>
> 3. Mit devicepair sollte ich doch mehrere Rauchmelder direkt miteinander
> verbinden können, kann mir jemand bitte ein Beispiel geben, wie ich das
> in der Fhem commandline eingeben müsste? Das Tutorial hab ich zwar
> gelesen bin aber noch unsicher ob ich es ganz verstanden habe.
> Also welche Namen / IDs ich hier angeben muss. bzw. wo ich die richtigen
> auslese.
> Einfach wäre natürlich die namen zu verwenden, aber das geht nich oder?
>
geht alles mit Namen. Bei einem "Team" ist einer immer der 'Teamleader' -
also dessen HMID wird als gruppenID genutzt. Mit diesem musst du peeren.
set devicepair 0 single set actor
auch commandref zu devicepair lesen
(will nicht experimentieren, damit ich die fhem conf nicht gleich
> zerstöre *smile*
>
>
> Gruss
Martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hi Martin,
danke für deine Antworten.
Ja hab die command referenz ja gelesen, aber tu mir mit den ganzen
Ausdrücken etc. noch etwas schwer.:-)
1. hab also wie folgt eingegeben:
set Rauchmelder_EG devicepair 0 Rauchmelder_WZ single set actor
Was sich nun geändert hat ist, dass unter dem Rauchmelder_WZ (im Raum)
statt den ??? die vorher dort standen das steht:
all-clear:from:Rauchmelder_WZ
Aber es wird in den details von beiden bei pair immer nur die Zentrale
angezeigt. Sieht man nicht, welche Geräte gepaired sind, oder muss ich
nochmal ein getConfig aufrufen, damit die Daten aktuell sind?
2. Wegen Test/Alarm:
Ja hab test als Befehl in der command ref gesehen, der geht auch und
gibt batteriestatus zurück. Aber es erklingt kein Test Ton. Es sind auch
alarmOn und alarmOff angeführt, die haben aber nichts getan. (es steht
aber auch dort dass mind. zwei gepaired sein müssen, damit dieser Befehl
geht- was ich ja noch nicht geschafft habe ;-) )
Würden diese Befehle dann jeweils den Alarm auslösen und stoppen? (also
mit Akustisch und optischer Anzeige?
3. Wird der Batteriestatus auch so an fhem übermittelt wenn er low ist,
oder müsste ich hier regelmäßig einen Test von fhem aus aufrufen?
4. und zu guter letzt: Wie sieht ein alarm aus, also wenn ich ein
notifiy machen möchte, was muss ich abfragen? Rauchmelder_EG: on? (das
hat er ausgespuckt als ich alarmOn aufgerufen habe - aber ohne wirklich
alarm auszulösen, also er blieb stumm - war aber auch nicht gepaired mit
einem zweiten)
Tja, schon wieder so viele Fragen, sorry, aber am Anfang ist alles etwas
mühsam... ;-) Aber ich lese fleissig und mache fortschritte *smile*
lG
Martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
>
> 1. hab also wie folgt eingegeben:
> set Rauchmelder_EG devicepair 0 Rauchmelder_WZ single set actor
>
> Was sich nun geändert hat ist, dass unter dem Rauchmelder_WZ (im Raum)
> statt den ??? die vorher dort standen das steht:
> all-clear:from:Rauchmelder_WZ
>
> Aber es wird in den details von beiden bei pair immer nur die Zentrale
> angezeigt.
pair oder peer? Damit tun sich viele schwer.
PairedTo ist die Zentrale
peerList ist die Liste der peers.Hier koennen andere Racuhmelder stehen
Sieht man nicht, welche Geräte gepaired sind, oder muss ich
> nochmal ein getConfig aufrufen, damit die Daten aktuell sind?
>
ein devicepair setzt nur die Daten. Nachfragen (getConfig) muss man immer
selbst auslösen. Da ist der Overhead zu gross, so dass ich es nicht nach
jeden Befehl setzen will...
>
> 2. Wegen Test/Alarm:
>
> Ja hab test als Befehl in der command ref gesehen, der geht auch und
> gibt batteriestatus zurück. Aber es erklingt kein Test Ton. Es sind auch
> alarmOn und alarmOff angeführt, die haben aber nichts getan. (es steht
> aber auch dort dass mind. zwei gepaired sein müssen, damit dieser Befehl
> geht- was ich ja noch nicht geschafft habe ;-) )
>
hmm - ich habe leider keinen zum Probieren. Und ob du schon gepairt hast
musst du erst prüfen
> Würden diese Befehle dann jeweils den Alarm auslösen und stoppen? (also
> mit Akustisch und optischer Anzeige?
>
würde ich erwarten.
>
> 3. Wird der Batteriestatus auch so an fhem übermittelt wenn er low ist,
> oder müsste ich hier regelmäßig einen Test von fhem aus aufrufen?
>
Der Rauchmelder sendet regelmässig - ich denke alle 23h - also etwa einmal
am Tag. Soll Batterie sparen.
Wenn dass alles läuft bekommst du einen event (notify) und kannst es im
Status nachlesen.
Ausserdem sollte im ActionDetector ein eintrag stehen, der bei Rauchmeldern
alle 28h etwas sehen will (eine message vom device) Sollte diese nicht
kommen wird der Zustand als 'dead' angezeigt.
> 4. und zu guter letzt: Wie sieht ein alarm aus, also wenn ich ein
> notifiy machen möchte, was muss ich abfragen? Rauchmelder_EG: on? (das
> hat er ausgespuckt als ich alarmOn aufgerufen habe - aber ohne wirklich
> alarm auszulösen, also er blieb stumm - war aber auch nicht gepaired mit
> einem zweiten)
>
Alarm detected:
state [all-clear|on]
smoke_detect:on from
Autonom Event:
test:from :
battery:[low|ok]
InfoLevel:
state:alive
battery:[low|ok]
Configs:
SDteam:add_
SDteam:remove_
Tja, schon wieder so viele Fragen, sorry, aber am Anfang ist alles etwas
> mühsam... ;-) Aber ich lese fleissig und mache fortschritte *smile*
>
wird schon
Gruss
Martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hi!
Bei mir sendet er in diesen Abständen:
2012-11-12_16:10:30 CUL_HM_smokeDetector_1CBC64 battery: ok
2012-11-12_16:10:30 CUL_HM_smokeDetector_1CBC64 alive
2012-11-18_20:07:27 CUL_HM_smokeDetector_1CBC64 battery: ok
2012-11-18_20:07:27 CUL_HM_smokeDetector_1CBC64 alive
2012-11-21_10:47:13 CUL_HM_smokeDetector_1CBC64 battery: ok
2012-11-21_10:47:13 CUL_HM_smokeDetector_1CBC64 alive
2012-11-28_12:09:42 CUL_HM_smokeDetector_1CBC64 battery: ok
2012-11-28_12:09:42 CUL_HM_smokeDetector_1CBC64 alive
2012-12-01_13:35:27 CUL_HM_smokeDetector_1CBC64 battery: ok
2012-12-01_13:35:27 CUL_HM_smokeDetector_1CBC64 alive
2012-12-04_07:28:16 CUL_HM_smokeDetector_1CBC64 battery: ok
2012-12-04_07:28:16 CUL_HM_smokeDetector_1CBC64 alive
2012-12-11_15:23:01 CUL_HM_smokeDetector_1CBC64 battery: ok
2012-12-11_15:23:01 CUL_HM_smokeDetector_1CBC64 alive
Am Donnerstag, 13. Dezember 2012 07:13:22 UTC+1 schrieb Martin:
>
>
>
>> 3. Wird der Batteriestatus auch so an fhem übermittelt wenn er low ist,
>> oder müsste ich hier regelmäßig einen Test von fhem aus aufrufen?
>>
> Der Rauchmelder sendet regelmässig - ich denke alle 23h - also etwa einmal
> am Tag. Soll Batterie sparen.
> Wenn dass alles läuft bekommst du einen event (notify) und kannst es im
> Status nachlesen.
> Ausserdem sollte im ActionDetector ein eintrag stehen, der bei
> Rauchmeldern alle 28h etwas sehen will (eine message vom device) Sollte
> diese nicht kommen wird der Zustand als 'dead' angezeigt.
>
>
>>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Morgen Martin!
> pair oder peer? Damit tun sich viele schwer.
pair zeigt die Zentrale an: Ja korrekt.
peerlist: cleared! (hab ich natürlich auch gechecked, sorry nur nicht
extra angegeben. )
Hab auch ein getConfig gemacht, peerlist bleibt cleared.
Irgendwas scheine ich falsch zu machen, sie wollen sich nicht paaren.
Haben wohl Angst vor Nachwuchs.
any idea?
Hab also versucht:
set Rauchmelder_EG devicepair 0 Rauchmelder_WZ single set actor
und umgekerht, falls es nur in eine Richtung gehen würde. Beides
erfolglos.:-(
Danach jeweils getConfig gesetzt (und am Gerät sicherheitshalber sogar
mit Tastendruck bestätigt, falls er sonst nicht antwortet).
Es ändert sich nichts. :-(
Ähm, wo hast du die Liste mit den möglichen Zuständen her? Die hab ich
bisher niergends gefunden. also bei den reglist etc. nicht und im
command ref nicht....?
lG
Martin
Am 13.12.2012 07:13, schrieb Martin:
>
>
> 1. hab also wie folgt eingegeben:
> set Rauchmelder_EG devicepair 0 Rauchmelder_WZ single set actor
>
> Was sich nun geändert hat ist, dass unter dem Rauchmelder_WZ (im
> Raum)
> statt den ??? die vorher dort standen das steht:
> all-clear:from:Rauchmelder_WZ
>
> Aber es wird in den details von beiden bei pair immer nur die
> Zentrale
> angezeigt.
>
> pair oder peer? Damit tun sich viele schwer.
> PairedTo ist die Zentrale
> peerList ist die Liste der peers.Hier koennen andere Racuhmelder stehen
>
> Sieht man nicht, welche Geräte gepaired sind, oder muss ich
> nochmal ein getConfig aufrufen, damit die Daten aktuell sind?
>
>
> ein devicepair setzt nur die Daten. Nachfragen (getConfig) muss man
> immer selbst auslösen. Da ist der Overhead zu gross, so dass ich es
> nicht nach jeden Befehl setzen will...
>
>
> 2. Wegen Test/Alarm:
>
> Ja hab test als Befehl in der command ref gesehen, der geht auch und
> gibt batteriestatus zurück. Aber es erklingt kein Test Ton. Es
> sind auch
> alarmOn und alarmOff angeführt, die haben aber nichts getan. (es
> steht
> aber auch dort dass mind. zwei gepaired sein müssen, damit dieser
> Befehl
> geht- was ich ja noch nicht geschafft habe ;-) )
>
>
> hmm - ich habe leider keinen zum Probieren. Und ob du schon gepairt
> hast musst du erst prüfen
>
> Würden diese Befehle dann jeweils den Alarm auslösen und stoppen?
> (also
> mit Akustisch und optischer Anzeige?
>
> würde ich erwarten.
>
>
> 3. Wird der Batteriestatus auch so an fhem übermittelt wenn er low
> ist,
> oder müsste ich hier regelmäßig einen Test von fhem aus aufrufen?
>
> Der Rauchmelder sendet regelmässig - ich denke alle 23h - also etwa
> einmal am Tag. Soll Batterie sparen.
> Wenn dass alles läuft bekommst du einen event (notify) und kannst es
> im Status nachlesen.
> Ausserdem sollte im ActionDetector ein eintrag stehen, der bei
> Rauchmeldern alle 28h etwas sehen will (eine message vom device)
> Sollte diese nicht kommen wird der Zustand als 'dead' angezeigt.
>
>
> 4. und zu guter letzt: Wie sieht ein alarm aus, also wenn ich ein
> notifiy machen möchte, was muss ich abfragen? Rauchmelder_EG: on?
> (das
> hat er ausgespuckt als ich alarmOn aufgerufen habe - aber ohne
> wirklich
> alarm auszulösen, also er blieb stumm - war aber auch nicht
> gepaired mit
> einem zweiten)
>
> Alarm detected:
> state [all-clear|on]
> smoke_detect:on from
>
>
> Autonom Event:
> test:from :
> battery:[low|ok]
>
> InfoLevel:
> state:alive
> battery:[low|ok]
>
> Configs:
> SDteam:add_
> SDteam:remove_
>
> Tja, schon wieder so viele Fragen, sorry, aber am Anfang ist alles
> etwas
> mühsam... ;-) Aber ich lese fleissig und mache fortschritte *smile*
>
>
> wird schon
> Gruss
> Martin
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
> Bei mir sendet er in diesen Abständen:
>
Dann müsste er also die restlichen 3-6 Tage nach dem letzten
Batteriestatus als dead angezeigt werden - tut er das? Weil du ja
eindeutig längere Abstände als 28 Stunden hast.
Oder versteh ich etwas noch nicht ganz richtig....?
Martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hi!
es wird kein dead angezeigt/geloggt.
Am Donnerstag, 13. Dezember 2012 09:20:22 UTC+1 schrieb Martin Thomas
Schrott:
>
> > Bei mir sendet er in diesen Abständen:
> >
> Dann müsste er also die restlichen 3-6 Tage nach dem letzten
> Batteriestatus als dead angezeigt werden - tut er das? Weil du ja
> eindeutig längere Abstände als 28 Stunden hast.
>
> Oder versteh ich etwas noch nicht ganz richtig....?
>
> Martin
>
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Am Donnerstag, 13. Dezember 2012 13:41:31 UTC+1 schrieb ilmtuelp0815:
>
> Hi!
> es wird kein dead angezeigt/geloggt.
>
>
> wie ist deine Konfiguration? Wenn der Rauchmelder angelernt wird, wird er
im ActionDetector eingetragen. Dann sollten auch die Stati kommen.
Ansonsten kannst du ihn auch manuell eintragen.
Wer alles eingetrage ist, kannst du in ActionDetector nachsehen.
Der ActionDetector wird automatisch erstellt, wenn er "gebraucht" wird.
also wenn er entweder automatisch (anlernen) oder manuell 'geschaltet'
wird.
Siehe actiondetect kommando
Gruss
Martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
...falls es untergegangen ist im schnellen Themenwechsel:
Morgen Martin!
> pair oder peer? Damit tun sich viele schwer.
pair zeigt die Zentrale an: Ja korrekt.
peerlist: cleared! (hab ich natürlich auch gechecked, sorry nur nicht
extra angegeben. )
Hab auch ein getConfig gemacht, peerlist bleibt cleared.
Irgendwas scheine ich falsch zu machen, sie wollen sich nicht paaren.
Haben wohl Angst vor Nachwuchs.
any idea?
Hab also versucht:
set Rauchmelder_EG devicepair 0 Rauchmelder_WZ single set actor
und umgekerht, falls es nur in eine Richtung gehen würde. Beides
erfolglos.:-(
Danach jeweils getConfig gesetzt (und am Gerät sicherheitshalber sogar
mit Tastendruck bestätigt, falls er sonst nicht antwortet).
Es ändert sich nichts. :-(
Ähm, wo hast du die Liste mit den möglichen Zuständen her? Die hab ich
bisher niergends gefunden. also bei den reglist etc. nicht und im
command ref nicht....?
lG
Martin
Am 13.12.2012 07:13, schrieb Martin:
>
>
> 1. hab also wie folgt eingegeben:
> set Rauchmelder_EG devicepair 0 Rauchmelder_WZ single set actor
>
> Was sich nun geändert hat ist, dass unter dem Rauchmelder_WZ (im
> Raum)
> statt den ??? die vorher dort standen das steht:
> all-clear:from:Rauchmelder_WZ
>
> Aber es wird in den details von beiden bei pair immer nur die
> Zentrale
> angezeigt.
>
> pair oder peer? Damit tun sich viele schwer.
> PairedTo ist die Zentrale
> peerList ist die Liste der peers.Hier koennen andere Racuhmelder stehen
>
> Sieht man nicht, welche Geräte gepaired sind, oder muss ich
> nochmal ein getConfig aufrufen, damit die Daten aktuell sind?
>
>
> ein devicepair setzt nur die Daten. Nachfragen (getConfig) muss man
> immer selbst auslösen. Da ist der Overhead zu gross, so dass ich es
> nicht nach jeden Befehl setzen will...
>
>
> 2. Wegen Test/Alarm:
>
> Ja hab test als Befehl in der command ref gesehen, der geht auch und
> gibt batteriestatus zurück. Aber es erklingt kein Test Ton. Es
> sind auch
> alarmOn und alarmOff angeführt, die haben aber nichts getan. (es
> steht
> aber auch dort dass mind. zwei gepaired sein müssen, damit dieser
> Befehl
> geht- was ich ja noch nicht geschafft habe ;-) )
>
>
> hmm - ich habe leider keinen zum Probieren. Und ob du schon gepairt
> hast musst du erst prüfen
>
> Würden diese Befehle dann jeweils den Alarm auslösen und stoppen?
> (also
> mit Akustisch und optischer Anzeige?
>
> würde ich erwarten.
>
>
> 3. Wird der Batteriestatus auch so an fhem übermittelt wenn er low
> ist,
> oder müsste ich hier regelmäßig einen Test von fhem aus aufrufen?
>
> Der Rauchmelder sendet regelmässig - ich denke alle 23h - also etwa
> einmal am Tag. Soll Batterie sparen.
> Wenn dass alles läuft bekommst du einen event (notify) und kannst es
> im Status nachlesen.
> Ausserdem sollte im ActionDetector ein eintrag stehen, der bei
> Rauchmeldern alle 28h etwas sehen will (eine message vom device)
> Sollte diese nicht kommen wird der Zustand als 'dead' angezeigt.
>
>
> 4. und zu guter letzt: Wie sieht ein alarm aus, also wenn ich ein
> notifiy machen möchte, was muss ich abfragen? Rauchmelder_EG: on?
> (das
> hat er ausgespuckt als ich alarmOn aufgerufen habe - aber ohne
> wirklich
> alarm auszulösen, also er blieb stumm - war aber auch nicht
> gepaired mit
> einem zweiten)
>
> Alarm detected:
> state [all-clear|on]
> smoke_detect:on from
>
>
> Autonom Event:
> test:from :
> battery:[low|ok]
>
> InfoLevel:
> state:alive
> battery:[low|ok]
>
> Configs:
> SDteam:add_
> SDteam:remove_
>
> Tja, schon wieder so viele Fragen, sorry, aber am Anfang ist alles
> etwas
> mühsam... ;-) Aber ich lese fleissig und mache fortschritte *smile*
>
>
> wird schon
> Gruss
> Martin
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hi Martin!
Dieser Action Detector ist mir noch etwas suspekt! Ich habe seinen Sinn
noch nicht erkannt :( Er wurde von autocreate eingetragen, schreibt aber
keine Werte ins log.
### ??? was soll das denn für ein Gerät sein ???
define ActionDetector CUL_HM 000000
attr ActionDetector actCycle 600
attr ActionDetector ignore 1
attr ActionDetector room CUL_HM
define FileLog_ActionDetector FileLog ./log/ActionDetector-%Y.log
ActionDetector
attr FileLog_ActionDetector logtype text
attr FileLog_ActionDetector room CUL_HM
Am Donnerstag, 13. Dezember 2012 17:37:46 UTC+1 schrieb Martin:
>
>
>
> Am Donnerstag, 13. Dezember 2012 13:41:31 UTC+1 schrieb ilmtuelp0815:
>>
>> Hi!
>> es wird kein dead angezeigt/geloggt.
>>
>>
>> wie ist deine Konfiguration? Wenn der Rauchmelder angelernt wird, wird er
> im ActionDetector eingetragen. Dann sollten auch die Stati kommen.
> Ansonsten kannst du ihn auch manuell eintragen.
> Wer alles eingetrage ist, kannst du in ActionDetector nachsehen.
>
> Der ActionDetector wird automatisch erstellt, wenn er "gebraucht" wird.
> also wenn er entweder automatisch (anlernen) oder manuell 'geschaltet'
> wird.
> Siehe actiondetect kommando
>
> Gruss
> Martin
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
> Hab auch ein getConfig gemacht, peerlist bleibt cleared.
>
> Irgendwas scheine ich falsch zu machen, sie wollen sich nicht paaren.
> Haben wohl Angst vor Nachwuchs.
> #
>
was ist passiert? Irgendwas? hast du anlernen gedrueckt? Rauchmelder kann
man nicht einfach ansprechen, muss man erst wachrütteln.
Ansonsten die messages aufzeichnen
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Der ActionDetector soll erkennen, ob ein device noch lebt, also irgend eine
aktion ergreift, die man sehen kann.
Er wird automatisch instanziiert wenn die Funktion bei einem Device
aufgerufen wird.
Das kann man manuell machen mit set device actiondetect 00:10 - das device
soll alle 10 min eine Nachricht senden.
Bei devices die sich regelmässig melden sollen wird der actiondetector
automatisch eingerichtet - beim Anlernen. i.A. sind dies devices mit
Batterie. Falls man andere devices addieren will, kann man dies tun, siehe
kommmando.
Der Actiondetctor soll so gut es geht im Hintergrund arbeiten, low
performance. Er kommt in deinem Fall alle 600sec (10 min) dran und prüft
alle devices in seiner Liste.
Nach restart sind alle devices unknown und werden dann entweder auf alive
oder dead gesetzt.
Zusehen ist die Liste der überwachten IDs im ActionDetector peerIDs
attribut. Der User sollte dies nicht aendern - aber ich habe kein
geschütztes Datenfeld, dass ich benutzen kann und das gespeichert wird.
Ausserdem siehst du in den Attributen actCycel und actStatus den Zustand
Ziel ist die überwachung, wenn die Batterie nicht low sondern leer ist
Aber eigentlich solle es im Kommandref soweit stehen - ist dies ungenügend?
Fragen?
Gruss
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hi martin!
#
was ist passiert? Irgendwas? hast du anlernen gedrueckt? Rauchmelder kann man nicht einfach ansprechen, muss man erst wachrütteln.
Ja habe wie bereits angemerkt auch den pair knopf am gerät gedrückt.
Was passiert? Ja garnichts dass ist esja.
Meldungen kommen nur bei getconfig und bei test.
Any idea?
Keine ahnung was ich falsch mache.
Lg
m
...sent by mobile phone
-Urspr. Mitteilung-
Betreff: Re: [FHEM] Re: hm Rauchmelder
Von: Martin
Datum: 13.12.2012 22:19
> Hab auch ein getConfig gemacht, peerlist bleibt cleared.
>
> Irgendwas scheine ich falsch zu machen, sie wollen sich nicht paaren.
> Haben wohl Angst vor Nachwuchs.
> #
>
was ist passiert? Irgendwas? hast du anlernen gedrueckt? Rauchmelder kann
man nicht einfach ansprechen, muss man erst wachrütteln.
Ansonsten die messages aufzeichnen
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hi
> Ja habe wie bereits angemerkt auch den pair knopf am gerät gedrückt.
>
ok
> Was passiert? Ja garnichts dass ist esja.
> Meldungen kommen nur bei getconfig und bei test.
> Any idea?
> Keine ahnung was ich falsch mache.
>
sind die Messages gesendet worden? Dann waere ja etwas passiert - oder ist
nichts rausgegangen.
Also bitte messages aufzeichenen mit der 'raw einstellungen'
attr global verbose 1
attr global mseclog 1
attr loglevel 1
erst mal sehen ob nicht gesendet wird, nicht empfangen oder ob es etwas
anderes ist
Gruss
Martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hi und guten Morgen!
ah, sorry, jetzt hab ich alles mitgelogged hoffe ich:
2012.12.14 08:48:35.445 1: Including fhem.cfg
2012.12.14 08:48:35.507 1: Including ./log/fhem.save
2012.12.14 08:49:39.052 1: 78.142.114.1:1000 reappeared (HMLAN1)
2012.12.14 08:49:39.052 1: HMLAN_Send: AAFFE17
2012.12.14 08:49:39.052 1: HMLAN_Send: C
2012.12.14 08:49:39.052 1: HMLAN_Send: Y01,01,
2012.12.14 08:49:39.052 1: HMLAN_Send: Y02,00,
2012.12.14 08:49:39.063 1: HMLAN_Send: Y03,00,
2012.12.14 08:49:39.063 1: HMLAN_Send: Y03,00,
2012.12.14 08:49:39.063 1: HMLAN_Send: T185D8883,04,00,00000000
2012.12.14 08:49:39.097 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315330
d:1C6720 O:AFFE17
m:18362513 d2:0002
2012.12.14 08:49:39.139 1: HMLAN_Parse: HMLAN1 S:E1A840B stat:0000
t:18357AAB d:FF
r:FFBB m:F4 8410 1A840B AFFE17 06015800
2012.12.14 08:49:39.239 1: HMLAN_Send: S:S9863DBFF stat: 00
t:00000000 d:01
r:9863DBFF m:F4 8002 AFFE17 1A840B 01015800
2012.12.14 08:49:43.222 1: HMLAN_Parse: HMLAN1 S:R9863DBFF stat:0002
t:00000000 d:FF
r:7FFF m:F4 8002 AFFE17 1A840B 01015800
2012.12.14 08:49:43.222 1: HMLAN_Send: +AFFE17
2012.12.14 08:50:04.084 1: HMLAN_Send: K
2012.12.14 08:50:04.129 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315330
d:1C6720 O:AFFE17
m:183686DF d2:0001
2012.12.14 08:50:29.089 1: HMLAN_Send: K
2012.12.14 08:50:29.134 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315330
d:1C6720 O:AFFE17
m:1836E890 d2:0001
2012.12.14 08:50:31.222 1: HMLAN_Send: S:S9864A771 stat: 00
t:00000000 d:01
r:9864A771 m:F5 B001 AFFE17 1DC986 01011DC9130000
2012.12.14 08:50:31.774 1: HMLAN_Parse: HMLAN1 S:R9864A771 stat:0001
t:1836F2DE d:FF
r:FFC4 m:F5 8002 1DC986 AFFE17 00
2012.12.14 08:50:31.774 1: HMLAN_Send: +1DC986
2012.12.14 08:50:45.456 1: HMLAN_Parse: HMLAN1 S:E1DC913 stat:0000
t:1837284C d:FF
r:FFC9 m:F4 8400 1DC913 000000 1000424A455130343538383939CD000100
2012.12.14 08:50:54.098 1: HMLAN_Send: K
2012.12.14 08:50:54.144 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315330
d:1C6720 O:AFFE17
m:18374A46 d2:0002
2012.12.14 08:50:58.198 1: HMLAN_Parse: HMLAN1 S:E1DC986 stat:0000
t:18375A17 d:FF
r:FFC2 m:F9 8400 1DC986 000000 1000424A455130343538373831CD000100
2012.12.14 08:51:19.100 1: HMLAN_Send: K
2012.12.14 08:51:19.145 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315330
d:1C6720 O:AFFE17
m:1837ABF3 d2:0002
2012.12.14 08:51:44.109 1: HMLAN_Send: K
2012.12.14 08:51:44.155 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315330
d:1C6720 O:AFFE17
m:18380DA9 d2:0002
2012.12.14 08:52:09.134 1: HMLAN_Send: K
2012.12.14 08:52:09.180 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315330
d:1C6720 O:AFFE17
m:18386F6E d2:0002
2012.12.14 08:52:34.135 1: HMLAN_Send: K
2012.12.14 08:52:34.180 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315330
d:1C6720 O:AFFE17
m:1838D119 d2:0002
2012.12.14 08:52:59.160 1: HMLAN_Send: K
2012.12.14 08:52:59.205 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315330
d:1C6720 O:AFFE17
m:183932DF d2:0002
2012.12.14 08:53:24.169 1: HMLAN_Send: K
2012.12.14 08:53:24.215 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315330
d:1C6720 O:AFFE17
m:18399495 d2:0002
tja, ich seh nicht mal Spanisch, ev. Bahnhof, aber mehr nicht. gesendet
hat der hmlan, das seh ich gerade noch. Wenn parse meint, dass er eine
eingegangene Message geparsed hat, dann hat er auch empfangen. Aber was
er da parsed ist für mich natürlich völlig unverständlich, hoffe du
verstehst hmlanisch.;-)
Was ich genau getan habe, damit du nicht nachfragen musst:
bei fhem set devicepair für zwei Rauchmelder gesetzt.
bei dem ersten also dem master laut devicepair aufruf zuerst die pair
taste gedrückt, dann auch noch beim zweiten.
Okay so, oder ganz falsch?
Danke!
Martin
p.s.: bitte wirf einen kurzen Blick in den mailtopic homematic und
event-on-change-reading
Am 14.12.2012 07:46, schrieb Martin:
> Hi
>
>
> Ja habe wie bereits angemerkt auch den pair knopf am gerät gedrückt.
>
> ok
>
> Was passiert? Ja garnichts dass ist esja.
> Meldungen kommen nur bei getconfig und bei test.
> Any idea?
> Keine ahnung was ich falsch mache.
>
> sind die Messages gesendet worden? Dann waere ja etwas passiert - oder
> ist nichts rausgegangen.
>
> Also bitte messages aufzeichenen mit der 'raw einstellungen'
> attr global verbose 1
> attr global mseclog 1
> attr loglevel 1
>
> erst mal sehen ob nicht gesendet wird, nicht empfangen oder ob es
> etwas anderes ist
>
> Gruss
> Martin
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hi Martin!
Danke für deine Erklärung. Die bringt mich der Sache wahrscheinlich etwas
näher.
Mit Kommandref meinst du das pdf Heimautomatisierung, oder? Dort gibt es ja
einen Teil über HM. Leider scheint der mit einem Übersetzungsprogramm
geschrieben zu sein. Der Text ist für mich, trotzdem ich ein technisches
Studium absolvert habe und in D aufgewachsen bin, schwer verständlich. Ich
werde mir den Text aber noch einmal reinziehen. Nun habe ich ja
HM-Komponenten und verstehe vielleicht die beschriebenen Zusammenhänge
besser.
Am Donnerstag, 13. Dezember 2012 22:34:11 UTC+1 schrieb Martin:
>
>
> Aber eigentlich solle es im Kommandref soweit stehen - ist dies ungenügend?
> Fragen?
>
> Gruss
>
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hi,
nein ich denke er meint eher die fhem referenz:
http://fhem.de/commandref.html
@Martin oder jemand anders der sich schon gut auskennt:
Bei event-on-xxx-reading steht als Beschreibung:
2. If any of the attributes is set, no events occur for updates or
changes of readings
not listed in any of the attributes.
ähm, das wäre schlecht, wenn das so stimmt!!!
Wenn ich z.B. event-on-change-reading battery angebe und das device ein
Rauchmelder ist, würde ich laut dieser Erklärung keine Alarme mehr
ausgegeben bekommen, weil alarm nicht in change oder update gelistet ist.
Ich hoffe das ist ein Fehler in der Erklärung und nicht im System?
Richtig wäre, wenn ein Meldungstyp in change gelistet ist, wird er nur
bei Änderungen ausgegeben, alle anderen werden immer ausgegeben sofern
keine in update gelistet sind. Wenn dort welche gelistet sind, werden
nur diese und die in change gelisteten ausgegeben.
Das wäre die richtige Arbeitsweise - wenn dem hoffentlich so ist, bitte
die ref anpassen.:-)
lG
Martin
Am 14.12.2012 10:03, schrieb ilmtuelp0815:
> Hi Martin!
> Danke für deine Erklärung. Die bringt mich der Sache wahrscheinlich
> etwas näher.
> Mit Kommandref meinst du das pdf Heimautomatisierung, oder? Dort gibt
> es ja einen Teil über HM. Leider scheint der mit einem
> Übersetzungsprogramm geschrieben zu sein. Der Text ist für mich,
> trotzdem ich ein technisches Studium absolvert habe und in D
> aufgewachsen bin, schwer verständlich. Ich werde mir den Text aber
> noch einmal reinziehen. Nun habe ich ja HM-Komponenten und verstehe
> vielleicht die beschriebenen Zusammenhänge besser.
>
> Am Donnerstag, 13. Dezember 2012 22:34:11 UTC+1 schrieb Martin:
>
>
> Aber eigentlich solle es im Kommandref soweit stehen - ist dies
> ungenügend?
> Fragen?
>
> Gruss
>
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hi,
Aber was er da parsed ist für mich natürlich völlig unverständlich, hoffe
> du verstehst hmlanisch.;-)
>
ich uebe
>
> Was ich genau getan habe, damit du nicht nachfragen musst:
> bei fhem set devicepair für zwei Rauchmelder gesetzt.
> bei dem ersten also dem master laut devicepair aufruf zuerst die pair
> taste gedrückt, dann auch noch beim zweiten.
>
da habe ich noch einen Fehler drin (mindestens)
workaround: schreiben 'devicepair 1' anstelle vn 'devicepair 0'
Weiter: den Teamchef brauchst du nicht pairen - aber alle anderen zum
Teamchef. Die Syntax ist historisch gewachsen und etwas kryptisch - alsoset
devicepair 1 ....
set devicepair 1 ....
set devicepair 1 ....
anlernen sollte nicht notwendig sein, das device reagiert darauf eh nicht
was den stack betrifft. Also einfach kommando rausschicken
Das mit der 1 ist kein schaden - im naechsten update wird es aber auch mit
0 funktionieren
Gruss
Martin
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hi
>
> nein ich denke er meint eher die fhem referenz:
> http://fhem.de/commandref.html
>
korrekt
>
> @Martin oder jemand anders der sich schon gut auskennt:
>
> Bei event-on-xxx-reading steht als Beschreibung:
>
> 2. If any of the attributes is set, no events occur for updates or changes
> of readings
> not listed in any of the attributes.
>
> ähm, das wäre schlecht, wenn das so stimmt!!!
>
nun, so ist es gebaut,wie beschrieben. Wenn man etwas angibt wird davon
ausgegangen, dass man es komplett durchspezifiziert.
Ich habe es bisher nicht genutzt und muss erst selbst testen. Es ist
angegeben, dass man regexp nutzen kann.
Meine Präferenz waere also: '.*' in change einbauen. Dann sollten notifies
fuer alle geaenderten kommen.
Gebaut ist es als oder event. Wenn du also wildcard in 'change' eingibst
und dann in 'update' einige speziellen sollte es passen:
also
event_on_change .* # sie snytax muss ich testen...
event_on_update state
=> nun bekommst du alle aenderungen plus alles schreiben auf 'state' .
Was nicht funktioniert ist das selektive Ausschalten bestimmter events.
Finde ich schade, da es hier auch Readings gibt, die ich nicht 'notified'
haben will. Wenn du dies nutzen willst (also ausschalten einzelner Events)
musst du komplett durchspezifizieren.
Ich denke was du willst ist:
- Alle events bei Change notifizieren
- spezielle bei update quasi immer
- manche ausschliessen (beispiel: einige register)
CUL_HM kann es jetzt auch - braucht ja nur das attribut freischalten.
> Wenn ich z.B. event-on-change-reading battery angebe und das device ein
> Rauchmelder ist, würde ich laut dieser Erklärung keine Alarme mehr
> ausgegeben bekommen, weil alarm nicht in change oder update gelistet ist.
> Ich hoffe das ist ein Fehler in der Erklärung und nicht im System?
>
> Richtig wäre, wenn ein Meldungstyp in change gelistet ist, wird er nur bei
> Änderungen ausgegeben, alle anderen werden immer ausgegeben sofern keine in
> update gelistet sind. Wenn dort welche gelistet sind, werden nur diese und
> die in change gelisteten ausgegeben.
>
Würde ich umgekehrt machen. Default: on change, nur auf Wunsch "on-update"
um unnötige Last zu vermeiden. Evtl noch ein event-supress.
> Das wäre die richtige Arbeitsweise - wenn dem hoffentlich so ist, bitte
> die ref anpassen.:-)
>
Ist aber nicht meine Baustelle, ich denke das kommt von Boris.
p.s. in CUL_HM habe ich ein paar readings auf 'no-event' gesetzt. Das
entferne ich evtl. wieder und verweise auf diese Attribute...
Gruss
Martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hi Martin,
okay,
> workaround: schreiben 'devicepair 1' anstelle vn 'devicepair 0'
Hab also folgendes versucht:
set Rauchmelder_EG devicepair 1 Rauchmelder_Keller single set actor
Beim Keller wird nun in der Raumübersicht als letzte Meldung "NACK"
angezeigt.
Was bedeutet das?
Wie auch immer, gepaired ist immer noch nichts, also irgendwo noch ein
hund begraben. PERList ist immer noch cleared.
Habe auch versucht mit pair Taste zu bestätigen und auch getconfig neu
geladen. Sogar getdevicepair ausgeführt. Die Liste bleibt cleared und
sie scheinen auch nicht gepaired zu sein, da nur einer alarm schlägt
wenn ich die test taste drücke.
Was nun? ...
Martin
Am 14.12.2012 13:07, schrieb Martin:
>
> Hi,
>
> Aber was er da parsed ist für mich natürlich völlig
> unverständlich, hoffe du verstehst hmlanisch.;-)
>
>
> ich uebe
>
>
> Was ich genau getan habe, damit du nicht nachfragen musst:
> bei fhem set devicepair für zwei Rauchmelder gesetzt.
> bei dem ersten also dem master laut devicepair aufruf zuerst die
> pair taste gedrückt, dann auch noch beim zweiten.
>
> da habe ich noch einen Fehler drin (mindestens)
> workaround: schreiben 'devicepair 1' anstelle vn 'devicepair 0'
>
> Weiter: den Teamchef brauchst du nicht pairen - aber alle anderen zum
> Teamchef. Die Syntax ist historisch gewachsen und etwas kryptisch -
> alsoset devicepair 1 ....
> set devicepair 1 ....
> set devicepair 1 ....
>
> anlernen sollte nicht notwendig sein, das device reagiert darauf eh
> nicht was den stack betrifft. Also einfach kommando rausschicken
>
> Das mit der 1 ist kein schaden - im naechsten update wird es aber auch
> mit 0 funktionieren
>
> Gruss
> Martin
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hi Martin,
ah, super also event-xx geht nun... Musst du das noch einspielen, oder
sollte ein update von fhem bereits funktionieren?
Nur damit ich sicher bin, alles verstanden zu haben:
z.B. Ich möchte bei allen Meldungen jede Änderung erhalten, möchte aber
Temperatur immer erhalten, auch wenn sich nichts geändert hat:
attr xyz event-on-change-reading .*
attr xyz event-on-update-reading temperatur
(nur als Beispiel, ich wusste gerade nichts besseres als Temperatur ;-)
Wenn das so ginge wäre das für mich ganz okay, denn ich finde auch, dass
einen ja prinzipiell meist nur die Änderungen interessieren.
Generell wäre ich aber der Meinung, dass change sich nicht auf andere
Werte auswirken sollte, als die angegebenen. Also wenn ich change
battery setze, sollten alle anderen sich nicht ändern.
Aber wie du sagst, ganz richtig wäre eigentlich: Alles kommt bei
änderungen standarrdmäßig, update ändert das auf immer wenn ein wert
kommt und statt dem attr change sollte es attr no-event geben, welches
ausblenden von werten erlaubt.Das wäre in der Tat logischer.
Danke für deine Hilfe, hoffe es klappt dann bald mal alles hier ;-)
Momentan erhalte ich mehrmals stündlich Batteriemeldungen *lach* Wobei
das sehr schwankt. Der bewegungsmelder hat teilweise alle 10 Minuten
Battery ok gesendet, aber auch 20 Stunden lang nichts. Ohne ersichtliche
Logik dahinter.
lG
Martin
Am 14.12.2012 13:46, schrieb Martin:
> Hi
>
>
> nein ich denke er meint eher die fhem referenz:
> http://fhem.de/commandref.html
>
> korrekt
>
>
> @Martin oder jemand anders der sich schon gut auskennt:
>
> Bei event-on-xxx-reading steht als Beschreibung:
>
> 2. If any of the attributes is set, no events occur for updates or
> changes of readings
> not listed in any of the attributes.
>
>
> ähm, das wäre schlecht, wenn das so stimmt!!!
>
>
> nun, so ist es gebaut,wie beschrieben. Wenn man etwas angibt wird
> davon ausgegangen, dass man es komplett durchspezifiziert.
> Ich habe es bisher nicht genutzt und muss erst selbst testen. Es ist
> angegeben, dass man regexp nutzen kann.
> Meine Präferenz waere also: '.*' in change einbauen. Dann sollten
> notifies fuer alle geaenderten kommen.
> Gebaut ist es als oder event. Wenn du also wildcard in 'change'
> eingibst und dann in 'update' einige speziellen sollte es passen:
> also
> event_on_change .* # sie snytax muss ich testen...
> event_on_update state
> => nun bekommst du alle aenderungen plus alles schreiben auf 'state' .
>
> Was nicht funktioniert ist das selektive Ausschalten bestimmter
> events. Finde ich schade, da es hier auch Readings gibt, die ich nicht
> 'notified' haben will. Wenn du dies nutzen willst (also ausschalten
> einzelner Events) musst du komplett durchspezifizieren.
>
> Ich denke was du willst ist:
> - Alle events bei Change notifizieren
> - spezielle bei update quasi immer
> - manche ausschliessen (beispiel: einige register)
>
> CUL_HM kann es jetzt auch - braucht ja nur das attribut freischalten.
>
>
> Wenn ich z.B. event-on-change-reading battery angebe und das
> device ein Rauchmelder ist, würde ich laut dieser Erklärung keine
> Alarme mehr ausgegeben bekommen, weil alarm nicht in change oder
> update gelistet ist.
> Ich hoffe das ist ein Fehler in der Erklärung und nicht im System?
>
> Richtig wäre, wenn ein Meldungstyp in change gelistet ist, wird er
> nur bei Änderungen ausgegeben, alle anderen werden immer
> ausgegeben sofern keine in update gelistet sind. Wenn dort welche
> gelistet sind, werden nur diese und die in change gelisteten
> ausgegeben.
>
>
> Würde ich umgekehrt machen. Default: on change, nur auf Wunsch
> "on-update" um unnötige Last zu vermeiden. Evtl noch ein event-supress.
>
>
>
> Das wäre die richtige Arbeitsweise - wenn dem hoffentlich so ist,
> bitte die ref anpassen.:-)
>
>
> Ist aber nicht meine Baustelle, ich denke das kommt von Boris.
>
> p.s. in CUL_HM habe ich ein paar readings auf 'no-event' gesetzt. Das
> entferne ich evtl. wieder und verweise auf diese Attribute...
>
> Gruss
> Martin
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo Martin
set Rauchmelder_EG devicepair 1 Rauchmelder_Keller single set actor
Beim Keller wird nun in der Raumübersicht als letzte Meldung "NACK"
angezeigt.
Was bedeutet das?
>> erst einmal heist es, dass der Rauchmelder geantwortet hat (timeout:
keine Antwort, NACK: Kommando erhalten aber nicht akzeptiert).
>> evtl ist der Rauchmelder schon/noch gepairt.
>> ein getConfig sollte einfach auch ohne 'anlernen' ausführbar sein -
kannst du die Messages dazu posten?
>> Nanach werd ich ein paar raw messages zusammenstellen... wenn ich die
logs habe
ah, super also event-xx geht nun... Musst du das noch einspielen, oder
> sollte ein update von fhem bereits funktionieren?
>
erst beim nächsten Update - habe es für heute geplant. Bin einfach zu
langsam mit dem Testen....
>
> Nur damit ich sicher bin, alles verstanden zu haben:
>
> z.B. Ich möchte bei allen Meldungen jede Änderung erhalten, möchte aber
> Temperatur immer erhalten, auch wenn sich nichts geändert hat
> attr xyz event-on-change-reading .*
> attr xyz event-on-update-reading temperatur
>
> (nur als Beispiel, ich wusste gerade nichts besseres als Temperatur ;-)
> Wenn das so ginge wäre das für mich ganz okay, denn ich finde auch, dass
> einen ja prinzipiell meist nur die Änderungen interessieren.
> Generell wäre ich aber der Meinung, dass change sich nicht auf andere
> Werte auswirken sollte, als die angegebenen. Also wenn ich change battery
> setze, sollten alle anderen sich nicht ändern.
>
korrekt - so habe ich es getestet - und hat funktioniert. Generell ist der
Mechanismus nicht von mir, ich hänge mich nur dran. Der Aufbau ist aber
konsequent und ich halte ihn für gut. Die Philosophie ist:
1) wenn du die Steuerung in die Hand nimmst musst du es komplett machen.
Also beim ersten Eintrag sind ALLE events betroffen
2) ein Eintrag hat keine Auswirkung auf andere Einträge (Einschrängung ist
punkt 1)
3) das zusammensspiel change/update ist komplett beschrieben und gilt
'FHEM-weit'
4) ich habe Mechanismen in CUL_HM eingebaut, die duplicate meldungen
Vermeiden. Das werde ich jetzt entfernen.
Probleme/herausforderungen ind
5) eine default Beschreibung waere m.E. sinnvoll im commandref -
entsprechend den Settings wie wir sie besprochen haben ('.*' in change,
spechails in update)
6) Events zu unterdrücken ist schwierig, da dies nur über eine
"negativliste" funktioniert. evtl wird noch eine event-supress liste
eingefügt.
7) das interface zum setzen ist nicht sehr userfreundlich, da immer eine
komplette liste eingegeben werden muss. Dies zu aendern ist aber komplex...
Gruss
Martin
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo martin!
danke für deine Antworten. Okay, bezüglich Rauchmelder:
>> evtl ist der Rauchmelder schon/noch gepairt.
Naja, schon, mit der zentrale! Aber sonst nicht, da die peer list ja
cleared ist?
>> ein getConfig sollte einfach auch ohne 'anlernen' ausführbar sein -
kannst du
die Messages dazu posten?
2012.12.15 11:25:56.572 1: HMLAN_Send: K
2012.12.15 11:25:56.617 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315330
d:1C6720 O:AFFE17
m:1DEBCD0F d2:0002
2012.12.15 11:26:21.598 1: HMLAN_Send: K
2012.12.15 11:26:21.644 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315330
d:1C6720 O:AFFE17
m:1DEC2ED5 d2:0002
2012.12.15 11:26:46.602 1: HMLAN_Send: K
2012.12.15 11:26:46.647 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315330
d:1C6720 O:AFFE17
m:1DEC9085 d2:0002
2012.12.15 11:27:11.625 1: HMLAN_Send: K
2012.12.15 11:27:11.671 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315330
d:1C6720 O:AFFE17
m:1DECF248 d2:0002
2012.12.15 11:27:36.650 1: HMLAN_Send: K
2012.12.15 11:27:36.695 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315330
d:1C6720 O:AFFE17
m:1DED540D d2:0002
2012.12.15 11:28:01.651 1: HMLAN_Send: K
2012.12.15 11:28:01.698 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315330
d:1C6720 O:AFFE17
m:1DEDB5BB d2:0002
2012.12.15 11:28:26.651 1: HMLAN_Send: K
2012.12.15 11:28:26.698 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315330
d:1C6720 O:AFFE17
m:1DEE1767 d2:0002
2012.12.15 11:28:46.867 1: HMLAN_Send: S:S9E1BE7CE stat: 00
t:00000000 d:01
r:9E1BE7CE m:1B B001 AFFE17 1DC913 00040000000000
2012.12.15 11:28:47.430 1: HMLAN_Parse: HMLAN1 S:E1DC913 stat:0000
t:1DEE6860 d:FF
r:FFCF m:1B A010 1DC913 AFFE17 0202010AAF0BFE0C170000
2012.12.15 11:28:47.431 1: HMLAN: Skip ACK
2012.12.15 11:28:47.530 1: HMLAN_Send: S:S9E1BEA02 stat: 00
t:00000000 d:01
r:9E1BEA02 m:1C B001 AFFE17 1DC913 0103
2012.12.15 11:28:47.545 1: HMLAN_Parse: HMLAN1 S:R9E1BE7CE stat:0001
t:1DEE6865 d:FF
r:FFCF m:1B A010 1DC913 AFFE17 0202010AAF0BFE0C170000
2012.12.15 11:28:47.545 1: HMLAN_Send: +1DC913
2012.12.15 11:28:47.645 1: HMLAN_Send: S:S9E1BEA75 stat: 00
t:00000000 d:01
r:9E1BEA75 m:1B 8002 AFFE17 1DC913 0101C800
2012.12.15 11:28:48.188 1: HMLAN_Parse: HMLAN1 S:R9E1BEA75 stat:0002
t:00000000 d:FF
r:7FFF m:1B 8002 AFFE17 1DC913 0101C800
2012.12.15 11:28:48.188 1: HMLAN_Send: +AFFE17
2012.12.15 11:28:48.298 1: HMLAN_Parse: HMLAN1 S:E1DC913 stat:0000
t:1DEE6BC7 d:FF
r:FFCF m:1C A010 1DC913 AFFE17 0100000000
2012.12.15 11:28:48.299 1: HMLAN: Skip ACK
2012.12.15 11:28:48.419 1: HMLAN_Parse: HMLAN1 S:R9E1BEA02 stat:0001
t:1DEE6BCC d:FF
r:FFCF m:1C A010 1DC913 AFFE17 0100000000
2012.12.15 11:28:48.419 1: HMLAN_Send: +1DC913
2012.12.15 11:28:48.519 1: HMLAN_Send: S:S9E1BEDDF stat: 00
t:00000000 d:01
r:9E1BEDDF m:1C 8002 AFFE17 1DC913 0101C800
2012.12.15 11:28:48.689 1: HMLAN_Parse: HMLAN1 S:R9E1BEDDF stat:0002
t:00000000 d:FF
r:7FFF m:1C 8002 AFFE17 1DC913 0101C800
2012.12.15 11:28:48.689 1: HMLAN_Send: +AFFE17
2012.12.15 11:28:51.654 1: HMLAN_Send: K
2012.12.15 11:28:51.700 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315330
d:1C6720 O:AFFE17
m:1DEE7917 d2:0003
>> Nanach werd ich ein paar raw messages zusammenstellen... wenn ich
die logs habe
Hoffe die log Einträge oben sind das was du wolltest
:-)
@event-on-change-reading:
1) wenn du die Steuerung in die Hand nimmst musst du es komplett machen.
Also beim
ersten Eintrag sind ALLE events betroffen
Okay, also nur für die letzte Sicherheit, ein Beispiel mit einem
Bewegungsmelder
(vielleicht hast du einen zum Testen:
Ich will alle Bewegungen aber nur Batteriemeldungen wenn sie sich ändern:
attr xyz event-on-change-reading .*
attr xyz event-on-update-reading motion.*
Hab ich richtig verstanden, dass ich in diesem Fall die motion.* also
"motion" und
"motion: on" durch den event-on-update-reading Eintrag extra abonieren
muss, weil
mein event-on-change-reading mit dem ".*" ja alles auf nur Änderungen
gestellt hat?
:-)
Keinen Teststress bitte! Besser einmal zu viel und gut getestet, als
lauter Fehler
im System
;-)
lG
Martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo Martin
>> ein getConfig sollte einfach auch ohne 'anlernen' ausführbar sein -
> kannst du
> die Messages dazu posten?
>
korrekt, das pairing hat nicht funktioniert. Bitte die kommandos aus der
email probieren
>
> attr xyz event-on-change-reading .*
> attr xyz event-on-update-reading motion.*
> Hab ich richtig verstanden, dass ich in diesem Fall die motion.* also
> "motion" und
> "motion: on" durch den event-on-update-reading Eintrag extra abonieren
> muss, weil
> mein event-on-change-reading mit dem ".*" ja alles auf nur Änderungen
> gestellt hat? :-)
> Keinen Teststress bitte! Besser einmal zu viel und gut getestet, als
> lauter Fehler im System
>
Sollte funktionieren - aber esgibtnich mehr events wie z.B. brightness. Die
kommen dann auch nur bei aenderungen
Gruss
Martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo Martin!
>korrekt, das pairing hat nicht funktioniert. Bitte die kommandos aus
der email probieren
sind per pm an dich gegangen!
> >attr xyz event-on-change-reading .*
>
> >attr xyz event-on-update-reading motion.*
>
> >Sollte funktionieren - aber esgibtnich mehr events wie z.B.
> brightness. Die kommen dann auch nur bei aenderungen
> hm, da kommt mir eine Idee! Hier sollten doch alle regulären
> Ausdrücke, wie überall in fhem funktionieren? Dann müsste man doch
> einen Ausdruck basteln können, der das update auf
"
> .* (aber nicht) battery! setzt? Damit müsste man alles bekommen, außer
> eben die battery die ja im change sitzt.
Also soetwas wie:
".*^battery"
Kannst du das mal in update eingeben und testen? Meiner Meinung nach
sollte das dann alles außer battery Meldungen immer ausgeben und die
Battery Meldungen müssten ja bei Änderung kommen, weil wir sie im change
haben.
lG
Martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hi Martin,
wie ist jetzt hier der Stand ? ?
Sollte ich irgendetwas mit der neuen FHEM Version nochmal versuchen,
oder warten bis du deine Aufzeichnungen durchforstet hast?
Bin gerade nicht sicher, ob das jetzt behoben sein sollte, oder nicht
unter die Probleme fällt, die gesolved sind.
lG
Martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com