[Gelöst] Pairing-Probleme mit HM-Sec-Key-S und HM-LC-Sw1-Pl-DN-R1

Begonnen von testit, 14 September 2018, 14:43:42

Vorheriges Thema - Nächstes Thema

testit

Liebes Forum,

nach über einem Jahr benötige ich doch mal wieder eure Hilfe. (Wäre ich ein halbes Jahr früher vorbei gekommen, hätte ich keinen neuen User anlegen müssen :))

Vor einem Jahr hatte ich also meinen Start mit Fhem und den Produkten Homematic. Nach Einleitung lesen und ein paar Fragen lief meine Installation bis heute eigentlich einwandfrei.
Neben dem Funk-LAN Gateway HM-LGW-O-TW-W-EU hatte ich in paar Tür-/Fensterkontakte und einen Bewegungsmelder. Nun sollte eine Funksteckdose (HM-LC-Sw1-Pl-DN-R1) und ein
Türschloss-Antrieb HM-Sec-Key-S hinzukommen. Leider bekomme ich beides nicht gepairt. Hinweise zu diesem Problem gibt es zwar hier im Forum, sind aber leider nicht zielführend.

Nach Inbetriebnahme beider Geräte werden diese durch Autocreate erkannt und es wird auch vom Türschloss der Status übertragen. Allerdings findet sich unter den Readings
kein "PairedTo". Die Befehlseingabe zum Pairen (set Tuerschloss HM_**** 600) wird mit der Meldung beantwortet:
"Unknown argument hmPairForSec, choose one of assignHmKey clear deviceRename fwUpdate getConfig getRegRaw inhibit lock open peerBulk raw regBulk regSet reset sign statusRequest unlock unpair"

Im PullDownMenü des Device zum "SET"-Befehl steht der Pair-Befehl auch gar nicht zur Verfügung, sondern u.a. nur der Unpair.
Komplett resettet und neu installiert ändert sich leider nix.
Dann habe ich erst mal den Funksender an das Türschloss angelernt, was ohne Probleme funktioniert und das Türschloss läßt sich zumindest erst mal so verwenden.

Auch die Steckdose wird durch Autocreate erkannt.
Hier gibt es allerdings den SET Device Pair-Befehl. Und egal, ob ich das Pairing erst vom LAN-Gateway oder vom Device aus starte es schlägt fehl (RESPONSE TIMEOUT:RegisterRead).
Natürlich habe ich die Verschlüsselung mit dem Netfinder zuvor deaktiviert.
Auch hier habe ich einen Reset an der Steckdose durchgeführt und das Pairing erneut versucht oder die Steckdose an anderer Stelle eingesteckt.

Was mache ich falsch, was vergesse ich?

Vielen Dank für jegliche Hilfe und Ratschläge.

Viele Grüße

Beta-User

Zitat von: testit am 14 September 2018, 14:43:42
Was mache ich falsch, was vergesse ich?
Du willst Pairen.

Steht im Wiki, wie es geht: https://wiki.fhem.de/wiki/HomeMatic_Devices_pairen

Da steht auch klar: Das IO-Device ist in den Pairing-Mode (hmPairFor... bzw. pair Serial) zu versetzen, nicht der Aktor usw.. Bei, Türschloss spielt dann auch AES wohl noch eine Rolle, steht aber auch da...

Willkommen im Forum, btw.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

testit

Hallo und vielen Dank für die schnelle Antwort!

Auch diesen Beitrag im Wiki habe ich natürlich gesehen und auch ausprobiert. Und damit man nicht glaubt ich mache mir das mit dem selber lesen nicht zu einfach, habe ich ja auch genau dieses Bsp. in meiner Einleitung oben beschrieben.

Ich setze genau diesen Befehl aus dem Wiki ein "set <Name des IO-Device> hmPairForSec 600" verwendet.
Okay, oben habe ich das nicht richtig geschrieben, aber in der Praxis habe ich das ausgeführt: "set HM_**** hmPairForSec 600".´ und die oben genannte Fehlermeldung erhalten.
Und AES war dann ausgeschaltet.


