Qubino Flush Shutter ZMNHCD1 secure inclusion

Begonnen von gZWm, 20 Juni 2019, 15:38:31

Vorheriges Thema - Nächstes Thema

gZWm

Ich versuche mit dem Qubino eine "secure inclusion". FHEM-seitig sollte alles stimmen, da eine secure inclusion mit einem Fibaro bereits geglückt ist.

Beim Qubino steht im Handbuch:

Parameter No. 250 – Unsecure / Secure Inclusion
Flush Shutter supports secure and unsecure inclusion. If the gateway (hub) does not enable the device to be included as secure, it is included as unsecure while retaining the same functionality.
Values (size is 1 byte dec):
• default value 0
• 0 – Unsecure Inclusion
• 1 – Secure Inclusion


Dummerweise scheint dieser Parameter 250 aber nicht zu existieren, jedenfalls kann ich ihn nicht lesen und blindes Schreiben (set ZWave_SWITCH_MULTILEVEL_XX configByte 250 1) bewirkt nichts.

In der Hoffnung, dass bloss die Adresse falsch ist, habe ich mal herumprobiert und den undokumentierten Parameter 200 gefunden, der auf 0 steht, sowie schreib- und lesbar ist. Aber den auf 1 zu setzen hilft auch nichts, ist wohl doch für irgendwas anderes zuständig. 210 ist ebenfalls vorhanden, steht aber standardmößig auf 14, daher habe ich es damit erst gar nicht probiert.

Hat jemand eine Ahnung, wie man die security beim Qubino erfolgreich aktivieren kann? (Zum Qubino-Support bin ich leider noch nicht durchgedrungen.)

Damu


gZWm

#2
Du must ins "Qubino_Flush-Shutter-PLUS-extended-manual_eng_2.2.pdf" schauen, das in dieser Version aber nicht mehr zum Download angeboten wird.

Tatsache, die haben auch in v2.5 des PDF-Handbuchs den Parameter rausgeworfen (ich hab noch 2.2). Stattdessen steht da jetzt:

"2. Automatic selection of secure/unsecure inclusion"

Gut, vielleicht ist meine Firmware ja neuer als mein Handbuch, und deshalb gibt es den Parameter nicht mehr.

Was aber leider nichts daran ändert, das die "secure inclusion" nicht funktioniert, auch wenn sie jetzt automatisch funktionieren sollte.

