Hab da mal wieder ne Frage. Habe einen Rauchmelder gekauft.
CUL_HM_HM_SEC_SD. Anlernen an FHEM (FritzBox(FHEM) + CUL) hat funktioniert. alive und battery ok Meldungen werden empfangen. Leider bekomme ich aus FHEM keine "test" Kommunikation. Also die drei Kommandos test, alarmOn, alarmOff funktionieren nicht. Ein getConfig liefert ein RESPONSE TIMEOUT:RegisterRead. Ich habe mir zum Anfangen diesen einen Rauchmelder zugelegt. Also im Moment keine Gruppenbildung. Hat einer einen Tipp für mich.
Gruß Jörg
hier noch die Readings-Anzeige
Readings
Activity:
alive
2013-04-07 13:17:09
CommandAccepted
yes
2013-04-07 12:44:58
R-pairCentral
set_0xF11034
2013-04-07 12:44:57
RegL_00:
battery
ok
2013-04-07 13:28:23
state
RESPONSE TIMEOUT:PeerList
2013-04-07 13:34:42
du benutzt ein HMLAN, kein CUL - korrekt?
Ich habe kein HMLAN sondern den CUL an der FritzBox
dann sieht es schlecht aus. Der SD ist ein burst-Device. Der braucht ein aufwach-pattern um kommunizieren zu können. CUL macht das nicht, hat noch keiner eingebaut.
Lauschen geht, senden nicht
Gruss
Martin
Vielen Dank. da weiß ich jetzt Bescheid. Spart mir einige Stunden an Bastelarbeit.
Gruß Jörg
Ich habe das geliche Problem allerdings mit HMLAN. Das Pairing hat funktioniert. Ich sehe den Rauchmelder im fhem aber weder test noch alarmOn oder off geht.
Hallo Jörg,
mittlerweile kann CUL auch burst! Der SD sollte komplett bedienbar sein.
Hallo bonner,
wie ist der SD gepeert? Ist er mitglied eines Teams? an wen sendest du das Kommando? Team oder device (oder sind die gleich?)?
ggf einmal ein list des SD senden und einen mitschnitt der messages - roh.
Gruss Martin
Hi Martin,
ich habe noch kein Team eingerichtet. Ich habe mitlerweile verstanden, dass ich das machen muss aber konnte noch keinen Erfolg erzielen :'(
In welchem Logfile stehen die Rohdaten?
Viele Grüße
Bonner
Hallo Bonner,
ich überarbeite den SD gerade. Insbesondere den optionalen virtuellen TeamLeiter.
Dann kommt eine passende Empfehlung - schaffe sich aber heute nicht mehr.
Was ich geschafft habe ist
- test: kann nur das Team, nicht der einzel-SD. Es piepsen alle SDs im Team 10 mal
- AlarmOn/Off : kann nur das Team, nicht der einzel-SD. Alarm geht an/aus nach ~16sec
- statusRequest: kann nur ein einzelner SD. Angezeigt wird der Status des Teams.
Wenn die Alarme piepsen kann man lokal am SD den Ton Ausschalten. Dieser geht an dem Einen SD aus - und es wird gemeldet. Schaltet man den nächsten aus kommt nichts mehr. Fragt man den Status ab wird TonAus für alle gemeldet, auch wenn der einzelne noch piept.
=> ob der Ton an oder aus ist, kann man nicht feststellen.
Deine Frage:
ein Team richtet man durch peeren ein. ALLE sds eines Teams mussen gepeert werden, auch der Master. Man kann einen der SDs als "master" nehmen, ich würde immer einen virtuellen nehmen. Das separiert die Kommandos und readings besser.
Morgen (hoffentlich) die neue SW mit Empfehlung
Gruss Martin
Hi,
den SD habe ich etwas überarbeitet. Die Datei incl Anleitung ist im Anhang.
Bestehende Installationen sollten einfach übernommen werden - ggf. ist ein restart notwendig, damit die SW die Parameter einlesen kann.
Neu ist die freigabe der Kommandos -alarmOn/Off und test nur noch vom TeamLeader - ein normaler SD beantwortet dies eh nicht.
test habe ich nach teamCall umbenannt - da es ein Ruf an alle Team-mitglieder ist. Hoffe das Passt so.
Bitte testen und Anmerkungen bald liefern - passt das Konzept, funktioniert es, gibt es verbesserungen, ist die Anleitung verständlich?
Die Anleitung ist eine Erweiterung des EinsteigerDoc Anhangs HM
Gruss Martin
Hi Martin,
danke für die Anleitung und Files. Leider Piepst es immer noch nicht. Kannst du da mal drauf schauen? Was mache ich da falsch?
Config Melder 1 und 2 (mit anderem Namen):
Die Melder sehen wie folgt aus:
define RauchmelderFlur CUL_HM 2300DB
attr RauchmelderFlur .devInfo 000100
attr RauchmelderFlur .stc CD
attr RauchmelderFlur actCycle 028:00
attr RauchmelderFlur actStatus unknown
attr RauchmelderFlur autoReadReg 4_reqStatus
attr RauchmelderFlur devStateIcon off:general_ok *:secur_alarm
attr RauchmelderFlur event-on-change-reading .*
attr RauchmelderFlur expert 2_full
attr RauchmelderFlur firmware 1.0
attr RauchmelderFlur group Rauchmelder
attr RauchmelderFlur icon secur_smoke_detector
attr RauchmelderFlur model HM-SEC-SD
attr RauchmelderFlur msgRepeat 1
attr RauchmelderFlur peerIDs 00000000,
attr RauchmelderFlur room Rauchmelder
attr RauchmelderFlur serialNr SERIENUMMER_GEHEIM
attr RauchmelderFlur subType smokeDetector
attr RauchmelderFlur webCmd statusRequest
define FileLog_RauchmelderFlur FileLog ./log/RauchmelderFlur-%Y.log RauchmelderFlur
attr FileLog_RauchmelderFlur logtype text
attr FileLog_RauchmelderFlur room CUL_HM
Ich habe zuerst folgendes gemacht:
set NameRauchmelder1 peerChan 0 NameRauchmelder1 single set actor
define MelderTeam CUL_HM 271170
attr MelderTeam expert 1
attr MelderTeam model virtual_1
attr MelderTeam peerIDs
attr MelderTeam subType virtual
attr MelderTeam webCmd press short:press long
define Alarmknopf CUL_HM 27117001
attr Alarmknopf event-on-change-reading .*
attr Alarmknopf expert 1
attr Alarmknopf icon secur_smoke_detector
attr Alarmknopf model virtual_1
attr Alarmknopf peerIDs 2300CB01,2300DB01,
attr Alarmknopf room ALARM
attr Alarmknopf webCmd press teamCall:alarmOn:alarmOff
define FileLog_Alarmknopf FileLog ./log/Alarmknopf-%Y.log Alarmknopf
attr FileLog_Alarmknopf logtype text
attr FileLog_Alarmknopf room CUL_HM
Hallo bonner
besser als der Auszug aus dem fhem.cfg ist immer ein "list RauchmelderFlur". Da stehen dann noch viel mehr Daten drin, die zumindest für mich interessant sind.
Zum Konzept:
Du hast virtuelle Buttons - die machen nur Sinn, wenn du als Team diesen verwenden willst. Alarmknopf ist also dein TeamLeader - und 2 SDs sind angelernt.
Zum peeren:
Zitatset NameRauchmelder1 peerChan 0 NameRauchmelder1 single set actor
verstehe ich nicht. Das ist das Kommando, wenn man KEINEN virtuelen Teamhead will und sich die Melder selbst verwalten.
set Alarmknopf peerChan 0 RauchmelderFlur single
set Alarmknopf peerChan 0 Rauchmelder2 single
wäre das korrekte Kommando.
Zitatattr RauchmelderFlur peerIDs 00000000,
zeigt an, dass im RauchmelderFlur kein peer eingetragen ist. Erst ist zu prüfen, dass die Daten stimmen. Mache sicherheitshalber ein
set RauchmelderFlur getConfigDas sollte hoffentlich glatt gehen. Dann schaue das Attribut noch einmal an. Es sollte
00000000,27117001 beinhalten. Wenn nicht peere es noch einmal.
Danach mache ein
save damit fhem.cfg das Attribut speichert.
Wichtig ist natürlich, dass der SD auch gepairt ist mit FHEM - sonst darfst du nicht "schreiben"
Danach sollten die 3 TeamKommandos vom AlarmKnopf funktionieren
Gruss Martin
Hi Martin,
danke für die Unterstützung. Mittlerweile funktioniert die Alarmierung beim Teamlead. Den zweiten SD bekomme ich nicht dazu.
Der SD RauchmelderWohnzimmer ist der Teamlead, RauchmelderFlur ein .
Mit dem Kommando set RauchmelderWohnzimmer getConfig bekomme ich für keinen der beiden ein Ergebnis.
Lt. list sieht es für den Teamlead (RauchmelderWohnzimmer) wie folgt aus:
Readings:
2013-12-08 11:02:22 Activity alive
2013-12-08 10:10:11 CommandAccepted yes
2013-12-08 11:14:20 PairedTo 0x3FB6A
2013-12-08 11:13:58 R-pairCentral 0x3FB6A
2013-12-08 11:14:20 RegL_00: 02:01 0A:03 0B:FB 0C:6A 00:00
2013-12-08 11:15:07 battery ok
2013-12-08 11:15:07 level 1
2013-12-08 11:14:21 peerList Alarmknopf,
2013-12-08 11:10:37 smoke_detect -
2013-12-08 11:15:07 state off
2013-12-08 11:10:16 teamCall from Melderteam:1
2013-12-08 10:27:33 trigLast RauchmelderFlur :short
2013-12-08 10:27:33 trig_RauchmelderFlur short
Für den Teammember (RauchmelderFlur) so:
Readings:
2013-12-08 11:02:27 Activity alive
2013-12-08 11:22:11 CommandAccepted no
2013-12-08 11:22:15 PairedTo 0x3FB6A
2013-12-08 11:02:33 R-pairCentral 0x3FB6A
2013-12-08 11:22:15 RegL_00: 02:01 0A:03 0B:FB 0C:6A 00:00
2013-12-08 11:15:05 battery ok
2013-12-08 11:15:05 level 0
2013-12-08 11:22:16 peerList RauchmelderWohnzimmer,
2013-12-08 11:10:37 smoke_detect -
2013-12-08 11:22:11 state NACK
2013-12-08 11:10:16 teamCall from Melderteam:1
List für den "Alarmknopf" des virtuellen Melderteams:
Readings:
2013-12-08 11:10:37 eventNo 0C
2013-12-08 11:10:37 level 1
2013-12-08 11:22:11 peerList RauchmelderWohnzimmer,RauchmelderFlur,
2013-12-08 10:16:43 recentAlarm Melderteam
2013-12-08 11:10:37 smoke_detect -
2013-12-08 11:10:37 state off
2013-12-08 11:10:16 teamCall from Melderteam:1
Der Event Monitor zeigt bei Aktivierung TeamCall folgendes
2013-12-08 11:33:30 CUL_HM Alarmknopf teamCall: from Melderteam:2
2013-12-08 11:33:30 CUL_HM RauchmelderWohnzimmer teamCall: from Melderteam:2
2013-12-08 11:33:30 CUL_HM RauchmelderFlur teamCall: from Melderteam:2
Jetzt weiss ich nicht mehr weiter.... :-\
gepairt sollten die SDs also sein.
ein getConfig und statusRequest sollten fehlerfrei funktionieren.
Der "Alarmknopf" ist ein virtueller Button/Kanal mit der Funktion 'leader'
ZitatLt. list sieht es für den Teamlead (RauchmelderWohnzimmer) wie folgt aus:
verstehe ich nicht. Das ist doch ein Melder, kein Lead.
ZitatRauchmelderFlur
peerList RauchmelderWohnzimmer,
ist falsch. Der Melder sollte am teamLead gepeert werden - also am Alarmknopf, nicht am RauchmelderWohnzimmer.
Es muss also erst gelöscht werden, dann gepeert:
set RauchmelderWohnzimmer peerChan 0 RauchmelderFlur single unset actor
set AlarmknopfpeerChan 0 RauchmelderFlur single
was Melderteam ist, ist mir nicht klar.
Also in jedem Melder steht am Ende der teamLead in der PeerList
Im TeamLead stehen alle Mitglieder in der peerList
Gruss Martin
Hi Martin,
jetz funktioniert es. Vielen Dank für deine Hilfe.
Wieso der Flurmelder mit den Wohnzimmermelder gepeert war kann ich nicht mehr nachvollziehen. Habe irgendwie viel rum probiert. Momentan ist meine Lernkurve noch sehr steil ;)
Deine Anleitung war sehr hilfreich.
Viele Grüße
Christian
Hallo Christian,
ja, das ist so ein Problem mit dem peeren. Nicht nur deswegen peere ich nicht "direkt" sondern nur mittels FHEM.
Und da die Kontrolle nicht einfach ist, besonders nach größeren Umbauten, gibt es HMinfo mit den kommandos
---checks---
configCheck [<typeFilter>] # perform regCheck and regCheck
peerCheck [<typeFilter>] # find incomplete or inconsistant peer lists
---infos---
register [<typeFilter>] # devicefilter parse devicename. Partial strings supported
peerXref [<typeFilter>] # peer cross-reference
param [<typeFilter>] [<param1>] [<param2>] ... # displays params for all entities as table
Gruss Martin
Hallo,
ich habe bei mir auch 3 SDs isnstalliert.
Team angelegt und alle geleert.
Bei den Members steht 00000000, ID Leader.
Beim Leader steht die bei peerlist das Team.
Wenn ich jetzt den teamCall vom Leader auslöse piepen Member1 und Member2.
Beim teamCall vom Team piept nur der Leader.
Ist das korrekt so?
Hi Jens,
nein, nicht korrekt.
jeder sd im Team muss an das Team gepeert werden. auch er selbst! so es kein virtueller Lead ist.
IDleader wird gesetzt, wenn ein SD an das Device gepeert ist. Diese ID ist dann mindestens für einen SD der team-lead.
Bei Alarm müssen ALLE heulen
bei teamCall sollten alle piepen
Die Option eines virtuellen TeamLeads gefällt dir nicht? Macht die Sache "symetrischer"
Gruss Martin
Ich habe ein virtuelles Team(TeamDev)erstellt, dadrin habe einen channel1(Rauchmelderteam). Rauchmelderteam ist SDLead und alle 3 Melder stehen in der peerlist. Mein Schlafzimmermaster soll der Master sein. Bei dem steht bei SDteam SDLead und bei peerlist Rauchmelderteam. Bei den anderen beiden Meldern steht in der peerlist 0000000, die Id vom Schlafzimmermelder.
Hi Jens,
nein. so geht das nicht.
Basics:
Alle SDs werden einem Team zugeordnet. Das passiert indem sie mit der teamID gepeert werden. Das kann die ID eines der SDs sein oder die eines virtuellen Aktors.
Das Device, das als "def" die teamID hat ist der team-lead. Das kann ein realer SD sein oder ein virtueller.
Wenn du einen Realen nutzt brauchst du keinen virtuellen - der hat dann keinen Nutzen.
Ein SD der TeamLead ist weiss eigentlich nichts davon. Der macht auch nichts anderes. Es muss also kein realer SD teamLead sein (kann, muss nicht).
Wenn du einen virtuellen TeamLead haben willst musst du alle SDs mit diesem peeren.
Einen SD würde ich erst einmal nur mit einem peer/team peeren. Ob auch mehrere funktionieren habe ich nicht getestet - auch nicht, was dann passieren soll.
Gruss Martin
Klasse jetzt hab ich es. Unter dem virtuellen steht sdLead bei sdTeam und alle 3 Melder in der peerlist. Und bei jedem Melder in der peerlist der Virtuelle Channel.
Wenn ich nun den teamCall beim Virtuellen auslöse melden sich auch alle 3 Melder.
Hab da wohl was verseht gehabt.
teamCall ist doch der Test den man ausprobieren sollte oder?
teamCall ist der ohrenschonende Test zum Prüfen, ob alle SDs in Team sind. Wenn du einen virtuellen TeamLead hast ist der Test m.E. besser, da ALLE antworten.
Die Message ist identisch der wenn du am 'hinteren ' knopf den test startest (siehe Bedienungsanleitung)
du kannst auch AlarmOn schicken, aber besser nicht, wenn die Frau zuhause ist oder die Kinder schlafen. Auch remote ist es nicht immer angebracht!
Ob ein Sensor funktioniert kann man wohl nur wirklich probieren, indem man es Rauchen lässt.
Gruss Martin
Hallo Martin,
weißt du eigentlich, ob man nach einem alarmOn für den Teamleader den Alarm manuell (durch Drücken einer Taste am Rauchmelder) wieder deaktivieren kann? Bei mir hat dies am Wochenende nämlich nicht funktioniert, hätte dies aber eigentlich gerne (Rauchmelder sollen auch Sirene einer Alarmanlage sein ("unmöglicher" Zustand von HM-Sec-SC und HM-Sec-RHS an Balkontür)).
Hallo Kossman,
jain
man kann einen Alarm immer nur an einem Device ausschalten - also die Sirene, nicht den Alarm.
Man kann dann aber per notify ueber die Zentrale die andere abschalten.
SDs sollten nach 10 min wieder krach schlagen, wenn noch rauch da ist aber die Sirene stumm geschaltet wurde. Habe ich nicht getestet, denke es aber so gelesen zu haben
Wie machen das die Rauchmelder im Team eigentlich, wenn sie keine Zentrale haben?
Da wird das Drücken des Knopfes doch auch per Funk an alle anderen RM weitergegeben, damit die aufhören zu jaulen. Wenn auch ggf. mit einer Verzögerung bis 16 Sekunden (laut Handbuch).
vielleicht habe ich nicht lange genug die Ohren zu gehalten - muesste ich einmal testen.
Moeglich ist das, die könnten es genauso wie die Zentrale mithoeren
Hallo zusammen!
Auf der Suche nach dem Thema Rauchmelder und Homematic bin ich hier gelandet und vielleicht kann der eine oder andere mir etwas Erhellung bringen!
Ehrlich zugegeben liebäugle ich als Entwickler schon länger mit dem Thema Heimautomatisierung und hab nach und nach in meiner Wohnung, wenn mal eine An- oder Umrüstung anstand, auf Komponenten von Homematic gesetzt da das System aus meiner Sicht die größte Flexiblität mit sich bringt.
Vor kurzem habe ich dann den nächsten Schritt gewagt und meinen RaspberryPi auch motiviert durch einen Artikel in der c't mit einem CCD Modul von Busware (http://shop.busware.de/product_info.php/products_id/94) erweitert.
Ich muss sagen, dass die Welt der Heimautomatisierung doch extrem komplex ist, selbst für mich als jemand der recht gut mit Linux & Co. umgehen kann und verstehe umso besser, warum Heimanwender sich nicht an solche Systeme wagen.
Wie auch immer ...
Ich habe 6 Rauchmelder der Homematic-Serie schon längere Zeit im Einsatz und hab mittlerweile schon solide Erfahrungswerte damit, dass die leider häufig zu Fehlalarmen neigen (liest man ja auch an verschiedensten Stellen). Dass ist dann letztendlich auch der Grund, warum ich die mittlerweile nicht mehr miteinander Vernetze.
Meine Frage wäre nun, was in der Konstellation "best practice" ist und warum. Man liest immer wieder, man solle selbst wenn man einen Rauchmelder hat, diesen in eine virtuelle Gruppe stecken ... warum? Sorry, wenn ich vielleicht eine Frage stelle, die irgendwo schon ausführlich sinnvoll wie auch immer beantwortet wurde, aber vor lauter Wald sehe ich momentan keine Bäume und ich versuche irgendwie in die Thematik rein zu kommen.
aus Wiki:
Nutzt man einen SD kann/sollte man diesen mit sich selbst teamen (peerChan). In allen anderen Fällen braucht man einen Teamlead um eine team-ID zu erhalten.
daran würde ich mich halten.
Hallo,
ich habe einen Rauchmelder und diesem gemäß dem Wiki: http://www.fhemwiki.de/wiki/HM-SEC-SD_Rauchmelder einer virtuellen Gruppe zugewiesen.
Wenn ich nun bei der Gruppe sage TeamCall oder AlarmOn oder AlarmOff, funktioniert alles super.
Was quasi nicht vorhanden ist, ist "Test". Ist das so gewollt, oder fehlt mir da etwas?
Mein Hintergedanke war, den Rauchmelder auch für den internen Alarm zu verwenden und das eben am besten mit "Test". Alternativ könnte man natürlich auch AlarmOn und nach ein paar Sekunden wieder AlarmOff nehmen ;)
Danke und Gruß,
Alex
kannst du mir erklären was test ist?
TeamCall ist der Funk-test
Alarm ist ein Alarm - kann aber auch als geräuschvoller test genutzt werden.
Zitat von: martinp876 am 01 Juni 2014, 19:51:49Nutzt man einen SD kann/sollte man diesen mit sich selbst teamen (peerChan). In allen anderen Fällen braucht man einen Teamlead um eine team-ID zu erhalten.
daran würde ich mich halten.
Danke! Was genau hat das für einen Zweck? Würde gerne auch dahinter blicken statt nur stupide auszuführen um zu verstehen wie das ganze System funktioniert. ;-) LG
Der einzelne SD kann gepeert werdenund man kann den Status abfragen.
Kommandos wie Alarm und test gehen immer an die Gruppe (Team). Daher gibt es diese nicht bei dem einzelnen Device.
Ein Gruppe braucht eine ein-eindeutige Adresse (jedes Device hat auch eine). HM bietet nun die Möglichkeit des Betriebs ohne Zentrale - und muss somit ohne User-interface eine Gruppen-adresse generieren. Diese darf mit weiteren Gruppen und Devices nicht kollidieren. Daher nimmt HM einfach die ID eines der SD - zufällig beim peeren. Das ist dann der Team-Lead - aber alles was er tut ist, die HMId zu Verfügung zu stellen. Diese Kollision (Adresse des SD und des Team ist jetzt identisch) hat HM unter kontrolle.
Du kannst also alle Team-kommandos mit der Adresse des TeamLeads absetzen - und nur bei diesem.
Wenn du also einen Einzelnen hast kannst du den mit sich selbst peeren, dann ist er der Teamlead und kann die teamkommandos an sich senden (oder du von der Zentrale an ihn).
Wenn ich eine SD gruppe einrichte mit mehr als einem SD gefällt mir das nicht - weil
- ein SD besonders ist
- wenn der Team-SD defekt ist muss ich alle SDs neu peeren (die HMId muss geändert werden)
- ich die Team-Kommandos und events in einem der SDs suchen muss
=> es ist nicht notwendig - aber schlicht deutlich ordentlicher - den TeamLead zu separieren.
Im Prinzip habe ich das gleiche schon in
http://www.fhemwiki.de/wiki/HM-SEC-SD_Rauchmelder#TeamLead
gesagt.
Danke martinp876 dass du dir die Mühe gemacht hast, es zu erklären! Ich denke, ich hab es soweit verstanden, Danke! ;-)
Zitat von: martinp876 am 03 Juni 2014, 11:30:44
kannst du mir erklären was test ist?
TeamCall ist der Funk-test
Alarm ist ein Alarm - kann aber auch als geräuschvoller test genutzt werden.
Hallo Martin,
der Test wäre das, was passiert, wenn man den Knopf am Rauchmelder drückt. Ich glaube er piepst dann 3 mal in normaler Lautstärke und geht dann wieder aus.
Mich hat es nur etwas gewundert, da er beim pairen mit FHEM automatisch einen Test-"Button" im Webinterface hatte, aber nachdem ich den Teamlead erstellt hatte, eben dieser Button beim Teamlead nicht mehr vorhanden ist. Allerdings konnte ich ohne Teamlead den Rauchmelder garnicht ansteuern, also zwar die Buttons für Test/AlarmOn/Off anklicken, aber es passierte nichts.
Alternativ würde ich es dann einfach über AlarmOn und Off regeln. Ist halt dann nur etwas "komplizierter", weil er ja ein paar Sekunden braucht, bis der Alarm an/aus ist, nachdem das Kommando abgesetzt wurde.
Gruß,
Alex
"test" gibt es so eigentlich garnicht. Das ist quasi teamCall.
Ein pendant zu dem Drücken den Buttons am SD selbst kenne ich nicht. Das Drücken schaltet nur diesen SD kurz ein - er sendet keine message und macht einen Abgleich intern (sagt die Anleitung).
Dass man dies auch per message provozieren kann ist mir nicht bekannt.
Die Kommandos des Teams werden nur dann freigegeben und angezeigt, wenn der SD als peer bei einem anderen eingetragen ist. Mit etwas gutem Willen kannst du jeden SD als Lead eines anderen eintragen... das wird nicht verhindert und wird die Verwirrung auf die Spitze treiben :o
So ... also ich bin jetzt mal vorgegangen wie allgemein bzw. in deiner Anleitung beschrieben martin.
Ich habe da z.B. einen Rauchmelder Wohnung3_Arbeitszimmer_RM1 ... um ihn virtuell einzubinden, habe ich folgendes gemacht:
define Wohnung3_Arbeitszimmer_TeamDev CUL_HM 100010
set Wohnung3_Arbeitszimmer_TeamDev virtual 1
rename Wohnung3_Arbeitszimmer_TeamDev_Btn1 Wohnung3_Arbeitszimmer_Team
attr Wohnung3_Arbeitszimmer_Team webCmd teamCall:alarmOn:alarmOff
attr Wohnung3_Arbeitszimmer_Team icon secur_smoke_detector
attr Wohnung3_Arbeitszimmer_Team event-on-change-reading .*
set Wohnung3_Arbeitszimmer_Team peerChan 0 Wohnung3_Arbeitszimmer_RM1 single
attr Wohnung3_Arbeitszimmer_RM1 webCmd statusRequest
attr Wohnung3_Arbeitszimmer_RM1 icon secur_smoke_detector
attr Wohnung3_Arbeitszimmer_RM1 devStateIcon off:general_ok *:secur_alarm
attr Wohnung3_Arbeitszimmer_RM1 event-on-change-reading .*
Hat dann soweit auch nette Icons in der Oberfläche gehabt, bei Status gab es aber nur ??? bzw. auch sonst ging irgendwie nicht viel. Was mache ich denn verkehrt?
fehlt in der peerChan nach dem single nicht noch ein set?
Geht nich gips nich
set ist default, braucht man also nicht.
Der status sollte aktualisiert werden, wenn du ein statusRequest auslöst.
AutoReadReg 5 sollte sicherstellen, dass nach dem restart der Status einmal gelesen wird - kann aber dauern da es im Hintergrund läuft. Nach 30min etwa sollte es aktuell sein.
Hallo,
ich habe 3 SD mit einem virtuellen Team Lead.
Ein TeamCall wird bei allen SD gemeldet. Allerdings nicht wie im Wiki beschrieben mit Piepen.
ZitatteamCall testet die Zugehörigkeit und Erreichbarkeit aller SDs im Team. Alle SDs sollten 10 mal leise piepen.
Alarm On/Off hat auch keine Auswirkung.
Was mache ich falsch?
Danke und Gruß
Dieter
Internals:
.triggerUsed 1
DEF 5CBA28
HMLAN1_MSGCNT 21
HMLAN1_RAWMSG R8346E074,0001,10CEAE08,FF,FFD2,63A0105CBA28246BDF012101300100000000
HMLAN1_RSSI -46
HMLAN1_TIME 2018-12-06 12:28:39
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 21
NAME Rauchmelder_EG
NOTIFYDEV global
NR 419
NTFY_ORDER 50-Rauchmelder_EG
STATE off
TYPE CUL_HM
lastMsg No:63 - t:10 s:5CBA28 d:246BDF 012101300100000000
peerList Rauchmelder_Team,
protCmdDel 1
protEvt_AESCom-ok 2 last_at:2018-12-06 11:37:15
protLastRcv 2018-12-06 12:28:39
protNack 1 last_at:2018-12-06 11:37:15
protRcv 10 last_at:2018-12-06 12:28:39
protSnd 17 last_at:2018-12-06 12:28:39
protSndB 7 last_at:2018-12-06 12:28:38
protState CMDs_done
rssi_HMLAN1 cnt:3 min:-38 max:-38 avg:-38 lst:-38
rssi_at_HMLAN1 cnt:19 min:-46 max:-45 avg:-45.21 lst:-46
.attraggr:
.attreocr:
.*
.attrminint:
READINGS:
2018-12-06 10:49:52 .D-devInfo 000100
2018-12-06 10:49:52 .D-stc CE
2018-12-06 10:52:02 .R-devRepeatCntMax 0
2018-12-06 12:28:39 .peerListRDate 2018-12-06 12:28:39
2018-12-06 12:28:39 .protLastRcv 2018-12-06 12:28:39
2018-12-06 11:30:17 Activity alive
2018-12-06 11:37:15 CommandAccepted no
2018-12-06 10:49:52 D-firmware 1.0
2018-12-06 10:49:52 D-serialNr OEQ0959166
2018-12-06 12:28:39 PairedTo 0x246BDF
2018-12-06 10:52:02 R-pairCentral 0x246BDF
2018-12-06 12:28:39 RegL_00. 00:00 02:01 0A:24 0B:6B 0C:DF 16:00 1F:00
2018-12-06 11:37:15 aesCommToDev ok
2018-12-06 11:37:15 aesKeyNbr 00
2018-12-06 12:04:49 alarmTest ok
2018-12-06 12:04:49 battery ok
2018-12-06 12:04:49 level 0
2018-12-06 12:28:39 peerList Rauchmelder_Team,
2018-12-06 12:04:49 recentStateType info
2018-12-06 12:28:39 sdRepeat off
2018-12-06 12:04:49 smokeChamber ok
2018-12-06 11:28:41 smoke_detect none
2018-12-06 12:04:49 state off
2018-12-06 10:58:48 teamCall from TeamDev:00
helper:
HM_CMDNR 99
cSnd 01246BDF5CBA2800040000000000,01246BDF5CBA280103
mId 00AA
peerIDsRaw ,21013001,00000000
regLst ,0
rxType 6
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +5CBA28,00,01,00
nextSend 1544095719.68009
prefIO
rxt 0
vccu
p:
5CBA28
00
01
00
mRssi:
mNo 63
io:
HMLAN1:
-38
-38
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
regCollect:
role:
chn 1
dev 1
rpt:
IO HMLAN1
flg A
ts 1544095719.59333
ack:
HASH(0x7e3c918)
638002246BDF5CBA2800
rssi:
HMLAN1:
avg -38
cnt 3
lst -38
max -38
min -38
at_HMLAN1:
avg -45.2105263157895
cnt 19
lst -46
max -45
min -46
shadowReg:
tmpl:
Attributes:
IODev HMLAN1
actCycle 099:00
actStatus alive
autoReadReg 5_readMissing
devStateIcon off:general_ok@green .*:secur_alarm@red
event-on-change-reading .*
expert 2_raw
firmware 1.0
icon secur_smoke_detector
model HM-SEC-SD-2
msgRepeat 1
peerIDs 00000000,21013001,
room Alarme
serialNr OEQ0959166
subType smokeDetector
webCmd statusRequestInternals:
.triggerUsed 1
DEF 21013001
NAME Rauchmelder_Team
NOTIFYDEV global
NR 480
NTFY_ORDER 50-Rauchmelder_Team
STATE off
TESTNR 2
TYPE CUL_HM
chanNo 01
device TeamDev
peerList Rauchmelder_EG,Rauchmelder_KG,Rauchmelder_OG,
sdTeam sdLead
.attraggr:
.attrminint:
READINGS:
2018-12-06 11:39:49 aesCBCCounter 0000D2
2018-12-06 11:28:41 eventNo 04
2018-12-06 11:28:41 level 0
2018-12-06 11:34:03 peerList Rauchmelder_EG,Rauchmelder_KG,Rauchmelder_OG,
2018-12-06 11:28:41 smoke_detect none
2018-12-06 12:04:49 state off
2018-12-06 10:58:48 teamCall from TeamDev:00
helper:
fkt sdLead2
expert:
def 1
det 0
raw 1
tpl 0
role:
chn 1
tmpl:
Attributes:
devStateIcon off:general_ok@green .*:secur_alarm@red
icon secur_smoke_detector
model virtual_1
peerIDs 5CBA2801,5CBA3D01,5CBA4001,
room Alarme
subType smokeDetector
webCmd press short:press long
Internals:
DEF 210130
IODev HMLAN1
NAME TeamDev
NOTIFYDEV global
NR 479
NTFY_ORDER 50-TeamDev
STATE CMDs_done
TYPE CUL_HM
channel_01 Rauchmelder_Team
protSnd 6 last_at:2018-12-06 11:39:50
protSndB 6 last_at:2018-12-06 11:39:50
protState CMDs_done
.attraggr:
.attrminint:
READINGS:
2018-12-06 11:39:50 state CMDs_done
helper:
HM_CMDNR 210
mId
expert:
def 1
det 0
raw 1
tpl 0
io:
prefIO
vccu
mRssi:
mNo
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
Attributes:
IODev HMLAN1
expert 2_raw
model virtual_1
room Alarme
subType virtual
webCmd virtual
Zitat von: dk3572 am 06 Dezember 2018, 13:46:16
Was mache ich falsch?
Einen steinalten Thread zu kapern.
Zur Sache: Hast Du im Wiki auch das Kapitel über Probleme beim SD-2 (https://wiki.fhem.de/wiki/HM-SEC-SD_Rauchmelder#Probleme_beim_SD-2) beachtet - denn im Gegensatz zu 2014, wo es den SD-2 noch nicht gab, hast Du ja so einen ...