Hallo Brandfreunde,
ich habe mir erstmalig drei Rauchmelder HM-SEC-SD-2 beschafft. Sie sind noch nicht ausgepackt, sie liegen seit Tagen im Karton rum. Die Wiki-Anleitung https://wiki.fhem.de/wiki/HM-SEC-SD_Rauchmelder#virtueller_TeamLead liest sich etwas verstörend - und ich will da möglichst wenig falsch machen. Also kam ich auf die Idee, den virtuellen teamlead schon mal vorab einzurichten. Und das geht schief.
define TeamDev CUL_HM 111111
Schick, geht. Sofort speichern.
set TeamDev virtual 1
Unknown argument virtual choose one of clear getConfig getRegRaw regBulk regSet
Ähmmm - und was sagt mir das jetzt genau?
Die automatisch erzeugte Konfiguration in fhem.cfg sieht so aus:
# teamlead Rauchmelder nach https://wiki.fhem.de/wiki/HM-SEC-SD_Rauchmelder#virtueller_TeamLead
define TeamDev CUL_HM 111111
attr TeamDev expert 2_raw
attr TeamDev model virtual_1
attr TeamDev subType virtual
attr TeamDev webCmd virtual
define TeamDev_Btn1 CUL_HM 11111101
attr TeamDev_Btn1 model virtual_1
attr TeamDev_Btn1 peerIDs
attr TeamDev_Btn1 webCmd press short:press long
Ist das ok so? Oder muss ich da wegen "virtual" noch was machen?
Und wie ist das mit "rename TeamDev_Btn1 Rauchmelder_Team"? Das wäre ja auf den ersten Blick problemlos möglich.
Danach packe ich meine drei neuen Rauchmelder aus und lerne die einzeln an, ja?
Moin,
sicher dass Du Dich nicht vertippt hast? Ich habe es gerade nachgestellt, es funktioniert wie im Wiki.
Ist Dein FHEM aktuell?
In jedem Fall brauchst Du einen Button-Kanal im Gerät TeamDev. Gib mal bitte die Ausgabe von
list TeamDev
statt der RAW definition.
Ich habe das nochmal neu gemacht. Die beiden Zeilen habe ich vermittels cut+paste im Browser in die Kommandozeile getan. Die erste Zeile (define) trägt lediglich eine Zeile (define) in fhem.cfg ein. Die zweite Zeile wirft dann den Fehler, trägt aber die weiteren Zeilen in fhem.cfg ein.
list TeamDev
Internals:
CFGFN
DEF 111111
IODev
NAME TeamDev
NOTIFYDEV global
NR 846
STATE ???
TYPE CUL_HM
channel_01 TeamDev_Btn1
READINGS:
helper:
HM_CMDNR 146
mId
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +111111,00,00,00
prefIO
rxt 0
vccu
p:
111111
00
00
00
mRssi:
mNo
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
tmpl:
Attributes:
expert 2_raw
model virtual_1
subType virtual
webCmd virtual
Und weiterhin habe ich testweise die zweite Zeile (set TeamDev virtual 1) mit den Schaltflächen realisiert. Das wirft keinen Fehler. Dafür FEHLT das Attribut attr TeamDev_Btn1 webCmd press short:press long in fhem.cfg.
Auch hierfür
list TeamDev
Internals:
CFGFN
DEF 111111
IODev
NAME TeamDev
NOTIFYDEV global
NR 840
STATE ???
TYPE CUL_HM
channel_01 TeamDev_Btn1
READINGS:
helper:
HM_CMDNR 104
mId
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +111111,00,00,00
prefIO
rxt 0
vccu
p:
111111
00
00
00
mRssi:
mNo
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
tmpl:
Attributes:
expert 2_raw
model virtual_1
subType virtual
webCmd virtual
Seltsam. Jedenfalls ist der virtuelle Kanal angelegt.
channel_01 TeamDev_Btn1Aber hier dann laut Wiki weiter.
ZitatDafür FEHLT das Attribut attr TeamDev_Btn1 webCmd press short:press long in fhem.cfg.
Wo soll das von allein herkommen und vor allem: Wofür soll man es brauchen?
vor allem fehlt attr IODev im hauptdevice.
Nochmal präzise, es geht um set TeamDev virtual 1:
Version 1)
Ich gab diese Zeile im Webbrowser in der Kommandozeile (oben) meiner fhem-Installation ein. Ergebnis war diese Fehlermeldung: Unknown argument virtual choose one of clear getConfig getRegRaw regBulk regSet
Trotzdem wurde folgendes in fhem.cfg geschrieben:
attr TeamDev expert 2_raw
attr TeamDev model virtual_1
attr TeamDev subType virtual
attr TeamDev webCmd virtual
define TeamDev_Btn1 CUL_HM 11111101
attr TeamDev_Btn1 model virtual_1
attr TeamDev_Btn1 peerIDs
attr TeamDev_Btn1 webCmd press short:press long
Version 2)
In der Webseite der virtuellen Device gibt es doch Schalter, so auch für "set". Mit diesem SCHALTER habe ich "set TeamDev virtual 1" eingegeben. (Natürlich zurückgesetzte conf.) Es gab keine Fehlermeldung.
Dann wurde folgendes in fhem.cfg geschrieben:
attr TeamDev expert 2_raw
attr TeamDev model virtual_1
attr TeamDev subType virtual
attr TeamDev webCmd virtual
define TeamDev_Btn1 CUL_HM 11111101
attr TeamDev_Btn1 model virtual_1
attr TeamDev_Btn1 peerIDs
In der ersten Version entsteht (bei mir) also diese Zeile zusätzlich (was auch immer die macht):
attr TeamDev_Btn1 webCmd press short:press long
Meine eigentliche Frage war aber: So ist das im Grunde ok und ich kann jetzt mal den ersten Rauchmelder auspacken und anlernen undund?
Zitat von: frank am 13 Juli 2018, 00:10:31
vor allem fehlt attr IODev im hauptdevice.
Ähmmm. Leider kann ich mit dem Satz nichts anfangen. Also außer dass wohl was falsch ist. Was läuft bei mir falsch? Wie kann ich das ändern?
natürlich eingeben/setzen:
attr TeamDev IODev <name_deines_gateways>
OK, bei einem HM-Button (und das ist der virtuelle Kanal ja irgendwie auch) macht press short:presse long schon irgendwie Sinn. Wurde bei meinem Test übrigens nicht automatisch angelegt. Aber ist egal: Als Teamlead gehören da sowieso ganz andere Befehle rein.
Insofern FEHLT nicht die Zeile, sie ist eher ZUVIEL.
Zu IODev: Idealerweise läuft eine VCCU, dann ist es noch ein bisschen anders.
Aber mit nur einem Homematic-IO reicht es so.
Ich musste mich um IODev bisher nie kümmern - es war einfach da.
ZitatMeine eigentliche Frage war aber: So ist das im Grunde ok und ich kann jetzt mal den ersten Rauchmelder auspacken und anlernen undund?
Nach der IODev-Klärung: yep. "Anlernen" an FHEM ist aber zunächst nicht mit dem TeamLead verknüpft. Erst wenn das Gerät richtig mit FHEM als Zentrale verbandelt ist, kann auch eine Verknüpfung mit dem TeamLead per peering erfolgten, als zweiter Schritt.
Ok, verstanden.
Mir wäre aber lieb, wenn ihr nochmal kurz über die config schaut - ob das so nun richtig ist. (Fehlt da noch Logfile oder gar zwei Logfiles?) - Alles korrekt?
define SCC CUL /dev/ttyAMA0@38400 1234
attr SCC hmId FF1312
attr SCC rfmode HomeMatic
...
# teamlead Rauchmelder nach https://wiki.fhem.de/wiki/HM-SEC-SD_Rauchmelder#virtueller_TeamLead
define TeamDev CUL_HM 111111
attr TeamDev IODev SCC
attr TeamDev autoReadReg 4_reqStatus
attr TeamDev expert 2_raw
attr TeamDev model virtual_1
attr TeamDev subType virtual
attr TeamDev room 13 Rauch
define TeamDev_Btn1 CUL_HM 11111101
attr TeamDev_Btn1 model virtual_1
attr TeamDev_Btn1 peerIDs
#attr TeamDev_Btn1 webCmd press short:press long
attr TeamDev_Btn1 room 13 Rauch
P.S: In meinem neuen Raum "13 Rauch" taucht diese short/long-Schalterei trotz Auskommentierung auf. Soll ich Screnshot zeigen?
Logfiles brauchst Du, wenn Du Aufzeichnungen über das Verhalten brauchst. Ausgelöste Alarme würde ich separat im zentralen Log speichern lassen. Für die Rauchmelder wird beim Anlernen (wenn Autocreate aktiv und das Anlegen von Logfiles nicht deaktiviert ist) auch ein Logfile angelegt. Für den Anfang und zum Kennenlernen ist das ganz nützlich, dann braucht man es eigentlich nicht mehr.
Für viele Geräte gibt es voreingestellte webCmds. Denkbar, dass das hier zum Tragen kommt, wenn du das Attribut entfernst.
Aber wieso auskommentieren? und vor allem wo? in der fhem.cfg? Siehe meine Signatur ...
Lerne jetzt die Rauchmelder an.
Benenne TeamDev_Btn1 um und peere die Melder damit wie im Wiki beschrieben.
Auch das Notify mit der Rauchmelderausschaltung (im Beispiel sd.nf.quiet, ersetze dort sdTeam durch Rauchmelder_Team Wiki angepasst) ist sehr praktisch.
Zitat von: Pfriemler am 13 Juli 2018, 12:28:36
Für viele Geräte gibt es voreingestellte webCmds. Denkbar, dass das hier zum Tragen kommt, wenn du das Attribut entfernst.
Aber wieso auskommentieren? und vor allem wo? in der fhem.cfg? Siehe meine Signatur ...
Einfach einen Doppelpunkt ":" in das Attribut webCmd eintragen statt zu leeren oder zu löschen.
Gruß Benni.
hallo curt,
ich meine das mit IODev steht drin:
ZitatNach der Definition bitte überprüfen, dass TeamDev das Attribut (attr) IODev bzw. IOgrp gesetzt hat (das sollte normalerweise automatisch passieren)! Am Besten die Konfiguration mit HMinfo configCheck prüfen, die ordnungsgemäße Funktion des TeamDev ist wichtig für den Erfolg des folgenden Peerings der Rauchmelder.
Das ist aus meiner Sicht Murks, passiert auch nicht automatisch:
attr TeamDev autoReadReg 4_reqStatus
attr TeamDev expert 2_raw
Und nochmal die Frage:
Welche Version hat Dein FHEM?Bitte version eingeben und Ausgabe posten.
Dein Fehler mit der Kommandozeile ist nicht nachvollziehbar!
Bei der Eingabe des Befehls set TeamDev virtual 1 bzw. interaktive in der Weboberfläche gibt es einen kleinen zeitlichen Unterschied in der Anzeige des Gerätes TeamDev_Btn1 - der Eintrag des webCmd dauert einen kleinen Moment, wenn man aber Refresh im Browser drückt wird er angezeigt. Das Ergebnis für TeamDev_Btn1 ist aber gleich!
Gruß Otto
Zitat von: Benni am 13 Juli 2018, 13:02:32
Einfach einen Doppelpunkt ":" in das Attribut webCmd eintragen statt zu leeren oder zu löschen.
Den Satz habe ich leider nicht verstanden. Wie würde das konkret aussehen?
Zitat von: Otto123 am 13 Juli 2018, 13:11:20
ich meine das mit IODev steht drin:
Wurde nicht automatisch angelegt.
Zitat von: Otto123 am 13 Juli 2018, 13:11:20
Das ist aus meiner Sicht Murks, passiert auch nicht automatisch:
attr TeamDev autoReadReg 4_reqStatus
attr TeamDev expert 2_raw
Doch. Beide Zeilen wurden automatisch angelegt, bei beiden ausprobierten Wegen identisch. Zweimal getestet, Irrtum unmöglich.
Zitat von: Otto123 am 13 Juli 2018, 13:11:20
Und nochmal die Frage: Welche Version hat Dein FHEM?
Aktuell - glaube ich wenigstens. Vor jeder Änderung fahre ich ein Update. Dann sichere ich fhem.conf.
Zitat von: Otto123 am 13 Juli 2018, 13:11:20
Dein Fehler mit der Kommandozeile ist nicht nachvollziehbar!
Wird aber exakt so ins Browserfenster (fett) geschrieben. Ich denke mir das doch nicht aus.
Zitat von: Otto123 am 13 Juli 2018, 13:11:20
Dein Fehler mit der Kommandozeile ist nicht nachvollziehbar!
Bei der Eingabe des Befehls set TeamDev virtual 1 bzw. interaktive in der Weboberfläche gibt es einen kleinen zeitlichen Unterschied in der Anzeige des Gerätes TeamDev_Btn1 - der Eintrag des webCmd dauert einen kleinen Moment, wenn man aber Refresh im Browser drückt wird er angezeigt. Das Ergebnis für TeamDev_Btn1 ist aber gleich!
Nein. Nicht gleich. In der Kommandozeilenversion wird "attr TeamDev_Btn1 webCmd press short:press long" zusätzlich angelegt. Ich denke mir das doch nicht aus.
Zitat von: Otto123 am 13 Juli 2018, 13:11:20
Bitte version eingeben und Ausgabe posten.
Latest Revision: 16974
File Rev Last Change
fhem.pl 16866 2018-06-14 07:58:06Z rudolfkoenig
96_allowed.pm 16295 2018-02-28 22:11:09Z rudolfkoenig
90_at.pm 15795 2018-01-05 20:46:21Z rudolfkoenig
98_autocreate.pm 15620 2017-12-16 18:10:36Z rudolfkoenig
57_Calendar.pm 16742 2018-05-15 19:20:16Z neubert
57_CALVIEW.pm 16846 2018-06-10 18:33:19Z chris1284
00_CUL.pm 16907 2018-06-25 09:03:09Z rudolfkoenig
10_CUL_HM.pm 16940 2018-07-03 18:40:53Z martinp876
98_DOIF.pm 16884 2018-06-18 21:20:59Z Damian
98_dummy.pm 16965 2018-07-09 07:59:58Z rudolfkoenig
55_DWD_OpenData.pm 16745 2018-05-15 20:07:52Z jensb
91_eventTypes.pm 14888 2017-08-13 12:07:12Z rudolfkoenig
01_FHEMWEB.pm 16875 2018-06-15 19:05:36Z rudolfkoenig
92_FileLog.pm 16770 2018-05-24 15:16:12Z rudolfkoenig
98_HMinfo.pm 16971 2018-07-10 17:49:45Z martinp876
98_HTTPMOD.pm 16951 2018-07-06 18:02:15Z StefanStrobel
36_JeeLink.pm 14707 2017-07-13 18:08:33Z justme1968
36_LaCrosse.pm 16168 2018-02-13 21:01:41Z HCS
74_Nmap.pm 14107 2017-04-26 03:51:05Z igami
91_notify.pm 15937 2018-01-20 13:43:28Z rudolfkoenig
33_readingsGroup.pm 16299 2018-03-01 08:06:55Z justme1968
33_readingsProxy.pm 16299 2018-03-01 08:06:55Z justme1968
86_Robonect.pm 16758 2018-05-19 07:14:30Z andi291
98_structure.pm 16865 2018-06-14 07:21:25Z rudolfkoenig
99_SUNRISE_EL.pm 16632 2018-04-17 19:00:21Z rudolfkoenig
98_SVG.pm 16830 2018-06-07 10:18:21Z rudolfkoenig
42_SYSMON.pm 15910 2018-01-16 23:07:56Z hexenmeister
98_telnet.pm 16293 2018-02-28 21:33:57Z rudolfkoenig
45_TRX.pm 16666 2018-04-27 22:14:50Z KernSani
46_TRX_LIGHT.pm 16516 2018-03-29 22:10:21Z KernSani
46_TRX_SECURITY.pm 16514 2018-03-29 22:09:17Z KernSani
46_TRX_WEATHER.pm 16542 2018-04-02 22:10:20Z KernSani
99_Utils.pm 15713 2017-12-28 11:01:02Z rudolfkoenig
77_UWZ.pm 15650 2017-12-20 05:41:22Z CoolTux
98_version.pm 15140 2017-09-26 09:20:09Z markusbloch
59_Weather.pm 16644 2018-04-22 08:07:35Z neubert
98_weblink.pm 16293 2018-02-28 21:33:57Z rudolfkoenig
59_Wunderground.pm 15171 2017-10-02 09:52:16Z loredo
10_ZWave.pm 16796 2018-05-29 19:28:34Z rudolfkoenig
00_ZWDongle.pm 16293 2018-02-28 21:33:57Z rudolfkoenig
Blocking.pm 15412 2017-11-09 14:34:29Z rudolfkoenig
Color.pm 11159 2016-03-30 16:08:06Z justme1968
DevIo.pm 16623 2018-04-15 18:44:05Z rudolfkoenig
DWDODweblink.pm 16 2018-04-13 21:03:00Z jensb
HMConfig.pm 16887 2018-06-19 18:42:44Z martinp876
HttpUtils.pm 16768 2018-05-24 08:53:41Z rudolfkoenig
myUtilsTemplate.pm 7570 2015-01-14 18:31:44Z rudolfkoenig
RTypes.pm 10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm 16568 2018-04-08 09:44:42Z rudolfkoenig
TcpServerUtils.pm 15707 2017-12-27 14:41:21Z rudolfkoenig
UConv.pm 14398 2017-05-28 09:40:42Z loredo
Unit.pm 14136 2017-04-29 16:31:46Z loredo
YahooWeatherAPI.pm 16641 2018-04-21 12:28:38Z neubert
ZWLib.pm 15466 2017-11-20 22:22:19Z rudolfkoenig
doif.js 15546 2017-12-03 09:57:42Z Ellert
fhemweb.js 16727 2018-05-11 09:12:01Z rudolfkoenig
fhemweb_readingsGroup.js 15189 2017-10-03 17:53:27Z justme1968
Zitat von: curt am 13 Juli 2018, 17:51:58
Den Satz habe ich leider nicht verstanden. Wie würde das konkret aussehen?
attr TeamDev_Btn1 webCmd :
Ich hatte das einige Tage auf sich beruhen lassen und mir die Sache nochmals angeschaut. Da fiel mir auf, dass es auch noch das Modul "CUL" gibt, welches ich in anderer Sache nutze. Daher testete ich das Anlegen eines virtuellen TeamLead mit/auf CUL. Leider scheitert das (bei mir) mit Fehlermeldung. Daher richtete ich das Ganze nochmals neu mit CUL_HM ein. Dieses bringt ja (bei mir) automatisch mehrere Attribute, die andere in der Diskussion in Frage stellten. Ich habe diese aber komplett so belassen, da ich nun zu der Überzeugung komme, dass der Modul-Entwickler sich dabei sicher was gedacht hat.
Zitat von: Pfriemler am 13 Juli 2018, 12:28:36
Lerne jetzt die Rauchmelder an.
Benenne TeamDev_Btn1 um und peere die Melder damit wie im Wiki beschrieben.
Das habe ich heute mit dem ersten nagelneuen Rauchnelder getan. Und das funktionierte auch ganz schön, Ergebnisse unten. Erschreckenderweise gibt es allerdings (bei mir) das Reading "
aesCBCCounter" überhaupt nicht - sollte mich das verunsichern?
Auszug fhem.conf (alias, room und battery_change von mir zusätzlich gesetzt):
define HM_5A5754 CUL_HM 5A5754
attr HM_5A5754 IODev SCC
attr HM_5A5754 actCycle 099:00
attr HM_5A5754 actStatus alive
attr HM_5A5754 alias Rauch Flur unten
attr HM_5A5754 autoReadReg 4_reqStatus
attr HM_5A5754 battery_change 2018-07-19
attr HM_5A5754 expert 2_raw
attr HM_5A5754 firmware 1.0
attr HM_5A5754 model HM-SEC-SD-2
attr HM_5A5754 msgRepeat 1
attr HM_5A5754 peerIDs 00000000,
attr HM_5A5754 room 13 Rauch
attr HM_5A5754 serialNr OEQ0600470
attr HM_5A5754 subType smokeDetector
attr HM_5A5754 webCmd statusRequest
Internals, kopiert von Webseite; was mache ich mit diesem Fehler?
DEF 5A5754
IODev SCC
NAME HM_5A5754
NOTIFYDEV global
NR 836
NTFY_ORDER 50-HM_5A5754
STATE MISSING ACK
TYPE CUL_HM
protCmdDel 1
protResnd 1 last_at:2018-07-19 21:48:55
protResndFail 1 last_at:2018-07-19 21:49:01
protSnd 1 last_at:2018-07-19 21:48:51
protSndB 2 last_at:2018-07-19 21:48:55
protState CMDs_done_Errors:1
Readlings, kopiert von Webseite
Activity alive 2018-07-19 21:36:39
CommandAccepted yes 2018-07-19 19:44:15
D-firmware 1.0 2018-07-19 19:44:13
D-serialNr OEQ0600470 2018-07-19 19:44:13
PairedTo 0xFF1312 2018-07-19 19:44:18
R-pairCentral 0xFF1312 2018-07-19 19:44:18
RegL_00. 02:01 0A:FF 0B:13 0C:12 16:00 1F:00 00:00 2018-07-19 19:44:18
aesCommToDev ok 2018-07-19 19:44:15
aesKeyNbr 00 2018-07-19 19:44:15
alarmTest ok 2018-07-19 19:46:26
battery ok 2018-07-19 19:46:26
level 0 2018-07-19 19:46:26
recentStateType info 2018-07-19 19:46:26
sdRepeat off 2018-07-19 19:44:18
smokeChamber ok 2018-07-19 19:46:26
state MISSING ACK 2018-07-19 21:49:01
Zitat von: Pfriemler am 13 Juli 2018, 12:28:36
Auch das Notify mit der Rauchmelderausschaltung (im Beispiel sd.nf.quiet, ersetze dort sdTeam durch Rauchmelder_Team Wiki angepasst) ist sehr praktisch.
Da habe ich noch nichts gemacht. - Mich wundert das fehlende "
aesCBCCounter und bin nun doch verunsichert. Ach Quatsch - das bin ich eigentlich immer.
Nachtrag:
Der erste Kontakt des Brandmelders mit FHEM laut Log:
2018-07-19 19:46:26 CUL_HM HM_5A5754 alarmTest: ok
2018-07-19 19:46:26 CUL_HM HM_5A5754 battery: ok
2018-07-19 19:46:26 CUL_HM HM_5A5754 level: 0
2018-07-19 19:46:26 CUL_HM HM_5A5754 smokeChamber: ok
2018-07-19 19:46:26 CUL_HM HM_5A5754 off
Zitat von: curt am 19 Juli 2018, 22:51:54
Auszug fhem.conf
...
Internals, kopiert von Webseite;
...
Readlings, kopiert von Webseite
Poste doch stattdessen bitte mal ein vollständiges list (http://commandref.fhem.de/#list) und zwar jeweils eins vom SD und eins vom (virtuellen) Team-Lead.
Hier die lists.
list HM_5A5754
Internals:
DEF 5A5754
IODev SCC
LASTInputDev SCC
MSGCNT 1
NAME HM_5A5754
NOTIFYDEV global
NR 836
NTFY_ORDER 50-HM_5A5754
SCC_MSGCNT 1
SCC_RAWMSG A0DB1A6105A5754FF131206010000::-46:SCC
SCC_RSSI -46
SCC_TIME 2018-07-20 09:08:45
STATE off
TYPE CUL_HM
lastMsg No:B1 - t:10 s:5A5754 d:FF1312 06010000
protLastRcv 2018-07-20 09:08:44
protRcv 1 last_at:2018-07-20 09:08:44
protSnd 1 last_at:2018-07-20 09:08:45
protState CMDs_done
rssi_at_SCC cnt:1 min:-46 max:-46 avg:-46 lst:-46
READINGS:
2018-07-19 23:51:13 Activity alive
2018-07-19 19:44:15 CommandAccepted yes
2018-07-19 19:44:13 D-firmware 1.0
2018-07-19 19:44:13 D-serialNr OEQ0600470
2018-07-19 19:44:18 PairedTo 0xFF1312
2018-07-19 19:44:18 R-pairCentral 0xFF1312
2018-07-19 19:44:18 RegL_00. 02:01 0A:FF 0B:13 0C:12 16:00 1F:00 00:00
2018-07-19 19:44:15 aesCommToDev ok
2018-07-19 19:44:15 aesKeyNbr 00
2018-07-20 09:08:45 alarmTest ok
2018-07-20 09:08:45 battery ok
2018-07-20 09:08:45 level 0
2018-07-20 09:08:45 recentStateType info
2018-07-19 19:44:18 sdRepeat off
2018-07-20 09:08:45 smokeChamber ok
2018-07-20 09:08:45 state off
helper:
HM_CMDNR 177
mId 00AA
regLst ,0
rxType 6
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +5A5754,00,00,00
nextSend 1532070525.02155
prefIO
rxt 0
vccu
p:
5A5754
00
00
00
mRssi:
mNo B1
io:
SCC:
-38
-38
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rpt:
IO SCC
flg A
ts 1532070524.92258
ack:
HASH(0x3d2f050)
B18002FF13125A575400
rssi:
at_SCC:
avg -46
cnt 1
lst -46
max -46
min -46
tmpl:
Attributes:
IODev SCC
actCycle 099:00
actStatus alive
alias Rauch Flur unten
autoReadReg 4_reqStatus
battery_change 2018-07-19
expert 2_raw
firmware 1.0
model HM-SEC-SD-2
msgRepeat 1
peerIDs 00000000,
room 13 Rauch
serialNr OEQ0600470
subType smokeDetector
webCmd statusRequest
list Rauchmelder_Team
Internals:
DEF 11111101
NAME Rauchmelder_Team
NOTIFYDEV global
NR 834
NTFY_ORDER 50-Rauchmelder_Team
STATE MISSING ACK
TESTNR 1
TYPE CUL_HM
chanNo 01
device TeamDev
peerList HM_5A5754,
sdTeam sdLead
READINGS:
2018-07-19 23:51:13 peerList HM_5A5754,
2018-07-19 23:51:13 state MISSING ACK
helper:
fkt sdLead2
expert:
def 1
det 0
raw 1
tpl 0
role:
chn 1
vrt 1
Attributes:
model virtual_1
peerIDs 5A575401,
room 13 Rauch
webCmd press short:press long
Ist das nun gut oder schlecht?
Muss ich mir Sorgen machen?
Oder kann ich nun mit den anderen beiden Meldern sowie den Codeschnipseln loslegen?
Ich fühle mich im Moment etwas einsam.
Was ich sehen kann ist, dass der SD zwar korrekt mit FHEM gepairt zu sein scheint, das ist gut!
Allerdings scheint das peering zwischen Virtuellem Team-Lead und dem SD nicht vollständig: Der virtuelle Team-Lead hat den SD zwar in seiner Peer-List stehen, aber umgekehrt ist der virtuelle Team-Lead beim SD als Peer unbekannt.
Ein configCheck mittels HMInfo sollte dir das übrigens auch melden.
Kann man sowieso immer machen, wenn man neue Geräte anlernt und/oder peert. ;)
gb#
Moin
Das hatte ich auch mit einigen von meinen 8! Gab da auch keinen erkennbaren Grund oder Regelmaessigkeit! Habe das dann von Hand nachgetragen.
Gruss Christoph
Zitat von: pc1246 am 24 Juli 2018, 07:10:09
Moin
Das hatte ich auch mit einigen von meinen 8! Gab da auch keinen erkennbaren Grund oder Regelmaessigkeit! Habe das dann von Hand nachgetragen.
Gruss Christoph
aber sicherlich nur beim virtuellen channel.
hier fehlt der peer aber beim rauchmelder. durch setzen des attributs kommt der peer aber nicht ins eeprom.
Zitat von: frank am 24 Juli 2018, 08:56:22
aber sicherlich nur beim virtuellen channel.
hier fehlt der peer aber beim rauchmelder. durch setzen des attributs kommt der peer aber nicht ins eeprom.
Moin
Sorry, ich meinte, dass ich das nachgetragen habe, wenn es nicht automatisch angelegt wurde! Das automatische Eintragen stand mal so im Wiki!
Gruss Christoph
Verstehe ich gerade nicht. Einen peer im Attribut eines virtuellen kanals eintragen funktioniert, auch wenn es nicht beschrieben ist.
Bei einem echten Device geht es aber nicht. Das muss ins Device. Fhem hat nur eine kopie. Es in die kopie einzutragen ist sinnlos.
Zitat von: Benni am 24 Juli 2018, 06:33:17
Ein configCheck mittels HMInfo sollte dir das übrigens auch melden.
Kann man sowieso immer machen, wenn man neue Geräte anlernt und/oder peert. ;)
Hätte ich das mal gelassen ... mehrere meiner Fensteröffnungsmelder quengeln auch rum: peer list incomplete. Gibt es einen Vorschlag, wo ich nachlesen kann, wie das grundsätzlich gedacht ist? Denn es ist so, dass die eigentlich genau das tun was sie tun sollen - und mein Verstand leider nicht ausreicht um zu begreifen, warum da nun noch was gepaired werden soll. Und wie man das macht.
Zum eigentlichen Thema:
configCheck done:
...
peer not verified. Check that peer is set on both sides
Rauchmelder_Team p:HM_5A5754
peering strange - likely not suitable
HM_5A5754 not peered!! add SD to any team !!
...
Da verstehe ich gleich gar nicht, was zu tun ist, die Wiki-Seite erklärt es mir auch nicht genau. Da steht ja nur, dass ich den SD mit dem virtual pairen soll (und der dazugehörige Befehl) - das hatte ich getan. Soll ich den SD2 mit sich selbst pairen oder ist da noch was anderes gemeint?
Ich habe noch zwei weitere SD2. Die habe ich noch nicht in Betrieb genommen, ich wollte/will eigentlich alles richtig machen. Aber irgendwie ...
Zitat von: martinp876 am 24 Juli 2018, 21:50:15
Verstehe ich gerade nicht. Einen peer im Attribut eines virtuellen kanals eintragen funktioniert, auch wenn es nicht beschrieben ist.
Bei einem echten Device geht es aber nicht. Das muss ins Device. Fhem hat nur eine kopie. Es in die kopie einzutragen ist sinnlos.
Moin
Okay, deutsche Sprache schwere Sprache! Ich habe nicht das Attribut von Hand nachgetragen, sondern bei denen, wo der Peer nicht automatisch eingetragen wurde, von deren Seite auch noch mal gepeert. Wir kommen aber ab, und ich kann es nur noch aus der Erinnerung sagen!
@curt:
Du solltest das mit dem Peeren und Pairen noch mal genauer durchlesen! Das sind zwei ganz verschiedene Paar Schuhe!
Pairen ist ein Geraet an der Zentrale, hier fhem, anmelden.
Peeren ist zwei Geraete miteinander bekannt machen, wobei hier auch ein virtuelles Geraet ein Peer sein kann!
Gruss Christoph
Zitat von: pc1246 am 25 Juli 2018, 07:03:10
Okay, deutsche Sprache schwere Sprache!
Englische Sprache aber auch, ich bin der lebende Beweis:
Zitat von: pc1246 am 25 Juli 2018, 07:03:10
@curt:
Du solltest das mit dem Peeren und Pairen noch mal genauer durchlesen!
Auftrag erledigt.
Zitat von: pc1246 am 25 Juli 2018, 07:03:10
Peeren ist zwei Geraete miteinander bekannt machen, wobei hier auch ein virtuelles Geraet ein Peer sein kann!
Verstehe ich recht, dass ich meinen ersten in Betrieb befindlichen Rauchmelder mit dem virtuellen "Rauchmelder_Team" peeren kann? Leider scheitere ich an dieser Aufgabe.
Ja, ich habe den Wiki-Eintrag https://wiki.fhem.de/wiki/HM-SEC-SD_Rauchmelder#virtueller_TeamLead gelesen und nachvollzogen - glaube ich zumindest.
Ich muss mal was ganz doofes fragen - ich habe als mein eigener Hausmeister gerade alle meine Fensterkontakte entsprechend #4 aus https://forum.fhem.de/index.php?topic=50918.0 gepeert (obwohl die auch ohne diese Aktion immer artig Ihren Zustand an mein FHEM meldeten - aber jetzt sind diese "peer list incomplete" und "missing register list"-Meldungen weg).
Läuft das darauf hinaus, dass ich
set [Rauchmelder] getConfig absetze und danach den Rauchmelder kurz auf- und wieder zuschraube? Oder was muss ich machen?
P.S:
Bezüglich des Rauchmelders ist anzumerken, dass "
aesCBCCounter" bei mir völlig fehlt. Das ist ja der eigentliche mich verunsichernde Punkt: Im Wiki steht, wie schlimm das ist, wenn da mal etwas schief gehen sollte. Und ich lernte: Ganz vorsichtig sein, ganz langsam machen, immer notfalls erstmal fragen. Dieser Thread halt.
Was mache ich nun damit, dass ich gar kein "
aesCBCCounter" habe?
Das Reading aesCBCCounter findet sich im (virtuellen) Team-Lead, nicht in den einzelnen SDs. Dazu muss der Team-Lead aber erst mal mit wenigstens einem SD korrekt ge-peert sein.
Zitat von: Benni am 30 Juli 2018, 17:46:38
Das Reading aesCBCCounter findet sich im (virtuellen) Team-Lead, nicht in den einzelnen SDs.
Schön wäre das ja. Nichts vorhanden.
Zitat von: Benni am 30 Juli 2018, 17:46:38
Dazu muss der Team-Lead aber erst mal mit wenigstens einem SD korrekt ge-peert sein.
An dieser Aufgabe wäre ich fast gescheitert. Da ich das mit Rauchmelder zum ersten Mal mache, habe ich gesucht und gesucht, inzwischen sicher auch sämtliche Beiträge gelesen, die sich mit Ähnlichem befassen. Ich habe gepeert und gepeert und neu gepairt ... zwischendurch sprach der Rauchmelder gar nicht mehr mit mir. VCCU habe ich inzwischen auch. Nach zig Versuchen (immer identisch nach Wiki-Anleitung) war auf einmal das Peering da, also auf beiden Seiten. hmInfo meldet keinerlei Fehler mehr. Das freut mich.
Allerdings sehe ich
aesCBCCounter nirgendwo. Und irritierenderweise habe ich nun
zwei virtuelle Devices, die sich in Einzelheiten deutlich unterscheiden (z.B mal mit, mal ohne IODev!). Was mache ich denn damit?
Ich zeige das einfach mal:
list HM_5A5754
Internals:
DEF 5A5754
IODev SCC
LASTInputDev SCC
MSGCNT 40
NAME HM_5A5754
NOTIFYDEV global
NR 841
NTFY_ORDER 50-HM_5A5754
SCC_MSGCNT 40
SCC_RAWMSG A12B4A0105A5754FF1312011111110100000000::-58.5:SCC
SCC_RSSI -58.5
SCC_TIME 2018-08-02 18:20:43
STATE off
TYPE CUL_HM
lastMsg No:B4 - t:10 s:5A5754 d:FF1312 011111110100000000
peerList Rauchmelder_Team,
protCmdDel 20
protLastRcv 2018-08-02 18:20:43
protRcv 22 last_at:2018-08-02 18:20:43
protRcvB 1 last_at:2018-08-01 17:18:24
protResnd 13 last_at:2018-08-02 18:18:51
protResndFail 11 last_at:2018-08-02 18:14:11
protSnd 34 last_at:2018-08-02 18:20:43
protSndB 29 last_at:2018-08-02 18:20:42
protState CMDs_done
rssi_SCC cnt:1 min:-47 max:-47 avg:-47 lst:-47
rssi_at_SCC cnt:40 min:-64 max:-38 avg:-53.37 lst:-58.5
READINGS:
2018-08-02 18:16:40 Activity alive
2018-08-02 18:20:28 CommandAccepted yes
2018-08-02 18:16:40 D-firmware 1.0
2018-08-02 18:16:40 D-serialNr OEQ0600470
2018-08-02 18:20:42 PairedTo 0xFF1312
2018-08-02 18:18:10 R-pairCentral 0xFF1312
2018-08-02 18:20:42 RegL_00. 02:01 0A:FF 0B:13 0C:12 16:00 1F:00 00:00
2018-08-02 18:20:28 aesCommToDev ok
2018-08-02 18:20:27 aesKeyNbr 00
2018-08-02 18:16:41 alarmTest ok
2018-08-02 18:16:41 battery ok
2018-08-02 18:16:41 level 0
2018-08-02 18:20:43 peerList Rauchmelder_Team,
2018-08-01 17:20:22 powerOn 2018-08-01 17:20:22
2018-08-02 18:16:41 recentStateType info
2018-08-02 18:20:42 sdRepeat off
2018-08-02 18:16:41 smokeChamber ok
2018-08-02 18:16:41 state off
2018-08-01 17:18:24 trigger_cnt 1
helper:
HM_CMDNR 180
PONtest 0
cSnd 01FF13125A575400040000000000,01FF13125A57540103
mId 00AA
peerIDsRaw ,11111101,00000000
regLst ,0
rxType 6
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +5A5754,00,00,00
nextSend 1533226843.25503
prefIO
rxt 0
vccu
p:
5A5754
00
00
00
mRssi:
mNo B4
io:
SCC:
-52.5
-52.5
prt:
bErr 0
sProc 0
helper:
prt:
rspWait:
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rpt:
IO SCC
flg A
ts 1533226843.15601
ack:
HASH(0x24f2700)
B48002FF13125A575400
rssi:
SCC:
avg -47
cnt 1
lst -47
max -47
min -47
at_SCC:
avg -53.375
cnt 40
lst -58.5
max -38
min -64
shadowReg:
tmpl:
Attributes:
IODev SCC
IOgrp VCCU:SCC
actCycle 099:00
actStatus alive
alias Rauch Flur unten
autoReadReg 4_reqStatus
battery_change 2018-07-19
expert 2_raw
firmware 1.0
model HM-SEC-SD-2
msgRepeat 1
peerIDs 00000000,11111101,
room 13 Rauch
serialNr OEQ0600470
subType smokeDetector
webCmd statusRequest
list Rauchmelder_Team
Internals:
DEF 11111101
NAME Rauchmelder_Team
NOTIFYDEV global
NR 839
NTFY_ORDER 50-Rauchmelder_Team
STATE off
TESTNR 1
TYPE CUL_HM
chanNo 01
device TeamDev
peerList HM_5A5754,
sdTeam sdLead
READINGS:
2018-08-02 18:20:27 peerList HM_5A5754,
2018-08-02 18:20:27 state off
helper:
fkt sdLead2
expert:
def 1
det 0
raw 1
tpl 0
role:
chn 1
vrt 1
shadowReg:
Attributes:
model virtual_1
peerIDs 5A575401,
room 13 Rauch
webCmd press short:press long
list TeamDev
Internals:
DEF 111111
IODev SCC
NAME TeamDev
NOTIFYDEV global
NR 837
NTFY_ORDER 50-TeamDev
STATE ???
TYPE CUL_HM
channel_01 Rauchmelder_Team
READINGS:
helper:
HM_CMDNR 169
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
rssi:
shadowReg:
Attributes:
IODev SCC
expert 2_raw
model virtual_1
room 13 Rauch
subType virtual
webCmd virtual
Hallo curt
Das sieht doch jetzt gut aus. Ich habe genau die gleichen virtuellen Devices wie Du. Dein counter wird schon auftauchen! Mach zum Beispiel mal einen Teamcall von Deinem Rauchmelder_Team. Bei mir hat der sich dann erhoeht!
Gruss Christoph
Zitat von: pc1246 am 03 August 2018, 16:48:22
Das sieht doch jetzt gut aus. Ich habe genau die gleichen virtuellen Devices wie Du.
Hallo Christoph,
also zwei virtuelle Devices ist richtig?
Zitat von: pc1246 am 03 August 2018, 16:48:22
Dein counter wird schon auftauchen! Mach zum Beispiel mal einen Teamcall von Deinem Rauchmelder_Team. Bei mir hat der sich dann erhoeht!
Ich muss noch zwei weitere Rauchmelder pearen und peeren. Tagsüber ist es derzeit nicht möglich, ernsthaft im Haus zu arbeiten. Und Nachts - ich traue mich nicht. Ich habe einen Heidenrespekt vor diesen Sirenen, einmal etwas falsch gemacht und die gesamte Nachbarschaft ruft die Feuerwehr (Dorf am Wald). Daher kein Teamcall, keine Experimente derzeit bei mir.
Zitat von: curt am 05 August 2018, 01:22:36
also zwei virtuelle Devices ist richtig?
Jein! Ja! Das eine ist das virtuelle Device und das andere ist ein Kanal dieses virtuellen Devices.
Peeren kann man, vereinfacht gesagt, nur Kanäle und keine Devices, deshalb ist nachher auch der virtuelle Kanal der Team-Lead und nicht das Device. (Interessant für das Team ist hier auch nur die hmID des Team-Lead, über die die SDs dann quasi miteinander verbunden sind ... das ist aber auch im Wiki so beschrieben).
Der Kanal eines (HM-)Device ist in FHEM normalerweise ebenfalls immer als separates Device verfügbar.
Übrigens macht der Team-Call beim SD2 keinen Lärm, es blinkt lediglich die LED an den SDs im Team grün (oder gar nicht, wenn der Team-Call fehlschlägt)
gb#
Ich gebe zu, dass ich Deinen Text leider nicht verstanden habe.
Es ist eine Geheimsprache, die ich leider nicht übersetzen kann.
Mein aktueller Status:
Die anderen beiden Rauchmelder SD2 habe ich tagelang versucht zu pairen und zu peeren, es war wie bei dem ersten Rauchmelder ein ganz übles Geduldsspiel. Ich weiß nicht, warum die so lange rumzickten. Nun endlich ist das erledigt.
Da ich neuerdings eine VCCU habe, müsste ich eigentlich alle Öffnungskontakte (und ich habe viele) an das VCCU gewöhnen. Die Wiki-Anleitung funktioniert allerdings nicht, im list/filter tauchen die gar nicht erst auf. Und ich habe nicht die geringste Ahnung woran das liegt. Einziger Verdacht: Alle Kontaktgeber aber ich via include aus der fhem.cfg ausgelagert.
Zitat von: curt am 10 August 2018, 02:37:37
Einziger Verdacht: Alle Kontaktgeber aber ich via include aus der fhem.cfg ausgelagert.
Dort ist wahrscheinlich generell das Hauptproblem zu suchen.
Gruß Otto
Zitat von: curt am 10 August 2018, 02:37:37
Da ich neuerdings eine VCCU habe, müsste ich eigentlich alle Öffnungskontakte (und ich habe viele) an das VCCU gewöhnen. ...
...Alle Kontaktgeber aber ich via include aus der fhem.cfg ausgelagert.
Wieso an VCCU gewöhnen? VCCU ist ein Zusatz, um mehrere Homematic-Interfaces gemeinsam zu verwenden. Da man für alle Interfaces die gleiche hmId verwenden sollte, gibt es da gar nichs zu tun außer IOgrp zu setzen. Das geht mit dem einen Befehl aus dem Wiki, das hast Du offenbar versucht, sicher keinen Tippfehler gemacht?
list TYPE=CUL_HM:FILTER=DEF=......:FILTER=subType!=virtual:FILTER=model!=ActionDetectorsollte eigentlich genau alle zu ändernden HM-Geräte (nicht jedoch eventuelle Kanäle) liefern.
Und meine fhem.cfg ist inzwischen 250 kB groß, ohne irgendwelche includes. Und keine Probleme. Aber selbst wenn, sollte das Ändern mit dem Filterbefehl kein Problem sein, oder werden die Änderungen nicht automatisch auch in den Includes weggeschrieben? Hm ...
Zitat von: curt am 10 August 2018, 02:37:37
Ich gebe zu, dass ich Deinen Text leider nicht verstanden habe.
Es ist eine Geheimsprache, die ich leider nicht übersetzen kann.
Ich habe in einem anderen Thread mal versucht mein Verständnis davon zu beschreiben: https://forum.fhem.de/index.php/topic,89770.msg825930.html#msg825930
Zitat von: curt am 10 August 2018, 02:37:37
... via include aus der fhem.cfg ausgelagert.
Ich weiß, es wird meist nicht gerne gehört, und ich möchte hier auch keine neue Diskussion dazu eröffnen (wurde bereits mehrfach geführt) hier dennoch der Hinweis: Lasst eure fhem.cfg in Ruhe! FHEM weiß was es tut und verwaltet die schon richtig, egal in welcher Größe. Und man muss da auch nicht "reinschauen", das geht alles meist besser und vor allem sicherer über FHEMWEB (meinetwegen auch über telnet) direkt.
Wenn ich mitbekomme, dass jemand von Hand in seiner cfg rumdoktert, vor allem wenn er an anderen Stellen auch offensichtlich so seine Verständnisschwierigkeiten hat (keine Kritik daran!), geht meine Hilfsmotivation inzwischen meist ziemlich in den Keller.