Otto123

Hi,

öffne mal bitte im Web dein Device "HM-LGW-O-TW-W-EU"
Hinter dem set Befehl kannst Du den hmPair... Befehl auswählen. Den Rest schreibst Du dahinter und drückst vorn auf set.

Wenn Du das nicht findest wirfst Du folgendes oben in die Kommandozeile:
list TYPE=HMUARTLGWund postest Du Ausgabe in Code Tags, die findest Du mit der # Taste über dem Smiley :-X

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Beta-User

Zitat von: testit am 14 September 2018, 14:43:42
Die Befehlseingabe zum Pairen (set Tuerschloss HM_**** 600) wird mit der Meldung beantwortet:

Sorry, dass sich mir bei diesem Text nicht erschlossen hat, dass dein IO Tuerschloss heißt :P ...

Da ist aber dann ein "HM_****" zu viel drin, der Verschreiber sollte wohl für hmPair... stehen, oder?

Weiter unten im Text kommt noch was, was zwar in die richtige Richtung geht, aber die Pairing-Bereitschaft muß man mit der "Seconds"-Methode durch einen Taster am Gerät selbst auslösen, nachdem man das IO "empfangsbereit" gemacht hat. Davon steht aber nix in deinem Text, nur, dass du da was von FHEM aus versucht hast; das steht aber so sicher auch nicht im Wiki 8) .

Schwamm drüber...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

testit

@Otto:
Danke für deine Hilfe, aber ich komme gerade etwas ins Schleudern.
Also ich soll das Langateway aufrufen und den Set-Befehl von dort aus starten?!?
Und was du mit dem "Rest schreibst Du dahinter" meinst wären dann noch die 600?

Und "und postest Du Ausgabe in Code Tags, die findest Du mit der # Taste über dem Smiley" verstehe ich leider gar nicht.

@Beta-User: Ja entschuldige, meine Einleitung war etwas holprig, aber du kannst davon ausgehen ich habe den Befehl so geschrieben, wobei die * für den Rest der HMID stehen:
"set HM_**** hmPairForSec 600" und dann gab es die Fehlermeldung. Ich habe auch versucht vom Gerät aus zuerst das Pairing zu starten, was ja auch nichts hilft. In FHEM gibt es beim Türschloss zu dem Set-Befehl nicht das Pairing im PullDown und die Befehldirekteingabe wie oben führt zu der Fehlermeldung.




Beta-User

Heißt denn dein LAN-GW nach ihrer HmID?

Wenn ja, wäre dein Befehl korrekt gewesen 8) .

Allerdings klingt die Frage nach dem Aufrufen des LAN-GW an Otto so, als wäre das NICHT dasselbe. Sollte es aber sein... Also: Du rufst im Browser die Detailansicht des LAN-GW auf. Da sollte dann auch die set-Optionen für hmPair.... ausgewählt werden können, weil das das IO ist. Dann die Anzahl der Sekunden da rein, Abschicken und Knopf am Gerät drücken.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

testit

Hurra,

Teilerfolg!

Vermutlich hat das Pairing, ausgelöst durch den Set-Befehl im LAN-Gateway, das Pairing mit der Steckdose ermöglicht und im Reading der Steckdose stehen nun die richtigen IDs :)
Und die Steckdose lässt sich schalten ohne Notify anzulegen?!? Scheint jedenfalls von hier aus so auszusehen.

