Ich habe ein Team von 9 HM-SEC-SD2, die untereinander gepeert aber bis jetzt mit keiner Zentrale gepairt sind. Wie kriege ich die am besten ins FHEM? Einzeln anlernen? Team vorher auflösen? Nur einen anlernen und der Rest wird automatisch entdeckt? Oder wie sonst?
Und auch hier gibt es eine gute Doku: https://wiki.fhem.de/wiki/HM-SEC-SD_Rauchmelder#virtueller_TeamLead
Danke! Da sehe ich allerdings nicht, wie ich bei Rauchmeldern vorgehe, die unabhängig von FHEM bereits ein Team bilden.
Die SD müssen einzeln gepairt werden. Fertig. Ok, prüfen, dass fhem die Register gelesen hat. Tip: hminfo archconfig und configcheck.
Ich bevorzuge einen virtuellen Teamlead. Du kannst es so lassen. Wenn du umstellen willst musst du jeden SD unpeeren und dann mit dem zu erstellenden virtuellen Teamlead peeren.
Danke! Ich habe jetzt den ersten angelernt. Wenn ich ein getConfig ausführe, geht er allerdings zuerst in einen Status "RESPONSE TIMEOUT:RegisterRead" und anschließend in "MISSING ACK". protState ist dann "CMDs_done_Errors:1".
Muß ich den SD2 zum Einlesen der Register nochmal in den Anlernmodus setzen oder gibt's noch was anderes zu beachten?
ich häng mich mal mit einer frage kurz rein, da ich auch grade mit den sd2 am einbinden bin ...
(bisher hat das lesen im forum und im wiki alle fragen beantwortet.
mal abgesehen davon, dass das pairing der sd2 echt gedult braucht, bis die readings komplett gefüllt sind ...
beim anlegen gemäß wiki hab ich ein kleines verständnisproblem.
define TeamDev CUL_HM 111111
laut wiki soll die HMID (hier 111111) ja einmalig sein.
verständnisfrage: ist das die selbe HMID wie auch im VCCU respektive im myHmUART eingetragen ist oder muss das eine andere sein?
Das VCCU sollte nach meinem Verständnis als Zentrale eine 8-stellige HMID haben. Der virtuelle Teamlead bekommt, wie alle anderen Geräte, eine 6-stellige. Die kannst Du frei wählen, sie muß nur eindeutig sein.
Zitat von: Manul am 01 Mai 2017, 15:04:38
Das VCCU sollte nach meinem Verständnis als Zentrale eine 8-stellige HMID haben. Der virtuelle Teamlead bekommt, wie alle anderen Geräte, eine 6-stellige. Die kannst Du frei wählen, sie muß nur eindeutig sein.
Devices haben immer eine 6 Stellige HmID, auch die VCCU
Die Channels haben dann eine 8 Stellige, die HmID vom Device + 2 weitere Stellen. meisst 01 für Channel 1, 02 für Channel 2, usw...
Zitat von: Ricö am 01 Mai 2017, 14:59:32
ich häng mich mal mit einer frage kurz rein, da ich auch grade mit den sd2 am einbinden bin ...
(bisher hat das lesen im forum und im wiki alle fragen beantwortet.
mal abgesehen davon, dass das pairing der sd2 echt gedult braucht, bis die readings komplett gefüllt sind ...
beim anlegen gemäß wiki hab ich ein kleines verständnisproblem.
define TeamDev CUL_HM 111111
laut wiki soll die HMID (hier 111111) ja einmalig sein.
verständnisfrage: ist das die selbe HMID wie auch im VCCU respektive im myHmUART eingetragen ist oder muss das eine andere sein?
Der TeamDev, stellt ein Device dar, somit muss der auch eine EIGENE HmID haben, nicht die der VCCU. Und sie muss halt einmalig sein, nicht dass du ausversehen eine HmID wählst, die schon ein anderes reales HM-Device nutzt, auswählst.
Das TeamDev ist ein virtuelles Device, hat daher eine 6 stellige HmID. Dann bekommt das TeamDev noch einen Channel, der bekommt dann automatisch die HmID vom TeamDev+01 - ist dann also 8 stellig.
Danke für die Korrektur, da hab ich im Gedächtnis wohl was durcheinandergeworfen.
Darf ich nochmal meine Frage ins Gedächtnis rufen?
Zitat von: Manul am 01 Mai 2017, 12:56:28
Muß ich den SD2 zum Einlesen der Register nochmal in den Anlernmodus setzen oder gibt's noch was anderes zu beachten?
Der SD2 steht immer noch auf "RESPONSE TIMEOUT:RegisterRead" (das anschließende "MISSING ACK" blieb beim letzten Versuch aus. protState ist nicht gesetzt.
Ich komme hier leider immer noch nicht weiter. Der SD-2 steht nach wie vor auf "RESPONSE TIMEOUT:RegisterRead". Ich habe einen 2. angelernt, der verhält sich genauso.
Mit dem 2. habe ich jetzt folgendes versucht:
- getConfig -> keine Änderung
- nochmal in den Anlernmodus versetzt -> keine Änderung
- getConfig und unmittelbar danach in den Anlernmodus versetzt -> keine Änderung
Aufgrund der fest verbauten Batterie möchte ich auch nicht beliebig viel mit dem RM experimentieren.
Crypt::Rijndael ist installiert:
reiter@hive:/opt/fhem$ dpkg -s libcrypt-rijndael-perl
Package: libcrypt-rijndael-perl
Status: install ok installed
Priority: optional
Section: perl
Installed-Size: 34
Maintainer: Debian Perl Group <pkg-perl-maintainers@lists.alioth.debian.org>
Architecture: armhf
Source: libcrypt-rijndael-perl (1.12-1)
Version: 1.12-1+b1
Depends: perl (>= 5.20.0-4), perlapi-5.20.0, libc6 (>= 2.4)
Description: Perl module implementing the Rijndael algorithm
Crypt::Rijndael is a Perl module that provides an XS-based implementation of
the Advanced Encryption Standard (AES) algorithm Rijndael, designed by Joan
Daemen and Vincent Rijmen.
Homepage: https://metacpan.org/release/Crypt-Rijndael/
reiter@hive:/opt/fhem$ perlconsole
Perl Console 0.4
[!] rcfile /home/reiter/.perlconsolerc is not readable
Perl> use Crypt::Rijndael
Perl>
Ich habe den Thread zum SD-2 bis Seite 12 gelesen. Da habe ich bis jetzt Leute gefunden, die das gleiche Problem hatten, und welche, bei denen das Anlernen problemlos war. Wie man von Zustand A nach Zustand B kommt, habe ich bis jetzt nicht gefunden.
Ich werde den Thread sicher auch noch bis zum Ende durchackern, wäre aber für jede Hilfe dankbar. Ich scheine ja offenbar irgendwas ganz offensichtliches zu übersehen.
Danke im voraus!
es können viele Details eine Rolle spielen, ich habe damals alle meine SD2 problemlos angelernt. Vor ein paar Wochen habe ich einen SD2 ausgetauscht, da dieser immer Fehlalarme verursachte - bei dem Neuen hatte ich auch Probleme mit beim pairen.
es könnte sein, dass ich beim letzten mal alle IO's bis auf einen deaktiviert hab und dann das pairForSec bei dem eingegeben hab anstatt bei der vccu.
- hast du eine vccu?
- was für IO's nutzt du? CUL / HMlgw / HMlan
Danke! Oh Mann! Wo ist denn hier bitte das Hand-gegen-die-Stirn-klatsch-Smiley?
Meine Vermutung, daß ich was offensichtliches übersehen habe, hat sich bewahrheitet, und dank Deines Posts bin ich auch drauf gekommen, was das war.
:-[ :-[ :-[ :-[ :-[ :-[
Ich hatte vorher ja nur drei HM-Geräte in FHEM eingebunden - und die waren vorher mit einer Zentrale mit der selben HmID gepairt. Deshalb musste ich sie, nachdem autocreate sie angelegt hat, nicht nochmal neu mit FHEM pairen. Die SD-2s waren hingegen vorher gar nicht gepairt - und daher natürlich nach dem Anlegen durch autocreate auch nicht. pairForSec und erneutes Versetzen in den Anlernmodus hat problemlos funktioniert.
Ich hätte aber noch zwei weitere Fragen:
- Fürs getConfig musste ich den SD-2 nochmal in den Anlernmodus setzen. Gibt es eine Möglichkeit, pairen und getConfig mit einem Mal Anlernmodus auszuführen? Sonst muß ich entweder mit dem Laptop durchs Haus oder für jeden SD-2 zwei Mal hin- und herrennen.
- Zusammenhängend damit: Gibt es einen technischen oder konzeptionellen Grund, warum FHEM/CUL_HM beim Anlernen nicht sofort ein getConfig ausführt? Schiene mir irgendwie praktisch.
Um Deine Fragen noch zu beantworten:
Zitat von: automatisierer am 03 Mai 2017, 22:23:46
- hast du eine vccu?
Ja.
Zitat von: automatisierer am 03 Mai 2017, 22:23:46
- was für IO's nutzt du? CUL / HMlgw / HMlan
Einen CUL.
Zitat von: Manul am 04 Mai 2017, 12:28:08
- Fürs getConfig musste ich den SD-2 nochmal in den Anlernmodus setzen. Gibt es eine Möglichkeit, pairen und getConfig mit einem Mal Anlernmodus auszuführen? Sonst muß ich entweder mit dem Laptop durchs Haus oder für jeden SD-2 zwei Mal hin- und herrennen.
- Zusammenhängend damit: Gibt es einen technischen oder konzeptionellen Grund, warum FHEM/CUL_HM beim Anlernen nicht sofort ein getConfig ausführt? Schiene mir irgendwie praktisch.
also ich kann bei meinen SD2 ein getConfig machen, ohne den Button am Gerät drücken zu müssen.
Ist das pairing richtig gelaufen und komplett abgeschlossen?
Zeig mal ein list von einem SD2
Zitat von: automatisierer am 04 Mai 2017, 13:32:16
also ich kann bei meinen SD2 ein getConfig machen, ohne den Button am Gerät drücken zu müssen.
Okay, danke. Vielleicht war ich gestern einfach nicht geduldig genug: Inzwischen scheint auch von dem SD-2, bei dem ich gestern nicht fürs getConfig aufs Knöpfchen gedrückt habe, alles eingetrudelt zu sein, und er steht auf "off". Allerdings ist bei nur R-pairCentral gesetzt, beim anderen auch noch PairedTo. Ich hänge mal beide listings an, vielleicht kannst Du ja mal drüberschauen, ob das okay aussieht.
Erst mal von dem mit Knöpfchen beim getConfig:
Internals:
DEF 4C6619
IODev CUL_0
NAME og_zi_rauchmelder
NOTIFYDEV global
NR 72
NTFY_ORDER 50-og_zi_rauchmelder
STATE off
TYPE CUL_HM
Readings:
2017-05-04 12:29:12 Activity alive
2017-05-04 00:13:14 CommandAccepted yes
2017-05-04 00:15:19 D-firmware 1.0
2017-05-04 00:15:19 D-serialNr NEQ05xxxxx
2017-05-04 00:15:12 PairedTo 0xFDxxxx
2017-05-04 00:13:43 R-pairCentral 0xFDxxxx
2017-05-04 00:15:12 RegL_00. 02:01 0A:FD 0B:9F 0C:7F 16:00 1F:00 00:00
2017-05-04 00:13:14 aesCommToDev ok
2017-05-04 00:13:14 aesKeyNbr 00
2017-05-04 00:15:20 alarmTest ok
2017-05-04 00:15:20 battery ok
2017-05-04 00:15:20 level 0
2017-05-04 00:15:12 peerList dg_sz_rauchmelder,
2017-05-04 00:15:20 recentStateType info
2017-05-04 00:15:12 sdRepeat off
2017-05-04 00:15:20 smokeChamber ok
2017-05-04 00:15:20 state off
Helper:
HM_CMDNR 38
mId 00AA
rxType 6
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +4C6619,00,01,00
prefIO
rxt 0
vccu
p:
4C6619
00
01
00
Mrssi:
mNo
Prt:
bErr 0
sProc 0
Q:
qReqConf 00
qReqStat 00
Role:
chn 1
dev 1
Tmpl:
Attributes:
IODev CUL_0
actCycle 099:00
actStatus alive
alias Rauchmelder 1. Stock Zimmer
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
group Rauchmelder
model HM-SEC-SD-2
msgRepeat 1
room 1. Stock,CUL_HM
serialNr NEQ05xxxxx
subType smokeDetector
webCmd statusRequest Und dann das vom anderen, mit dem fehlenden PairedTo:
Internals:
DEF 4C65F1
IODev CUL_0
NAME dg_sz_rauchmelder
NOTIFYDEV global
NR 59
NTFY_ORDER 50-dg_sz_rauchmelder
STATE off
TYPE CUL_HM
Readings:
2017-05-04 12:29:12 Activity alive
2017-05-04 00:17:54 CommandAccepted yes
2017-05-04 00:17:52 D-firmware 1.0
2017-05-04 00:17:52 D-serialNr NEQ05xxxx
2017-05-04 00:17:52 R-pairCentral set_0xFDxxxx
2017-05-04 00:17:54 aesCommToDev ok
2017-05-04 00:17:53 aesKeyNbr 00
2017-05-04 05:07:42 alarmTest ok
2017-05-04 05:07:42 battery ok
2017-05-04 05:07:42 eventNo 01
2017-05-04 05:07:42 level 0
2017-05-04 05:07:42 recentStateType info
2017-05-04 00:17:52 sdRepeat invalid
2017-05-04 05:07:42 smokeChamber ok
2017-05-04 05:07:42 smoke_detect none
2017-05-04 05:07:42 state off
Helper:
HM_CMDNR 173
mId 00AA
rxType 6
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +4C65F1,00,01,00
prefIO
rxt 0
vccu
p:
4C65F1
00
01
00
Mrssi:
mNo
Prt:
bErr 0
sProc 0
Q:
qReqConf 00
qReqStat 00
Role:
chn 1
dev 1
Tmpl:
Attributes:
IODev CUL_0
actCycle 099:00
actStatus alive
alias Rauchmelder Schlafzimmer
alias_Schlafzimmer Rauchmelder
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
group Rauchmelder
model HM-SEC-SD-2
msgRepeat 1
room CUL_HM,Schlafzimmer
serialNr NEQ05xxxx
subType smokeDetector
userattr alias_Schlafzimmer
webCmd statusRequestZitat von: automatisierer am 04 Mai 2017, 13:32:16
Ist das pairing richtig gelaufen und komplett abgeschlossen?
Wie stelle ich das genau fest? Ich verwende FHEM jetzt seit ca. einer Woche, ist alles noch etwas neu für mich.
R-pairCentral zeigt dir das gepairt ist. pairedTo ist ein Relikt, eine Kopie des Registers. Warum es nicht gesetzt ist kann ich nicht sagen, macht aber nichts.
Allerdings sollte das Register zur Einstellung des repeaters sichtbar sein. Ist deine fhem Installation aktuell?
Vor ca. einer Woche aus dem Debian repository installiert - hat sich seitdem viel getan?
update check
eingeben
List of new / modified files since last update:
UPD ./CHANGED
UPD ./fhem.pl
UPD FHEM/00_ZWDongle.pm
UPD FHEM/01_FHEMWEB.pm
UPD FHEM/10_CUL_HM.pm
UPD FHEM/10_RESIDENTS.pm
UPD FHEM/10_ZWave.pm
UPD FHEM/20_GUEST.pm
UPD FHEM/20_ROOMMATE.pm
UPD FHEM/22_HOMEMODE.pm
UPD FHEM/34_ESPEasy.pm
UPD FHEM/36_Vallox.pm
UPD FHEM/50_HP1000.pm
UPD FHEM/70_BRAVIA.pm
UPD FHEM/70_ENIGMA2.pm
UPD FHEM/70_ONKYO_AVR.pm
UPD FHEM/71_ONKYO_AVR_ZONE.pm
UPD FHEM/71_YAMAHA_AVR.pm
UPD FHEM/72_FB_CALLMONITOR.pm
UPD FHEM/72_FRITZBOX.pm
UPD FHEM/73_km200.pm
UPD FHEM/74_THINKINGCLEANER.pm
UPD FHEM/88_HMCCU.pm
UPD FHEM/88_HMCCUCHN.pm
UPD FHEM/88_HMCCUDEV.pm
UPD FHEM/98_DLNARenderer.pm
UPD FHEM/98_Hyperion.pm
UPD FHEM/98_SVG.pm
UPD FHEM/98_THRESHOLD.pm
UPD FHEM/HMConfig.pm
UPD FHEM/RESIDENTStk.pm
UPD FHEM/UConv.pm
UPD FHEM/Unit.pm
UPD FHEM/myUtilsTemplate.pm
UPD www/pgm2/console.js
New entries in the CHANGED file:
- new: 36_Vallox: support Vallox DigitSE ventilation system
- feature: 71_YAMAHA_AVR: new set command & readings for displayBrightness,
extraBass, surroundDecoder and ypaoVolume
- change: 70_ENIGMA2: HDD capacity is now re-calculated to GB if unit can be
determined
- bugfix: 88_HMCCU: Fixed bug during FHEM start
- feature: 88_HMCCU: New reading based calculation modes
- feature: 34_ESPEasy.pm: Added ESPeasy Mega internals build.*
- bugfix 73_km200.pm: Errorlist unsorted timestamp
- bugfix: 72_FB_CALLMONITOR: fix reverse-search of dasschnelle.at
- feature: 70_BRAVIA: command remoteControl supports 'PictureMode'
- bugfix: 22_HOMEMODE: Use of uninitialized value $d in hash element
minor commandref fix
Ich mach mal ein update und schau mir die Sache dann morgen noch mal an. Muß ich nach dem update nochmal ein getConfig für alle HM-Geräte machen?
So, ich habe mittlerweile ein Update durchgeführt und zwei weitere RM gepairt. Am list hat sich allerdings - bis auf HM_CMDNR - nichts geändert. Wie müsste das Register für den Repeater denn aussehen?
Einer der neu angelernten RM ist im gleichen Zustand, der andere bleibt hartnäckig in "RESPONSE TIMEOUT:RegisterRead" - die config scheint aber übertragen zu sein, R-pairCentral und PairedTo sind gesetzt, die peerList ebenfalls, allerdings ist da nur einer aufgeführt.
Irgendwelche Kommentare?
Das Register heißt devRepeatCntMax.
Das File hmConfig.pm wird vom Update schlecht behandelt. Wenn das veraltet ist könnte es zu so einem Problem kommen.
Mache ein
get sd regList
Damit bekommst du alle Register welche fhem darstellen will. Mit
Get sd regTable
Bekommst du alle gelesenen mit deren Werten.
Weiter: wenn ein registerlesen schief geht dann wird dies durch entsprechende Einträge vermerkt. Mit
Set SD msgEvents
Kann man die Nachricht löschen. Dann noch einmal starten. Wenn nun die Meldung done ohne Fehler kommt ist alles ok.
2017-05-04 00:17:52 R-pairCentral set_0xFDxxxx
solange dort "set_" steht, hat das pairing wahrscheinlich nicht funktioniert. schau dir das wiki pairen an.
einfach öfter drüber pairen und die ts_culfw für den cul installieren.
Update vorneweg: Ohne weiteres Zutun ist zumindest die Timeout-Meldung jetzt bei keinem der RM mehr zu sehen und alle haben brav den state "off".
Zitat von: frank am 05 Mai 2017, 22:43:00
2017-05-04 00:17:52 R-pairCentral set_0xFDxxxx
solange dort "set_" steht, hat das pairing wahrscheinlich nicht funktioniert. schau dir das wiki pairen an.
einfach öfter drüber pairen und die ts_culfw für den cul installieren.
Danke, das hatte ich glatt übersehen. Sieht aus, als wären nur 2 meiner 4 "gepairten" RM wirklich gepairt. Ich werd mir dann erstmal die ts-Firmware installieren und dann die beiden neu und, wenn das klappt, die restlichen pairen.
Zitat von: martinp876 am 05 Mai 2017, 20:29:12
Das Register heißt devRepeatCntMax.
Das hat keiner der vier RM.
Zitat von: martinp876 am 05 Mai 2017, 20:29:12
Das File hmConfig.pm wird vom Update schlecht behandelt. Wenn das veraltet ist könnte es zu so einem Problem kommen.
Aus Neugier: Inwiefern wird das schlecht behandelt? Meine lokale Version enthält zumindest einen Eintrag zu devRepeatCntMax:
reiter@hive:/opt/fhem/FHEM$ grep -i devRepeatCntMax HMConfig.pm
devRepeatCntMax =>{a=> 31.0,s=>1.0,l=>0,min=>0 ,max=>1 ,c=>'' ,f=>'' ,u=>'' ,d=>0,t=>"act as repeater"},
,"HM-SEC-SD-2" =>{ devRepeatCntMax =>1}md5sum der Datei ist f2f72d43ccf7cf76f38203e946c3fb44.
Zitat von: martinp876 am 05 Mai 2017, 20:29:12
Mache ein
get sd regList
Damit bekommst du alle Register welche fhem darstellen will. Mit
Get sd regTable
Bekommst du alle gelesenen mit deren Werten.
regList:
list: register | range | peer | description
0: devRepeatCntMax | 0 to 1 | | act as repeater
0: pairCentral | 0 to 16777215 | | pairing to central
1: sign | literal | | signature (AES) options:off,on
regTable:
No regs found for:
og_zi_rauchmelder type:smokeDetector -
list:peer register :value
0: devRepeatCntMax :0
0: pairCentral :0xFDxxxx"set og_zi_rauchmelder msgEvents":
Unknown argument msgEvents, choose one of assignHmKey clear deviceRename fwUpdate getConfig getRegRaw peerBulk peerChan raw regBulk regSet reset sign statusRequest unpairDa hab ich wohl was falsch verstanden.
Set sd clear msgEvents
Das Register ist sowohl in reglist als auch in der regTable zu sehen. Also alles ok.
Hmconfig würde sonst bei einigen nicht upgedatet und ein Update force war notwendig.
Bevor du das pairing anzweifeln mache ein getconfig. Evtl. Hat nur die Kontrolle versagt.
Hminfo configcheck solltest du testen. Das sollte aufzeigen, wo potentiell Probleme sind. Ebenso hminfo protoevents.
So, ich habe mittlerweile die TSCUL-Firmware drauf. Die SDs scheinen jetzt alle ordentlich gepairt zu sein. Die folgenden Einträge im hminfo configCheck bleiben allerdings auch nach mehreren versuchten getConfigs hartnäckig bestehen (betrifft zwar nicht die Rauchmelder, sondern optische Fensterkontakte, aber vielleicht kann's mir ja trotzdem jemand erklären):
configCheck done:
missing register list
dg_sz_sco_balkon: RegL_00.,RegL_01.,RegL_04.dg_sz_wt_WindowRec,RegL_04.dg_sz_ht_WindowRec
kg_li_sco_kellerfenster: RegL_00.,RegL_01.
peer list incomplete. Use getConfig to read it.
incomplete: kg_li_sco_kellerfenster:
Offensichtlich kennt fhem nicht die Register des Kellerfenster Kontakte.
Wenn du ein getconfig absetzt wird es von Kellerfenster nicht bearbeitet, da es sich um ein device e handelt welches lange schläft. Du musst hier config drücken oder den Kontakt bewegen, falls lacyconfig unterstützt wird.
Mit hminfo protoevents kannst du sehen, dass kein device pending commands hat.
Danke! Wie ist hier das timing? Kann ich die Anlerntaste irgendwann nach dem getConfig drücken oder gibt's da ein begrenztes Zeitfenster?
Ich habe einen CUL_V3 mit der TSCUL-FW. Laut Wiki unterstützt der lazyconfig nicht. Ist das eine Einschränkung der Firm- oder der Hardware?
Über hminfo get Models kannst du sehen, was von einem Model unterstützt wird.
Wenn man config drückt wird eine msg gesendet. Sollten Kommandos in der Queue liegen beginnt fhem mit dem senden.
Zitat von: martinp876 am 08 Mai 2017, 22:05:08
Über hminfo get Models kannst du sehen, was von einem Model unterstützt wird.
Das heißt, es hängt gar nicht vom IO-Device ab, sondern nur vom HM-Device? Ist diese Information im Wiki (https://wiki.fhem.de/wiki/HomeMatic#LazyConfig) dann veraltet?
ZitatLazyConfig
Kommandos in der Queue werden bearbeitet, wenn eine Aktion vom Device ausgeht. So zum Beispiel ein Tastendruck bei einer Fernbedienung. Dieser mode wird von CUL/CUNO nicht unterstützt. FHEM ignoriert diese Option automatisch und wartet i.a. auf ein Config.
Zitat von: martinp876 am 08 Mai 2017, 22:05:08
Wenn man config drückt wird eine msg gesendet. Sollten Kommandos in der Queue liegen beginnt fhem mit dem senden.
Und wenn das Device lazyconfig unterstützt, funktioniert das auch bei jeder anderen msg, die das Device sendet - hab ich das so richtig verstanden?
Update von meiner Seite: Inzwischen sind alle neun Rauchmelder gepairt und werden in FHEM korrekt angezeigt. Danke Euch allen für die Hilfe!
Die Fragen zum lazyconfig sind immer noch offen, aber vielleicht mache ich dafür lieber bei Gelegenheit einen eigenen thread auf.