Ich habe 10 Rauchmelder untereinander ohne FHEM gepeert. Anschließend wollte ich die RM an FHEM anlernen. Bei neun der zehn RM hat es geklappt. Der letzte RM gibt die o.g. Fehlermeldung aus. Gerät löschen - neu Anmelden - getconfig schlug fehl. Einen Werkreset habe ich bisher nicht gemacht, da ich den RM dann an die anderen RM nicht mehr ohne FHEM angebunden bekomme. FHEM ist auf dem neuesten Stand. Was kann ich tun ?
Ruhe bewahren warten und nochmal die Anlerntaste drücken. Nicht vorher löschen!
Sagt Dein IO was von overload?
Poste mal ein list von dem rauchmelder .
Gruß Otto
Danke für die schnelle Antwort. Drücken der Anlerntaste bewirkt nichts. Sie leuchtet dann auch nur noch rot und nicht grün. Ich hoffe die Angaben unten sind richtig.
Danke im Vorraus
Matthias
Internals:
DEF 32D032
IODev CCD
NAME HM_32D032
NOTIFYDEV global
NR 99
NTFY_ORDER 50-HM_32D032
STATE RESPONSE TIMEOUT:RegisterRead
TESTNR 1
TYPE CUL_HM
protCmdDel 1
protResnd 3 last_at:2016-10-06 20:46:04
protResndFail 1 last_at:2016-10-06 20:46:10
protSnd 1 last_at:2016-10-06 20:45:50
protState CMDs_done_Errors:1
sdTeam sdLead
Readings:
2016-10-06 20:46:10 state RESPONSE TIMEOUT:RegisterRead
Regl_00.:
VAL
Helper:
HM_CMDNR 5
cSnd 01F1123432D03200040000000000,01F1123432D03200040000000000
fkt sdLead1
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +32D032,00,00,00
prefIO
rxt 0
vccu
p:
32D032
00
00
00
Mrssi:
mNo
Prt:
bErr 0
sProc 0
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Tmpl:
Attributes:
IODev CCD
autoReadReg 4_reqStatus
expert 2_raw
room
ZitatCMDs_processing...
er arbeitet.
Kennst Du codetags? Offenbar nicht :( die # taste über den smilys - bitte editiere Deinen post und packe das list dort rein. Mit Vorschau kannst Du die Wirkung sehen.
Vom list fehlt auch ne ganze Menge.
Zitatkurzer Tastendruck: Anlern-/
Konfigurationsmodus
- LED blinkt orange
- kurzer Tastendruck: Anlern-/Konfigurations-
Du drückst kurz und er leuchtet sofort rot?
Du hast SD oder SD2?
Kurz drücken und gleich rot. bei den anderen wurde die Diode nach 2 Sek. grün.
Du hast SD oder SD2 ? Klingt nach kaputt oder so.
Das list muss zwischen die Codetags!
Ich habe SD. Die Anlerntaste hat beim anlernen untereinander noch funktioniert. Das gleiche Verhalten haben die anderen RM aber auch. Sind sie einmal mit FHEM verbunden leuchtet die Diode rot.
gibst Du bitte nochmal ein komplettes list oben zwischen die codetags?
Was sagt Dein IO?
RSSI 81 ist auch etwas an der Grenze, ist der weit weg?
Die RM lassen sich mit getConfig direkt abfrufen und senden sofort, wusste ich nicht. Insofern ist das rot sofort ok. :)
Ich habe nun alle auskopiert was ich finden konnte. Da ich noch Anfänger in Sachen FHEM bin tue ich mich etwas schwer. Der RM liegt nun 3 Meter neben der Antenne.
Viele Grüße nach Leipzig
Matthias
Versuch es nochmal :)
gib bitte list HM_32D032 in der FHEm Kommandzeile oben ein und drücke enter. Dann bekommst Du ein listing.
Das kopierts Du und drückst im Post den # Knopf. Der Cursor steht zwischen den tags, dann machst ctrl v und fertig.
Es muss im Editorfenster so aussehen
Zitat[code ]set HM_32D032 clear msgEvents[ /code]
ohne die beiden Leerzeichen innerhalb der Tags. Die sind nur als "Trick"
Das Pairing ist nicht abgeschlossen! --> R-pairCentral set_0xF11234 <- da muss F11234 stehen.
Was sagt dein CCD, was von overload? Macht der überhaupt overload - weiß ich nicht.
Du kannst
set HM_32D032 clear msgEvents ausführen. Danach
set HM_32D032 getConfigVielleicht geht es dann.
Gruß Otto
Danke für die ASnleitung wie man ein Listing macht. Ich habe schon überall gesucht. Habe beide Befehle nacheinander eingegeben. Nun steht da schon eine ganze Weile CMD´s processing.
Nach einem Browser Refresh sollte CMDs processing aber irgendwann verschwinden.
Du kannst auch noch set HM_32D032 clear all und dann getConfig machen.
Ich habe das mit einem virtuellen Teamlead gemacht http://www.fhemwiki.de/wiki/HM-SEC-SD_Rauchmelder
Also alles in FHEM. ;)
Nur sudo reboot hat ihn wiederbelebt. Beide Befehle nochmal ausgeführt. Ergebniss: RESPONSE TIMEOUT:RegisterRead
Zitat von: Muff Potter 24 am 06 Oktober 2016, 19:18:14
Nur sudo reboot hat ihn wiederbelebt.
Was genau meinst Du damit? FHEM hat gehangen?
FHEM hat nicht gehangen. Firefox hat beständig versucht die seite zu aktualisieren. Mehrere Minuten ohne Erfolg. Die Pairingleuchte an der Buswareplatine die sonst nur blinkt, hatte fast dauerleuchten.
hast Du clear all versucht?
Nein habe ich nicht. Dachte das es alles löscht. Soll ich es probieren ?
Es löscht alle Inhalte, aber nicht das Gerät. Anschließend mit getConfig wird alles neu eingelesen.
clear all gibt es bei mir leider nicht. Habe statt dessen nur clear genommen. Eine Frage: Bei den angemeldeten RM steht auf der Geräteseite hinter dem Gerätenamen assignhmkey, bei Hm_D032 ist virtual vorgewählt. Hat das etwas zu bedeuten ?
naja offenbar ist das der Teamlead.
Und er ist noch nicht gepairt, deswegen eventuell die unvollständige Ansicht.
Wenn Du es noch einmal mit einem vollständigen List versuchen würdest, kann martin Dir vielleicht helfen.
Ich bin mit meinem Latein zu Ende. Ich habe es wie gesagt anders gemacht, nach Wiki, erst gepairt und dann mit virtuellem Teamlead.
Gruß Otto
habe die Liste aktualisiert. Natürlich habe ich das halbfertige Gerät nicht zum teamlead gemacht. Auch nícht virtuell.
Was mich wunderte war das das virtual oben als erstes im Pulldownmenü auftauchte wo sonst assignhmkey an erster Stelle steht.
Wie kann ich jetzt an weitere Hilfe gelangen ?
Vielen Dank für deine Mühe
Naja Du hast das nicht wissentlich gemacht. Aber soweit ich verstanden habe gibt es immer einen Teamlead, dass passiert wenn Du die ersten beiden peerst.
Du musst Dir das nochmal mit den Codetags anschauen, den Ende Tag [/ code] musst Du am Ende von dem List anordnen. Jetzt stehen beide tags am Anfang hintereinander, dass macht keinen Sinn.
Welche Kommandos hast Du bei set zur Auswahl?
Gruß Otto
Gets ------
cmdList
param -param-
reg -addr- ... -list- -peer-
regList
regVal -addr- ... -list- -peer-
saveConfig -filename- ...
Sets ------
alarmOff
alarmOn
assignHmKey
clear [readings|rssi|msgEvents|unknownDev]
clear [readings|trigger|register|oldRegs|rssi|msgEvents|attack|all]
deviceRename newName
fwUpdate -filename- -bootTime- ...
getConfig
getRegRaw [List0|List1|List2|List3|List4|List5|List6] ... [-PeerChannel-]
peerBulk -peer1,peer2,...- [set|unset]
raw data ...
regBulk -list-:-peer- -addr1:data1- -addr2:data2- ...
regSet [prep|exec] -regName- -value- ... [-peerChannel-]
reset
sign [on|off]
teamCall
templateDel tmplt
unpair
virtual -noButtons-
mach mal ein set xxx getConfig
Läuft kurz an. Dann kommt wieder Timeout:registerRead
was hast Du bei clear zur Auswahl?
Unter clear: readings, rssi, msgEvents, unknownDev
naja könntest Du alles mal machen, also rssi ist egal aber die anderen 3.
Die Werte sollten ja alle neu angelegt werden. Falls der SD einen getConfig danach akzeptiert.
Gruß Otto
Habe alle drei probiert. Kein Erfolg. Habe zwischendurch auch über die komandozeile clear all abgesetzt. Da nichts half habe ich dann nochmal den hmpairforsec probiert. Und dann erhalte ich mehr Ausgaben. Zum Beispiel R-pairCentral. Zwar mit Set. Aber immerhin. Alternativpairing mit hmpairserial hat auch nichts geändert.
Zitat von: Muff Potter 24 am 06 Oktober 2016, 23:10:47
Habe alle drei probiert. Kein Erfolg. Habe zwischendurch auch über die komandozeile clear all abgesetzt. Da nichts half habe ich dann nochmal den hmpairforsec probiert. Und dann erhalte ich mehr Ausgaben. Zum Beispiel R-pairCentral. Zwar mit Set. Aber immerhin. Alternativpairing mit hmpairserial hat auch nichts geändert.
Aber ich denke beim drücken der Anlerntaste springt er sofort auf rot?
Das mit dem set im R-pairCentral verhält sich so:
Die Zentrale schickt dem Melder dieses set_ er muss es akzeptieren und sich zurückmelden, dass er es ausgeführt hat. Die Quittung wäre die hmId ohne set_ .
Du kannst das hmpairforsec beliebig wiederholen, vielleicht macht er es ja irgendwann.
Du kannst die messages sniffen (http://www.fhemwiki.de/wiki/Homematic_Nachrichten_sniffen) und hoffen das martin dazu was sagen kann.
Gruß Otto
Nach dem ausführen von hmpairforsec habe ich mehrmals die Anlerntaste gedrückt. Die Diode blieb rot. Trotzdem wurde mir später die serial mit set angezeigt.
Wie soll ich beim schnüffeln vorgehen. Die Daten eintragen und dann getconfig ? Oder soll ich einen anderen befehl absetzen ?
Viele Grüße
Ich habe nun sämtliche RM gelöscht und die ganze Prozedur von vorne durchlaufen. Jetzt geht es.
Vielen Dank für die Hilfe
Muff
Zitat von: Muff Potter 24 am 08 Oktober 2016, 14:33:10
Ich habe nun sämtliche RM gelöscht und die ganze Prozedur von vorne durchlaufen. Jetzt geht es.
Vielen Dank für die Hilfe
Muff
Zumindest ein Erfolg, obwohl es aufreibend war ;)
Hast Du das peering der RMs auch gelöscht? Oder bloß das pairing mit FHEM neu gemacht?
Gruß Otto
Es wurden alle 10 Rauchmelder auf Werkreset gesetzt. Dann untereinander angelernt. Anschließend an FHEM angelernt und mit dem virt. Teamleader verknüpft. Bin jetzt dabei ihnen das Mailen beizubringen. Da könnte ich noch Hilfe brauchen.
Viele Grüße
Muff
Hi,
maile tue ich mit DebianMail. Ich mache für die RM aber derzeit nur Batterieüberwachung.
Gruß Otto
DebianMail habe ich eingerichtet. Der virt. Teamlead soll nun das mailen übernehmen. In der mail soll zu erkennen sein welcher Melder warum ausgelöst hat. Definiert habe ich "RauchmelderAlarm" "RauchmelderNAlarm" "RauchmelderBatterie" "RauchmelderNBatterie" "RauchmelderOffline" und "RauchmelderNOffline".
Leider komme ich meist erst Abends dazu mich um FHEM zu kümmern. Kann dann aber Aufgrund der Nachtruhe nicht mehr testen. Hättest du evtl. ein paar Beispiele wie dein Notify aussieht. Dann wäre für mich Neuling vieles leichter....
Viele Grüße
Muff
Moin,
das ist ziemlich eins zu eins aus dem Wiki, für alle Batterien im System
define nty_batterie notify .*:[Bb]attery:.* { if ($EVENT !~ m/ok/) {DebianMail('name@domain.de','FHEM Batteriewarnung',$NAME.': '.$EVENT)};;}
Gruß Otto
Ich hatte es nach einer älteren C´T Ausgabe so konfiguriert:
EG_Flur_RM.:smoke-Alarm_.* { system ("/usr/local/bmz/bin/set_status $NAME alarm") }{
DebianMail('BMA@meinemail.de','Alarm BMA','Alarm BMA Rauchmelder');
Log 3, "RauchmelderAlarm";
und nun so ersetzt:.*:smoke-Alarm:.* { if ($EVENT !~ m/ok/) {DebianMail('bma@meinemail.de','FHEM Feueralarm',$NAME.': '.$EVENT)};}
muss ich bei dem von dir genannten notify auch jedesmal eine "Alarmaufhebung" setzen oder passiert das bei Verwendung von event anstatt status automatisch.
Gibt es eine Möglichkeit die gesetzten notify zu testen. Also eine Art "Probealarm".
Wir haben uns missverstanden, mein notify ist nur für den Batteriezustand - allgemein für alle Geräte! Hat nichts speziell mit dem Rauchmelder zu tun, funktioniert aber auch da.
Was Du jetzt macht hast, wird nicht funktionieren. Der Test "if ($EVENT !~ m/ok/)" ist speziell für den Batteriestatus.
Schau mal bitte hier im Forum, ich habe das mit den Emails und wann Alarm und wann nicht schon oft gelesen. Da gab es einige Artikel.
Ich glaube mich zu erinnern, dass die echte Rauchmeldung nur bei Rauch kommt - aber ob man die da wirklich wissen will?
Wichtiger ist doch ob die Batterie in Ordnung ist und ob die Dinger leben - sich melden. Dafür gab es auch eine Idee mit dem Aktiondetektor (https://forum.fhem.de/index.php?topic=48174.0).
Gruß Otto
Das etwas falsch gelaufen sein muß ist mir vor wenigen Minuten auch klar geworden. Nach einem Raspi-Neustart hat es sämtliche Meldungen gegeben. Alarm - Online - Offline. Das ganze Repertoire. Meine Familie war begeistert....
Aber wenigstens funktioniert der Mailversandt.
Viele Grüße
Muff
Ich habe den virt. teamlead so eingerichtet:
Virtuellen Teamlead erzeugen: define TeamDev CUL_HM 111111
set TeamDev virtual 1
rename TeamDev_Btn1 Rauchmelder_Team_Virt
und die Rauchmelder an den teamlead so angelernt:
set Rauchmelder_Teamlead_Virt peerChan 0 Garage_Werkstatt_RM single set actor
Ich bekomme über den teamlead aber keine Verbindung zu den RM. teamcall schlägt fehl. Was mache ich falsch ?
Moin,
habe ich das nochmal überprüft und ich habe das seinerzeit genauso gemacht. Teamcall funktioniert, alle Rauchmelder melden sich mit zartem piepsen.
Was sagt hminfo?
Gruß Otto
Guten Abend. In der hm Info konnte ich folgendes finden:
peer not verified. Check that peer is set on both sides
Rauchmelder_Team_Virt p:KG_Flur_RM
wenn das peerChan richtig lief, dann muss der Teamlead alle IDs der Rauchmelder in der peerIDs haben und jeder Rauchmelder die ID des Teamlead in der peerIDs. Die ID ist jeweils erweitert um 01 - quasi Channel 01.
Wenn nicht, dann hat irgendetwas nicht geklappt.
Gruß Otto
In der peerliste des teamlead werden die RM angezeigt. In der peerliste des jeweiligen RM taucht der teamlead aber nicht auf. Ist peerchannel 0 den richtig ? So sieht List KG_Flur_RM aus:
Save config
CUL_HM
Unsorted
icoEverything Everything
Logfile
Commandref
Remote doc
Edit files
Select style
Event monitor
restart
update
updatecheck
reloadMyUtils
Internals:
CCD_MSGCNT 36
CCD_RAWMSG A1235A01032D8A7F112340132D8A70100000000::-62.5:CCD
CCD_RSSI -62.5
CCD_TIME 2016-10-15 22:22:31
DEF 32D8A7
IODev CCD
LASTInputDev CCD
MSGCNT 36
NAME KG_Flur_RM
NOTIFYDEV global
NR 72
NTFY_ORDER 50-KG_Flur_RM
STATE off
TESTNR 2
TYPE CUL_HM
lastMsg No:35 - t:10 s:32D8A7 d:F11234 0132D8A70100000000
peerList self01,
protCmdDel 4
protLastRcv 2016-10-15 22:22:31
protNack 4 last_at:2016-10-14 23:59:06
protSnd 50 last_at:2016-10-15 22:22:31
protState CMDs_done
rssi_CCD avg:-74 min:-93 max:-63 lst:-73 cnt:10
rssi_at_CCD avg:-72.36 min:-95 max:-53 lst:-62.5 cnt:36
sdTeam sdLead
Readings:
2016-10-15 22:21:45 Activity alive
2016-10-15 22:21:42 CommandAccepted yes
2016-10-15 22:21:45 D-firmware 1.1
2016-10-15 22:21:45 D-serialNr LTK0105739
2016-10-15 22:22:31 PairedTo 0xF11234
2016-10-15 22:22:31 R-pairCentral 0xF11234
2016-10-15 22:22:30 RegL_00. 02:01 0A:F1 0B:12 0C:34 00:00
2016-10-08 13:39:18 SDteam add_HM_32CAC0
2016-10-15 00:29:10 battery ok
2016-10-15 00:29:10 level 1
2016-10-15 22:22:31 peerList self01,
2016-10-15 00:29:10 recentStateType info
2016-10-08 13:39:16 sabotageAttackId_ErrIoId_32CAC0 cnt:1
2016-10-08 13:38:57 sabotageAttackId_ErrIoId_32DA9B cnt:8
2016-10-15 00:29:10 state off
2016-10-15 00:29:10 teamCall from TeamDev:5
Helper:
HM_CMDNR 53
cSnd 01F1123432D8A700040000000000,01F1123432D8A70103
fkt sdLead1
mId 0042
peerIDsRaw ,32D8A701,00000000
rxType 2
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +32D8A7,00,00,00
nextSend 1476562951.29986
prefIO
rxt 0
vccu
p:
32D8A7
00
00
00
Mrssi:
mNo 35
Io:
CCD -60.5
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rpt:
IO CCD
flg A
ts 1476562951.20931
ack:
HASH(0x1881530)
358002F1123432D8A700
Rssi:
Ccd:
avg -74
cnt 10
lst -73
max -63
min -93
At_ccd:
avg -72.3611111111111
cnt 36
lst -62.5
max -53
min -95
Shadowreg:
Tmpl:
Attributes:
IODev CCD
actCycle 099:00
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.1
model HM-SEC-SD
msgRepeat 1
peerIDs 00000000,32D8A701,
room CUL_HM
serialNr LTK0105739
subType smokeDetector
webCmd statusRequest
und so der Teamlead:
Internals:
CFGFN
DEF 11111101
NAME Rauchmelder_Team_Virt
NOTIFYDEV global
NR 480
STATE off
TESTNR 5
TYPE CUL_HM
chanNo 01
device TeamDev
peerList KG_Flur_RM,
sdTeam sdLead
Readings:
2016-10-14 23:59:05 peerList KG_Flur_RM,
2016-10-14 23:59:05 state off
2016-10-15 00:29:10 teamCall from TeamDev:5
Helper:
fkt sdLead1
Expert:
def 1
det 0
raw 1
tpl 0
Role:
chn 1
vrt 1
Tmpl:
Attributes:
model virtual_1
peerIDs 32D8A701,
webCmd press short:press long
Ich habe bei mir damals folgendes gemacht:
define TeamDev1 CUL_HM 5D0001
set TeamDev1 virtual 1
rename TeamDev1_Btn1 Rauchmelder_Team
set Rauchmelder_Team peerChan 0 HM_297D06 single set
set Rauchmelder_Team peerChan 0 HM_297D08 single set
set Rauchmelder_Team peerChan 0 HM_297DBC single set
Was mir bei Dir auffällt:
Zitat2016-10-15 22:22:31 peerList self01,
Der ist mit sich selbst gepeert. Ich denke das ist verkehrt, damit ist er sein Teamlead. Wahrscheinlich akzeptiert er kein weiteres peering.
Gruß Otto
Welcher Wert ist bei define Teamdev einzutragen. In der Anleitung steht 111111. Bei dir ist es 5D0001. Gibt es eine Möglichkeit die HMID auszulesen ?
In der Anleitung steht könnte ;D und ich kopiere nicht immer alles einfach ;)
Die ID für den virtuellen Teamlead bestimmt jeder selbst, es darf keine HMID sein die schon existiert. Die HMID des Gerätes ist ja quasi die einmalige Adresse für den Kommunikation.
Du hast schon alles richtig gemacht, aber Dein KG_Flur_RM mit der HMID 32D8A7 (Die steht in der DEF) ist mit sich selbst gepeert.
Ich nehme an, das war Dein erster Versuch und Du hast das nicht rückgängig gemacht.
Ich denke Du musst das peering löschen. set KG_Flur_RM peerBulk 32D8A701 unset
Und dann das peering mit dem virtuellen Teamlead wiederholen.set Rauchmelder_Teamlead_Virt peerChan 0 KG_Flur_RM single set
Gruß Otto
Habs vorher falsch gemacht, weil ich dachte, wenn ich den Teamlead lösche, lösche ich auch die Zuweisung.
Habe nun alle RM vom Teamlead entpeert.
set Rauchmelder_Teamlead_Virt peerChan 0 Rauchmelder_Flur single unset actor
Der Befehl:
set KG_Flur_RM peerBulk 32D8A701 unset
schlug fehl. Vermutlich stimmt die HMid nicht. Alle RM mit List durchsucht. Ich finde sie nicht. Kann an die ID über einen Befehl auslesen ?
Und set KG_Flur_RM peerBulk self01 unset?
Wie gesagt, er ist mit sich selbst gepeert. Und die ID stand im list.
Gruß Otto
Ich habe nun für KG_Flur_RM clear all und anschl. get config ausgeführt. Dann war endlich self01 verschwunden. Wenn ich dann KG_Flur_RM erneut peere steht in der peerliste des teamlead self01,KG_Flur_RM. In der peerliste von KG_Flur_RM taucht der teamlead dann aber nicht auf. Muß der self01 beim teamlead gelöscht werden ?
Der virtuelle Teamlead ist nicht mit sich selbst gepeert.
Im virtuellen Teamlead müssen nur alle RMs stehen, in den RMs steht jeweils der virtuelle Teamlead.
Gruß Otto
Durch einen Defekt an der SD-Karte war ich gezwungen meine letzte Sicherung vom Januar wieder auf den neuesten Stand zu bringen. Nachdem ich nun fast alles neu gemacht habe inkl. pairen, sind noch diese Fehler übrig geblieben.
configCheck done:
PairedTo mismatch to IODev
HM_32CAC0 paired:0xF11234 IO attr: -.
HM_32CAC2 paired:0xF11234 IO attr: -.
HM_32CD58 paired:0xF11234 IO attr: -.
HM_32CFEE paired:0xF11234 IO attr: -.
HM_32D02F paired:0xF11234 IO attr: -.
HM_32D032 paired:0xF11234 IO attr: -.
HM_32D4E5 paired:0xF11234 IO attr: -.
HM_32D8A7 paired:0xF11234 IO attr: -.
HM_32DA9B paired:0xF11234 IO attr: -.
HM_52DA84 paired:0xF11234 IO attr: -.
Ws kann ich tun ?
du hast diesen Devices noch nie etwas geschickt? Nicht einmal ein ACK? Das Attribut setzt sich automatisch. Man kann es setzen - besser aber man stellt eine vccu ein.
Das attr sollte sich dann setzen, man speichert einmal und dann ist es drin.
Ich habe den RM schon mehrere Komandos geschickt. Alle 10 RM haben den Status "alive". FHEM läuft auf einem Raspi mit Busware - Platine. Alle RM wurden untereinander gepairt und dann an FHEM angelernt. Mittlerweile habe ich das Prozedere 3 mal durchlaufen. Werkreset - alle untereinander anlernen - umbenennen und an FHEM anlernen. Die Zuordnung zu einem virt. Teamleader zwecks EMailversand schlägt fehl. Der betreffende RM taucht in der peerlist des virt. teamlead auf aber der virt. Teamlead nicht in der peerliste des RM. In der peerliste jedes RM ist der Rauchmelder EG_Wohn_RM eingetragen. Er ist auch als SdLead gekennzeichnet. Aber in der peerliste steht: self01 welches laut Otto falsch ist. Ich bekomme es aber nicht gelöscht. Ist es evtl. sinnvoll FHEM beim ersten untereinander anlernen abzuschalten ?
CCD_MSGCNT
6
CCD_RAWMSG
A0B43944032CAC052DA848001::-91.5:CCD
CCD_RSSI
-91.5
CCD_TIME
2016-11-12 14:29:05
DEF
32CAC0
IODev
CCD
LASTInputDev
CCD
MSGCNT
6
NAME
EG_Wohn_RM
NOTIFYDEV
global
NR
95
NTFY_ORDER
50-EG_Wohn_RM
STATE
off
TESTNR
1
TYPE
CUL_HM
lastMsg
No:43 - t:40 s:32CAC0 d:52DA84 8001
peerList
self01
protLastRcv
2016-11-12 14:29:04
rssi_at_CCD
avg:-87.25 min:-91.5 max:-82.5 lst:-91.5 cnt:6
sdTeam
sdLead
Readings
Activity
alive
2016-11-11 22:50:46
D-firmware
1.1
2016-11-11 22:50:46
D-serialNr
LTK0110268
2016-11-11 22:50:46
PairedTo
0xF11234
2016-11-11 22:24:36
R-pairCentral
0xF11234
2016-11-11 22:24:36
RegL_00.
02:01 0A:F1 0B:12 0C:34 00:00
2016-11-11 22:24:35
eventNo
04
2016-11-11 22:36:57
level
1
2016-11-11 22:36:57
peerList
self01,
2016-11-11 22:50:46
recentAlarm
DG_Dachboden_RM
2016-11-11 22:36:22
smoke_detect
none
2016-11-11 22:36:57
state
off
2016-11-11 22:36:57
teamCall
from DG_Dachboden_RM:1
2016-11-12 14:29:04
trigLast
EG_Wohn_RM:no alarm
2016-11-11 22:36:14
trig_EG_Wohn_RM
No alarm_3
2016-11-11 22:36:14
trigger
Short_1
2016-11-12 14:29:04
trigger_cnt
1
Zitat von: Muff Potter 24 am 12 November 2016, 14:38:29
Alle RM wurden untereinander gepairt und dann an FHEM angelernt.
Was genau meinst Du damit?
Ich dachte wir hatten das seinerzeit alles exakt durchgespielt?
Warum hast Du die RMs nicht so gelassen? Mit denen war doch alles gut? Du hättest doch nur den virtuellen Teamlead wieder einrichten müssen? Die RMs hätten sich doch wahrscheinlich wieder allein eingetragen? IIch weiß jetzt nicht sofort genau wie, aber bei jedem anderen HM Gerät drückt man einmal die Anlerntaste und Autocreate erzeugt den Eintrag neu. Da die HMId stimmt bleibt damit auch das Pairing bestehen und man bekommt mit einem getConfig alles wieder.
Gruß Otto
Ich hätte alles so gelassen. Leider ist mir - wie ich vorher schrieb - die SD -Karte kaputt gegangen. Und die Sicherung von Januar kannte nicht einmal sendmail. Also war neu machen angesagt.
Zitat von: Muff Potter 24 am 12 November 2016, 18:16:41
Ich hätte alles so gelassen. Leider ist mir - wie ich vorher schrieb - die SD -Karte kaputt gegangen. Und die Sicherung von Januar kannte nicht einmal sendmail. Also war neu machen angesagt.
Aber nochmal: peers stehen im Device. Die ID der Zentrale (pairing) steht im Device. Deine ID vom Teamlead steht hier im Thread. Deine HMId steht hier im Thread.
Alles nichts was mit der SD Card kaputt gegangen sein kann. ;D Du hättest den RMs keine Gewalt antun müssen!
Gruß Otto
Auf der SD-Karte ist das Betriebsystem für den Raspberry Pi sowie die FHEM Installation. Die Sicherungskopie war von Januar ohne Debianmail, Sendemail usw.
Ich habe alles neu machen müssen. Und nun bin ich gerade zum 4. Mal dabei die RM anzulernen. Diesmal ohne vorheriges peering. Ich möchte versuchen das später mit devicepair nachzuholen. Alles was ich im Moment erhalte ist:
configCheck done:
peering strange - likely not suitable
HM_32CAC0 not peered!! add SD to any team !!
HM_32CD58 not peered!! add SD to any team !!
HM_32CFEE not peered!! add SD to any team !!
HM_32D02F not peered!! add SD to any team !!
HM_32D032 not peered!! add SD to any team !!
HM_52DA84 not peered!! add SD to any team !!
PairedTo mismatch to IODev
HM_32CAC0 paired:0xF11234 IO attr: -.
HM_32CD58 paired:0xF11234 IO attr: -.
HM_32CFEE paired:0xF11234 IO attr: -.
HM_32D02F paired:0xF11234 IO attr: -.
HM_32D032 paired:0xF11234 IO attr: -.
HM_52DA84 paired:0xF11234 IO attr: -.
Naja aber beim alles neu machen, muss man ja nicht zwangsläufig noch mehr kaputt machen. Egal passiert...
Gib mal ein list HM_32CAC0 als Beispiel.
Gruß Otto
Es war umgekehrt. Erst ist die Karte kaputt gegangen und dann musste ich alles Neu machen.
Internals:
CCD_MSGCNT 9
CCD_RAWMSG A0D00A41032CAC0F1123406010000::-95.5:CCD
CCD_RSSI -95.5
CCD_TIME 2016-11-12 18:03:11
CFGFN
DEF 32CAC0
IODev CCD
LASTInputDev CCD
MSGCNT 9
NAME HM_32CAC0
NOTIFYDEV global
NR 119
STATE off
TYPE CUL_HM
lastMsg No:00 - t:10 s:32CAC0 d:F11234 06010000
protCmdDel 3
protLastRcv 2016-11-12 18:03:11
protResnd 2 last_at:2016-11-12 17:56:59
protResndFail 2 last_at:2016-11-12 17:57:04
protSnd 12 last_at:2016-11-12 18:03:11
protState CMDs_done
rssi_CCD avg:-84 min:-84 max:-84 lst:-84 cnt:1
rssi_at_CCD avg:-88.72 min:-96 max:-84.5 lst:-95.5 cnt:9
Readings:
2016-11-12 17:57:31 Activity alive
2016-11-12 17:56:26 CommandAccepted yes
2016-11-12 17:57:31 D-firmware 1.1
2016-11-12 17:57:31 D-serialNr LTK0110268
2016-11-12 17:57:47 PairedTo 0xF11234
2016-11-12 17:57:47 R-pairCentral 0xF11234
2016-11-12 17:57:47 RegL_00. 02:01 0A:F1 0B:12 0C:34 00:00
2016-11-12 18:03:11 battery ok
2016-11-12 18:03:11 level 0
2016-11-12 18:03:11 powerOn 2016-11-12 18:03:11
2016-11-12 18:03:11 recentStateType info
2016-11-12 18:03:11 state off
Helper:
HM_CMDNR 0
PONtest 0
cSnd 01F1123432CAC00103,01F1123432CAC0010E
mId 0042
peerIDsRaw ,00000000
rxType 2
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +32CAC0,00,00,00
nextSend 1478970191.42309
prefIO
rxt 0
vccu
p:
32CAC0
00
00
00
Mrssi:
mNo 00
Io:
CCD -93.5
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf 00
qReqStat 00
Role:
chn 1
dev 1
Rpt:
IO CCD
flg A
ts 1478970191.32879
ack:
HASH(0x2887158)
008002F1123432CAC000
Rssi:
Ccd:
avg -84
cnt 1
lst -84
max -84
min -84
At_ccd:
avg -88.7222222222222
cnt 9
lst -95.5
max -84.5
min -96
Shadowreg:
Tmpl:
Attributes:
IODev CCD
actCycle 099:00
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.1
model HM-SEC-SD
msgRepeat 1
peerIDs 00000000,
room CUL_HM
serialNr LTK0110268
subType smokeDetector
webCmd statusRequest
Du willst mich nicht verstehen... Vielleicht drücke ich mich ja komisch aus.
Das list sieht eigentlich gut aus, er hat das attr IOgrp nicht, eigentlich wird das automatisch angelegt. Warum es so ist kann ich nicht sagen. Ob es wirklich schlimm ist auch nicht. Mann kann es auch manuell setzen.
Ich sehe immer noch kein Problem. Lässt der Teamlead sich nicht anlegen und peeren? Oder hast Du es einfach noch nicht gemacht?
Gruß Otto
Bevor die Karte defekt war hatte ich schon das Problem das die RM im virt. teamlead angezeigt wurden, der virt. Teamlead in der peerlist des RM aber nicht. Es war die gleiche Meldung: PairedTo mismatch to IODev wie jetzt auch. Welchen Befehl soll ich eingeben um die attr manuel zuzuweisen ?
Ich hatte gedacht wir waren damals bis zum glücklichen Ende gekommen :'(
Hast Du eine VCCU?
Wenn nicht!!! Dann mach mal:
attr HM_32CAC0 IOgrp CCD
Das peeren vom Teamlead geht nicht?
set Rauchmelder_Teamlead_Virt peerChan 0 KG_Flur_RM single set
Gruß Otto
Das attr HM_32CAC0 IOgrp CCD hat keine Auswirkungen gezeigt. Das zuordnen zum virt Teamlead funktioniert nur einseitig. Ich habe auch ein Feld CUL_HM. Darin sind alle 10 RM aufgeführt. Müssen die RM vielleicht erst aus der Gruppe entfernt werden ? Ich erhalte diese Fehlermeldung:
IOgrp: CCU not found
HM_32CAC0 ->CCD
Zitat von: Muff Potter 24 am 12 November 2016, 19:28:00
Ich habe auch ein Feld CUL_HM. Darin sind alle 10 RM aufgeführt. Müssen die RM vielleicht erst aus der Gruppe entfernt werden ?
Was meinst Du mit Feld und Gruppe? kannst Du ein list bieten?
Der HM_32CAC0 ist doch noch gar nicht gepeert? Zumindest nicht in deinem list.
Gibst Du bitte ein list von deinem Teamlead?
Gruß Otto
In einem anderen thread diese Forums stand: RM nicht erst untereinander peeren und dann FHEM bekannt machen - sondern erst mit FHEM pairen und dann über devicepair die RM untereinander peeren.Einen teamlead habe ich noch nicht. Ich versuche gerade den Befehl für devicepair zu finden und umzusetezn.
So sieht meine linke Seite aus:
Save config
CUL_HM
Unsorted
Wettervorhersage
icoEverything Everything
Logfile
Commandref
Remote doc
Edit files
Select style
Event monitor
restart
update
updatecheck
reloadMyUtils
Mach es so wie im Wiki http://www.fhemwiki.de/wiki/HM-SEC-SD_Rauchmelder
... oder lass es.
Tut mir leid,, ich bin raus...
Gruß Otto
Trotzdem Danke für deine Hilfe. Ich habe nur versucht in monatelanger Kleinarbeit 10 Rauchmelder mittels FHEM dazu zu überreden mir eine Email zu schicken. Ich sehe das sich die Moderatoren hier alle erdenkliche Mühe geben anderen zu helfen. Aber klare Anweisungen finden sich nicht. Der eine schreibt RM erst untereinander anmelden, dann mit FHEM pairen - der nächste sagt es genau andersherum. Ich werde das Projekt und damit FHEM wohl einstellen müssen.
Hier helfen Dir nicht Moderatoren sondern FHEM Benutzer die es irgendwie wissen. Und wie immer in der Welt: viele Wege können nach Rom führen. Manches ist heute richtig und morgen nicht mehr. Und was vielleicht gestern zum Ziel geführt hat muss heute nicht mehr funktionieren. So ist es: Die Welt kann schlecht sein :-X
FHEM ist gut dokumentiert:
- commandref
- Wiki
Man muss sich nicht daran halten was da geschrieben steht, aber erstmal macht es Sinn.
Viel Erfolg
Otto
Ich habe versucht jedes Wiki und viele Anleitungen hier zu verstehen. Ich habe viele (Irr)wege verfolgt. Es gibt an keiner Stelle eine durchführbare Anleitung A-Z.
In der comandref sind einzelne befehle erklärt. Im RauchmelderWiki finde ich Anweisungen über einen Teamlead. Und einiges andere. Wenn so etwas auftaucht
configCheck done:
peering strange - likely not suitable
HM_32CAC0 not peered!! add SD to any team !!
HM_32CAC2 not peered!! add SD to any team !!
HM_32CD58 not peered!! add SD to any team !!
HM_32CFEE not peered!! add SD to any team !!
HM_32D02F not peered!! add SD to any team !!
HM_32D032 not peered!! add SD to any team !!
HM_32D4E5 not peered!! add SD to any team !!
HM_32D8A7 not peered!! add SD to any team !!
HM_32DA9B not peered!! add SD to any team !!
HM_52DA84 not peered!! add SD to any team !!
PairedTo mismatch to IODev
HM_32CAC0 paired:0xF11234 IO attr: -.
HM_32CAC2 paired:0xF11234 IO attr: -.
HM_32CD58 paired:0xF11234 IO attr: -.
HM_32CFEE paired:0xF11234 IO attr: -.
HM_32D02F paired:0xF11234 IO attr: -.
HM_32D032 paired:0xF11234 IO attr: -.
HM_32D4E5 paired:0xF11234 IO attr: -.
HM_32D8A7 paired:0xF11234 IO attr: -.
HM_32DA9B paired:0xF11234 IO attr: -.
HM_52DA84 paired:0xF11234 IO attr: -.
IOgrp: CCU not found
HM_32CAC0 ->CCD
findet sich nichts. Und auch ankeiner anderen Stelle. So macht FHEM keinen Spaß....
nun, wenn du teamlead verstanden hast solltest du
add SD to any team
so weit verstehen, dass dein Device scheinbar nicht zu einem Team gehört.
Nun ist die Frage, was du willt. Sollen SDs gruppiert werden oder sind es alle Einzelkämpfer?
Im ersten Fall solltest du einen TeamLead einrichten - nach Gusto.
Im zweiten Fall solltest du den SD mit sich selbst peeren und ein Ein-SD-Team je SD einrichten.
Aber das sagt der Kommentar: Der SD ist in keinem Team - Das kann behoben werden wenn man ihn in ein Team schiebt - nicht klar?
Was das not peered bedeutet ist mir klar. Nur für:PairedTo mismatch to IODev hätte ich gerne ein paar Infos. Ziel ist es 10 Rauchmelder so miteinander zu vernetzen das sie bei Stromausfall ohne FHEM funktionieren und mit Strom über FHEM eine Email bei Rauch, leerer Batterie und Ausfall des RM verschicken.
Ich habe bei meinen ersten Versuchen die RM untereinander angelernt und dann mit FHEM gepairt. Nach einrichten des virt. Teamlead und zuweisen der RM waren alle 10 RM in der peerliste des virt. Teamlead. Der virt. Teamlead tauchte aber in der peerliste der RM nicht auf. Und das ist offenbar falsch.
Bei meinem 4. Versuch habe ich die RM laut einem älteren Beitrag erst mit FHEM gepairt und wollte sie dann mit devicepair autark machen. Den Befehl devicepair gibt es aber wohl nicht mehr. Der einzige Vorteil den das nicht vorher untereinander anlernen hatte war, das die RM sowohl beim virt teamlead als auch bei den RM in der peerliste auftauchte. Der Fehler mit IODev war allerdings auch da vorhanden.
Um die notifys einzurichten habe ich mir die die Befehle für smoke-alarm, missing, off usw. erst zusammen suchen müssen. Als ich gestern mal den Alarm getestet habe kam im Ereignissfenster smoke_detect und nicht smoke-Alarm. Eine Mail wurde auch nicht verschickt.
Und wenn ich es den wirklich ans laufen bekomme und im nächsten Jahr einen RM ersetzen möchte kann ich das ganze Prozedere wieder durchlaufen. Nachträglich einbinden ist nicht möglich.
Ich muß mich bei Otto123 entschuldigen. Aber wenn man monatelang an so einer Aufgabe sitzt ist das einfach frustrierend....
HMInfo prüft, ob das sendende IO auch die HMId hat zu welcher das Device gepairt ist.
Schaue nach
- welches IODev ist beim SD in Internals
und im Attr eingetragen?
- Welche HMId ist beim IO eingetragen das beim SD als IO eingetragen ist?
da passt etwas nicht.
In deinem Fall wird entweder das IO nicht gefunden oder das IO hat die HMId nicht eingetragen.
Nach einrichten des virt. Teamlead und zuweisen der RM waren alle 10 RM in der peerliste des virt. Teamlead. Der virt. Teamlead tauchte aber in der peerliste der RM nicht auf. Und das ist offenbar falsch.Den Ablauf verstehen! Wenn du ein peerChan machst wird mit 2 Devices geredet (das ist das einzige Kommando, welches auf 2 Devices wirkt).
Faktisch wird ein peering immer "unidirektional" eingetragen. Du sagst dem Button das sein Peer der Aktor ist. Davon weiss der Aktor nichts. Dann sagst du dem Aktor, dass der Button sein peer ist. Davon bekommt der Button nichts mit.
Bei SDTeam und SD ist es ebenso.
Dass der SDTeam alle SDs gespeichert hat ist logisch. Das hat NICHTS damit zu tun, ob es die SDs auch begriffen haben. Da du die SDs allerdings schon geteamt hast kannst du sie nicht mehr mit dem SDTeam (Virtuell) peeren (was dem SDTeam wie gesagt wurscht ist).
Grund: Ein SD kann nur in einem Team sein. Ist er in einem Team wird er ein weiteres peeren verweigern. Du musst ihn erst aus dem ersten Team nehmen.
Grundregel: Nach einer Konfiguration solltest du prüfen, dass auch alle Kommandos übertragen sind. Es ist auch anders möglich, allerdings empfehle ich hier HMInfo - macht das Leben einfacher.
1)Definieren 2) alte Meldungen löschen 3) konfiguration starten 4) meldungen prüfen:
define hm HMInfo
set hm clearG msgEvents
<Konfigurieren>
get hm protoEventswenn es probleme gegeben hat must du prüfen.
um deine SDs mit einem virtTeamLead zu peeren solltest du
- getConfig der/des SD
- peer ermitteln - steht im Attribut
- set sd peerBulk <PeerID> unset
- ggf ein getConfig - peerId sollte "leer" sein, also 00000000
- mit dem TeamLead peeren
Danke für die ausführliche Anleitung. Ich habe sie mir mehrmals durchgelesen um die durchzuführenden Schritte genau zu verstehen. Eine sache ist mir allerdings noch nicht klar. Wenn ich die 10 RM vorher anlerne steht bei mir unter peerIDs 00000000,32CAC001. Der RM HM_32CAC0 ist unter sdTeam als sdLead gekennzeichnet. Wenn ich nun mit dem unset Befehl die RM vom sdLead löse ist doch das vorherige anlernen wieder gelöscht und ich werde im Brandfall bei Ausfall der BMA nicht mehr gewarnt. Oder bleibt das ursprüngliche anlernen erhalten ?
- welches IODev ist beim SD in Internals und im Attr eingetragen? Bei beiden CCD
- Welche HMId ist beim IO eingetragen das beim SD als IO eingetragen ist? Beim RM finde ich HM_CMDNR 1 und mId 0042
und mit list CCD:
Internals:
CCD_MSGCNT 3
CCD_TIME 2016-11-16 19:31:51
CMDS mCFiAZGMRTVWXefltux
Clients :CUL_HM:HMS:CUL_IR:STACKABLE_CC:
DEF /dev/ttyAMA0@38400 1234
DeviceName /dev/ttyAMA0@38400
FD 11
FHTID 1234
NAME CCD
NR 43
NR_CMD_LAST_H 5
PARTIAL
RAWMSG A0D00A41032CAC2F1123406010000F9
RSSI -77.5
STATE Initialized
TYPE CUL
VERSION V 1.57 CSM868
initString X21
Ar
Matchlist:
1:CUL_HM ^A....................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
Readings:
2016-11-15 22:35:06 cmds m C F i A Z G M R T V W X e f l t u x
2016-11-16 19:31:51 state Initialized
2016-11-16 20:56:02 version V 1.57 CSM868
XMIT_TIME:
1479321111.31277
1479324353.33343
1479324358.04911
1479324390.25388
1479324393.41915
Helper:
32cac2:
QUEUE:
32cfee:
QUEUE:
32d02f:
QUEUE:
Attributes:
rfmode HomeMatic
Du hast keine HMId eingetragen (attr ccd hmId fehlt). Damit wird F1+FHTID genommen (habe ich vor wenigen Minuten gelernt 8) )
Also bei dir F11234.
Ob hmInfo damit klar kommt weiß ich nicht.
Gruß Otto
Das war ein SUPERTIP.... :D
hminfo meldet zum erstenmal keine Fehler. Das hatte ich noch nie. Vielen Dank dafür. Endlich geht was vorran.
Wie könnte ich nun weiter vorgehen:
Wen ich die Anleitung von Martin richtig verstehe und das peering löse, bekomme ich bei Ausfall von FHEM keinen Feueralarm.
Das möchte ich nicht.
Oder soll ich es wie in der CT´beschrieben mit mehreren notify für jeden einzelnen RM versuchen:
define RauchmelderAlarm notify EG_Flur_RM.:smoke-Alarm_.* { system ("/usr/local/bmz/bin/set_status $NAME alarm") }
define RauchmelderBatterie notify EG_Flur_RM.:[Bb]attery:.[^o][^k].* { system ("/usr/local/bmz/bin/set_status $NAME lowbatt") }
define RauchmelderOffline notify EG_Flur_RM.:MISSING.* { system ("/usr/local/bmz/bin/set_status $NAME offline") }
define RauchmelderNAlarm notify EG_Flur_RM.:off.* { system ("/usr/local/bmz/bin/del_status $NAME alarm") }
define RauchmelderNBatterie notify EG_Flur_RM.:[Bb]attery:.ok.* { system ("/usr/local/bmz/bin/del_status $NAME lowbatt") }
define RauchmelderNOffline notify EG_.*_RM.:alive.* { system ("/usr/local/bmz/bin/del_status $NAME offline") }
genau genommen melden Rauchmelder kein Feuer sondern Rauch. Das ist unabhängig von FHEM - immer! Er gibt Signal bei Rauch, ansonsten ist er kaputt und nicht FHEM.
Du hast aktuell die Melder untereinander gepeert? Dann melden die alle Alarm wenn einer Rauch ermittelt. Den Status melden alle Melder an FHEM, eventuell ist die Meldung unterschiedlich, das weiß ich nicht genau. Immerhin hat ja einer Rauch und die anderen machen nur mit. Es würde ein notify reichen um ein Mail zu schicken, wie sinnvoll das ist? Man kann bei allen mit einem notify den Batteriestatus abfragen. Wie das geht steht im Wiki.
Der virtuelle Teamlead hat folgenden Vorteil, steht im Wiki!
ZitatNutzt man nur einen einzelnen SD, kann/sollte man diesen mit sich selbst teamen (peerChan). In allen andere Fällen braucht man einen TeamLead um eine team-ID zu erhalten. Man kann hierzu einen der SDs nutzen. Wird dieser einmal ausgewechselt, hat man allerdings seine team-ID verloren.
Wenn man mit Zentrale (FHEM) arbeitet, gibt es eigentlich keinen vernünftigen Grund (ausser 1-SD-Teams), einen der SDs als lead zu nutzen. Man kann genauso gut einen virtuellen Aktor bauen und diesen zum Lead machen. Das ergibt eine sauberere Struktur.
Also was willst Du? Warum betreibst Du den ganzen Aufwand? Jetzt sag ich es nochmal anders: Lass es so, alles ist gut. Oder wenn Du willst mach es so wie im Wiki.
Gruß Otto
Was ich möchte habe ich schon mehrmals geschrieben:
Ich habe meine 10 RM gepeert damit ich z.B. bei einem Brand in der Garage und gleichzeitigem Stromausfall auch ohne FHEM gewarnt werde.
Ich möchte/ habe die RM mit FHEM gepairt um die Systemzustände der RM überwachen zu können und eine Email bei Änderungen (Rauch, Melder nicht erreichbar usw.) zu bekommen. Bei Abwesenheit und Feueralarm - Email kann ich meine im Haus verbauten Kameras abfragen und sehen ob es wirklich brennt.
Wenn ich das Wiki richtig verstanden habe brauche ich den virt. teamlead um eine mail verschicken zu können. Den virt. Teamlead kann ich aber nur einrichten, wenn ich das zuvor durchgeführte peering löse. Und ab hier beisst sich die Katze in den Schwanz. Ich kann das eine nicht tun ohne das andere zu lassen. Und da wollte ich nur wissen ob ich das richtig verstanden habe. Das ist alles....
Nichts für ungut....
Muff
Du liest immer nicht richtig, oder hast eine Art negativen Wunschlesemodus aktiv:
Zitat Wiki
ZitatAlarme
Meldet ein SD einen Alarm, wird dieser in dem SD und im TeamLead angezeigt.
Nutzt man HMinfo, wird ein Rauchalarm auch hier als "Error" gemeldet. In HMinfo wird dies für alle SD-teams im System gemacht.
Nützliche Notifies
Codefragmente, die man einsetzen kann. Ggf. muss man etwas anpassen, zumindest können sie als Anregung nützlich sein.
Bei Alarm email schicken und Licht im Flur anschalten
Wo steht da was vom
virtuellen Teamlead? Da steht nur Teamlead - und Du hast doch Einen! Frage den ab und alles ist gut!
Baue das notify aus dem Wiki ein und erzeuge an einem x-beliebigen RM einen Rauchalarm und Du wirst sehen das es funktioniert!
Gruß Otto
Nach stundenlangem Lesen habe ich da wohl einiges durcheinander gebracht. Jetzt nochmal gelesen und so hoffe, ich auch verstanden. Danke das du mich in die richtige Richtung gebracht hast. Ich werde es in den nächsten Tagen umsetzen und mich dann nochmal melden.
Vielen dank nochmal
Muff