Beim Qubino-Support (http://support.qubino.com/support/signup) habe ich meine Email "erfolgreich" registriert, aber keine Zugangsdaten erhalten. UPDATE: Irgendwie habe ich es jetzt vielleicht geschafft, da ein Support-Ticket einzureichen, aber noch keine Antwort bekommen.

harald654

Hallo gzWm,

bist du schon irgentwie weiter gehommen? Ich stehe vor dem gleichen Problem :-\

gZWm

Mittlerweile ja:

Laut Qubino-Support muss man die Nummer des Moduls prüfen, die immer so ähnlich lautet: "ZMNHCD1 H1SxPy"

Wenn da beim "x" eine "5" steht (wie bei mir), dann gibt es das secure-inclusion feature gar nicht. Steht da eine "7", dann sollte es automatisch gehen, also ohne den Parameter, der wiederum nur für eine nie verkaufte Version "6" galt.

Wenn beim "y" eine "2" steht, kann man die Firmware von "5" auf "7" upgraden lassen, aber nur beim Händler oder durch einschicken an Qubino. Steht da eine "1", dann geht das nicht.

Ich selbst habe ein H1S5P2 und ein anderes, dass ich erst ausbauen müßte, um nachzusehen. Überlege noch, was ich nun mache. Ist halt schon ziemlich blöd, wenn's kein OTA-Upgrade gibt.

gZWm

Update:

Habe jetzt noch ein Modul gekauft und ein H1S7P2 erwischt. Damit sollte Secure Inclusion also ja automatisch gehen.
Tut's aber nicht, Ergebnis nach "addNode onSec":
SECURITY --- DISABLED (SECURITY not supported by device)

Wurde also nur wieder bloß nomal inkludiert. Da ist wohl nochmal eine Support-Anfrage fällig...

gZWm

Zitat von: gZWm am 31 Juli 2019, 19:17:07
SECURITY --- DISABLED (SECURITY not supported by device)

Der Support meint, möglicherweise würde FHEM die neueste Version des Moduls nur deshalb nicht secure-inkludieren, weil es bei den alten Versionen ja noch nicht ging und daher noch irgendwo in FHEM das so für das Modul hinterlegt ist. Kann das sein und wenn ja, kann ich da selbst irgendwo ein Flag umstellen?

Ich weiß nicht, ob obige Meldung das Resultat einer tatsächlich versuchten Secure-Inklusion ist oder ob das aus einer statischen Tabelle kommt und dazu führt, dass der Versuch erst gar nicht gemacht wird. Auf letzteres tippt der Qubino-Support, ohne es allerdings explizit mit FHEM getestet zu haben.

rudolfkoenig

ZitatSECURITY --- DISABLED (SECURITY not supported by device)
Diese Meldung kommt, wenn in der Liste der bei der Inklusion gemeldeten Klassen kein SECURITY vorhanden ist.

FHEM aktiviert Verschluesselung so:
- Benutzer setzt in FHEM addNode onSec/onNwSec
- Benutzer startet Inklusion auf dem Geraet (evtl. mit speziellen Tricks fuer Secure)
- Geraet wird "normal" inkludiert, und meldet dabei die Liste aller Klassen
- Vorgang fuer Secure-Inklusion (etliche Funk-Befehle) wird gestartet

Man kann in FHEM z.Zt. diesen letzten Schritt nicht losgeloest von der Inklusion aktivieren, d.h. wenn die SECURE Klasse per Konfigurationsaenderung nach einer "normalen" Inklusion aktiviert wird (und so iterpretiere ich den ersten Beitrag), wuerde das FHEM nicht mehr auswerten.

gZWm

Zitat von: rudolfkoenig am 02 August 2019, 12:19:23
wenn die SECURE Klasse per Konfigurationsaenderung nach einer "normalen" Inklusion aktiviert wird (und so iterpretiere ich den ersten Beitrag), wuerde das FHEM nicht mehr auswerten.

Das sollte laut Qubino aber jetzt nicht mehr der Fall sein (diese Geschichte mit dem Parameter 250, den es deshalb auch gar nicht mehr gibt), sondern mit dem neuen Modul sollte die Inklusion "secure" erfolgen, wenn das Gateway dies so anfragt - mehr ist laut Qubino nicht zu tun.

Aber ich werde nachher mal schauen, was das derzeit normal inkludierte Gerät genau für Klassen gemeldet hat. Oder meldet ein Z-Wave Gerät "secure" nur wenn es bereits sicher inkludiert wurde? Ich kenne den Standard nicht. Aber wenn es so wäre, würde die von Dir beschriebene FHEM-Vorgehensweise ja nie funktionieren - mit dem Fibaro RS3 geht's aber, wenn auch mit anderen Problemen (der meldet nämlich nach secure-Inklusion viel weniger Klassen als normal, und bietet somit dann nur eingeschränkten Funktionsumfang).

rudolfkoenig

Zitatwenn das Gateway dies so anfragt - mehr ist laut Qubino nicht zu tun.
Der Dongle/FHEM "fragt" nicht nach SECURE.
Das Geraet signalisiert im ersten Schritt der Inklusion, ob es Secure kann und FHEM speichert das im classes Attribut ab.
Die Option "onSec/onNwSec" sagt FHEM, dass nach dem ersten Schritt mit dem Secure-Vorgang weitergemacht werden soll, wenn das Geraet die SECURE Klasse unterstuetzt.


gZWm

Mag sein, ich kann ja da mangels eigener Sachkunde nur Qubino (sinngemäß und von E nach D übersetzt) zitieren.

Jedenfalls ist da nichts in den classes was nach "Secure" aussieht. Beim Fibaro hingegen sehe ich dort in den classes "SECURITY SECURITY_S2" auftauchen, außerdem nochmal separat die secure_classes.

Na, dann werd' ich da wohl nochmal beim Support nachhaken müssen...

gZWm

Wie kann ich denn mit FHEM

0X72 COMMAND_CLASS_MANUFACTURER_SPECIFIC
0X06 DEVICE_SPECIFIC_GET

auslesen?

Da soll laut Support der Version-String "ZMNHCD1 H1S7P2" drinstehen. Nur um sicher zu gehen, dass ich auch wirklich die richtige Version habe.

rudolfkoenig

#12
Mit faellt Folgendes ein:

Version 1:
attr ZWDongle verbose 5
get ZWDongle raw 13XX0272062501
wobei XX mit der nodeIdHex des Geraetes zu ersetzen ist.
Danach aus dem FHEM-Log die Antwort studieren oder hier posten.

Version 2:
10_ZWave.pm aendern, und die get Zeile mit {model=>"04"} durch {model=>"04",qfsGet=>"06"} ersetzen.
Eigentlich gehoert auch ein passender Parse-Eintrag dazu, aber dafuer muss man die Antwort kennen, z.Bsp. durch Log studieren, s.o.

gZWm

#13
Zitat von: rudolfkoenig am 07 August 2019, 09:22:22
attr ZWDongle verbose 5
get ZWDongle raw 13XX0272062501
wobei XX mit der nodeIdHex des Geraetes zu ersetzen ist.

Danke, das liefert bei allen meinen drei Modulen (natürlich die node ID immer angepasst):
UNPARSED: MANUFACTURER_SPECIFIC 127207010e5a4d4e4843443120483153355031

Der hintere unterstrichene Teil davon entspricht "ZMNHCD1 H1S5P1" - und das obwohl ich laut Etikett zwei H1S5P2 und ein H1S7P2 habe.

Jetzt hat Qubino aber was zu erklären ... entweder sind die Dinger alle falsch etikettiert, dann kann ich die Dinger nur noch versuchen umzutauschen (denn upgrade geht bei dieser Nummer ja nicht) oder die Etiketten stimmen, aber dann ist die in der Firmware hinterlegte Version falsch, und wir sind genauso schlau wie am Anfang und wissen nicht, warum das eine neuere Modul nicht sicher inkludiert wird.

Oder dritte Möglichkeit: Der oben gefundene String stammt gar nicht aus der Antwort sondern ist irgendwo aus den Tiefen von FHEM entsprungen und dort fest kodiert, vielleicht ein ungewolltes Überbleibsel aus der Entwicklungszeit. Kannst Du das ausschließen? (bevor ich mich zu unrecht bei Qubino beschwere)

rudolfkoenig

ZitatDer hintere unterstrichene Teil davon entspricht "ZMNHCD1 H1S5P1"
Stimmt:fhem> { pack("H*", "5a4d4e4843443120483153355031") }
ZMNHCD1 H1S5P1


ZitatDer oben gefundene String stammt gar nicht aus der Antwort sondern ist irgendwo aus den Tiefen von FHEM entsprungen und dort fest kodiert, vielleicht ein ungewolltes Überbleibsel aus der Entwicklungszeit. Kannst Du das ausschließen?
Ja.