[Gelöst] Vorhandenes HM-SEC-SD2-Team wie anlernen?

[martinp876]

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?

[Manul]

Vor ca. einer Woche aus dem Debian repository installiert - hat sich seitdem viel getan?

[LuckyDay]

update check
eingeben

[Manul]

Code Auswählen Erweitern

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?

[Manul]

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?

[martinp876]

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.

[frank]

Code Auswählen Erweitern

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.

[Manul]

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".

Code Auswählen Erweitern

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.

Das Register heißt devRepeatCntMax.

Das hat keiner der vier RM.

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:

Code Auswählen Erweitern

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.

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

No regs found for:

og_zi_rauchmelder type:smokeDetector -
list:peer register         :value
   0:      devRepeatCntMax  :0
   0:      pairCentral      :0xFDxxxx

"set og_zi_rauchmelder msgEvents":

Code Auswählen Erweitern

Unknown argument msgEvents, choose one of assignHmKey clear deviceRename fwUpdate getConfig getRegRaw peerBulk peerChan raw regBulk regSet reset sign statusRequest unpair

Da hab ich wohl was falsch verstanden.

[martinp876]

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.

[Manul]

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):

Code Auswählen Erweitern

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:

[martinp876]

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.

[Manul]

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?

[martinp876]

Ü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.

[Manul]

Ü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 dann veraltet?

LazyConfig
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.

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?

[Manul]

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.