Da liegt also mein Denkfehler. Das "IO" ist das LAN-GW und ich habe verstanden es ist das anzulernende Geräte :-[ :-[ :-[

Das ist ja schon mal schön. Vielen Dank für die Hilfe!!!

Leider bin ich nur per RemoteDesktop auf dem FHEM-Server und kann das Pairing für das Türschloss nicht am Gerät erneut starten, was aber auch nicht ganz ungefährlich ist und man benötigt den bereits an diesem Schloss angelernten Sender (Fernbedienung).  Das geht also erst, wenn ich wieder vor Ort bin und den Sender habe. Bei einem Versuch in der Vergangenheit habe ich es dann auch mal geschafft, das das Pairing zw. Schloss und der Fernbedienung verloren ging und das Schloss nicht mehr reagierte.

Aber so geht schon mal die Steckdose. Dann versuche ich morgen vor Ort das Schloss auch zu pairen.

Nochmal vioelen vielen Dank und schönes Wochenende




Beta-User

Bißchen seltsame Frage, ob man ein Device auch anders als mit notify schalten kann, wenn du FHEM angeblich schon seit mehr als einem Jahr nutzt!

Und es ist nicht "vermutlich" so, dass es geklappt hat, weil du die richtig Vorgehensweise gewählt hast, sondern anders herum wird ein Schuh draus: Es hat funktioniert, weil du es richtig gemacht hast ;) . Alles andere würde auf eine Fehlfunktion hinweisen...

Zitat von: testit am 14 September 2018, 15:55:52
Da liegt also mein Denkfehler. Das "IO" ist das LAN-GW und ich habe verstanden es ist das anzulernende Geräte :-[ :-[ :-[
Wenn das eine Art von Entschuldigung iVm. einem "ich denke zukünftig darüber nach, was mir ein (hoffentlich freundlich gesonnener) Helfer sagen will" sein soll: Angenommen ;D .

Schönes WE und viel Erfolg!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

testit

Keine Frage, mein großer Fehler und sicher auch geschuldet der Tatsache, das ich zu selten mit FHEM arbeite.
Lief bisher ja alles und mein Wiedereinstieg war offensichtlich nicht gründlich genug. Das sollte ich mal ändern, denn es gibt ja noch so viel, was man mit FHEM machen kann.

Beta-User

...war doch gründlich!
Gründlich durchgerüttelt ;) , also: alles gut!

Geh's langsam an, vieles ist nicht sooo einfach, wie es auf den ersten Blick scheint. Und: manches braucht man nicht (oder zumindest nicht gleich), und wenn es bisher so ok war, bedenke bitte, dass die Einarbeitung in FHEM Zeit braucht. Wobei man da zwei Dinge ergänzen/ändern kann: "viel" ergänzen (zu Zeit) und FHEM durch "jedes andere HA-Toolkit" ersetzen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Otto123

Zitat von: testit am 14 September 2018, 15:29:42
Und "und postest Du Ausgabe in Code Tags, die findest Du mit der # Taste über dem Smiley" verstehe ich leider gar nicht.
Damit solltest Du Dich beschäftigen, sonst wird Frage und Antwort Spiel hier etwas schwierig.  :D
Siehe Bild im Anhang 

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

testit

War heute vor Ort und konnte das Pairen mit dem Türschloss machen, was auch funktionierte.

Nun muß ich nur noch ein wenig suchen, wie ich die Befehle zum Schliessen und Öffnen einbinde. Während bei der Anlage der Steckdose gleich zwei Links für Ein- bzw. Ausschalten mit angelegt wurden, fehlen diese beim Türschloss.

Und das mit dem Code-Tag werde ich auch in Zukunft beachten.

Viele Grüße


Beta-User

Denke bei Gelegenheit auch an [gelöst] für den Thread-Titel.

Die Links für die Befehle sollten sich über das Attribut webCmd festlegen lassen (vielleicht gibt es Hinweise dazu im Wiki).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

testit

Bei Attributes steht schon ein webcmd drin mit lock:inhibit on:inhibit off
Im Wiki hat dieses Device noch keine beschrieben. Aber irgendwo werde ich schon eine Liste mit den möglichen Comands finden, die hänge ich dann wahrscheinlich mit dem "attr"-Button und "webCmd" einfach hinter den bestehenden Code.

Wie setze ich denn den Thread-Titel auf gelöst? Eine entsprechende Bezeichnung zu einem Button oder Textlink sehe hier nicht oder ist es der "Thema schliessen"-Link?