@bb: Bist du dir sicher? Das Geräte sollte, sofern du den Haken im Konfigurator drin hast (für Security) und dann das Gerät frisch anlernst, problemlos beim Laden durch-laufen. Schau mal beim Inkludieren ins Debug vom Z-Wave Konfigurator. Dort gibt es Meldungen ob es korrekt als „Secure“ Gerät angelernt wurde.
paresy
OK, das ist jetzt ein Nebenthema, aber so ganz scheint die Ausage nicht zu stimmen:
Folgender Versuch
Gerät hardwareseitig geresetet, gelöscht und in IPS mit aktiver Security included. eine neue NodeID wurde angelegt.
Dann den PC Controller gestartet, Update gedrückt und das über IPS inkludierte Gerät erscheint in der Nodeliste.
Da kann ich dann sowohl unverschüsselt (die ersten drei Zeilen) als auch verschlüsselt (die nächsten 5 Zeilen) kommunizieren.
Naja, zumindest kommt etwas verschlüsseltes zurück- ob es stimt weiß ich nicht.
Ergo hat der PC Controller Gateway irgendwie den AES Key vom IPS Gateway bekommen.
Ich kann den Node dann über den PC Controller excluden. Kurz darauf wird der Node auch im IPS Konfigurator ROT und bekommt den Typ Unknown. (ob Exclude über Secure läuft weiß ich aber nicht, vermutlich wohl nicht)
Haken ist drin,gespeichert, und Konfigurator neu gestartet.
Hier dass Log.
Beim Laden hängts dann wie bekannt bei der 0x98
In der Klassenansicht gibt es keien haken bei Secure !!!
Die None Get Funktion läuft komplett ohne Verschlüsselung. Siehst du im PC Controller denn eine Liste der Secure Klassen? Auf deinem Bild links ist die Liste der normalen. Müsste dort weiter unten sein.
paresy
Das Gerät wird nicht als Secure angelernt. Mich wundert dass der PC Controller das problemlos macht.
paresy
Ja, so schauts aus.
Jetzt hab ich nochmal die 5.0 hochgefahren und Secure enabled.
Das Gerät wird brav included, danach werden aber auch keine Secure Klassen gefunden.
Dafür gibt es aber auch keine Timeouts und Aktualisieren läuft durch ohne Mecker durch.
Sieht so aus als ob das Teil und auch manche Coolcam Plugs kein Secure mit IPS mögen.
Aber eben 0x98 und 0x9F trotzdem reporten.
Die 5.1 verläßt sich auf vorhandensein von 0x98 und fällt auf die Nase.
Die 5.0 hat das scheinbar irgendwie anders gemacht, darum funktionierte es dort 
Zu erwähnen wäre aber noch das ich von genau dem gleichen Spirit Thermostat mit dem wir nun den ganzen Abend spielen welche mit Secure Klassen im Netz hab. Mit denen läuft auch die 5.1 sauber.
Wie schon mal gesagt, mir persönlich wäre Verschlüsselung ja egal. Nerft eh nur der ganze Sicherheitskram - nicht nur in IPS.
Was wäre wenn du anch dem 0x98 Timeout nicht abbrichst, sondern halt die anderen Klassen weiter abfrägst ?
Dann sollte doch alles wieder laufen - naiv gedacht.
Gehts is recht, wenn nicht Fallback auf unverschlüsselt.
jetzt is aber genug für heute
bb
Moin.
bei den FIBARO Roller Shutter gibt es das reprpduzierbare Problem, dass beim Parameterauslesen zweimal auf Ignorieren geklickt werden muss, da scheinbar die ersten beiden Parameter nicht vorhanden sind bzw. nicht ausgelesen werden können
@herbertf: Das ist dann aber leider ein Fehler von der ZWDB. Wahrscheinlich sind die Parameter für eine andere Firmware Version vom Gerät. Du kannst Chris ja gerne einen Fix für dein Gerät/Firmware einreichen. Dann korrigiert er das bestimmt.
paresy
Magst du mal auf „Laden“ Klicken und mir von dem Gerät das Log schicken? (Der Teil wo BINARY_SENSOR steht ist spannend) Mal sehen ob das Teil weniger Sensoren meldet, als er dann wirklich kann…
paresy
@bb: Nur zur Info: Du kannst aus der settings.json den NetworkKey einfach extrahieren (Copy&Paste) und bei „Override“ im PC Controller eintragen. Dann laufen beide Tools parallel auch mit Security S0 
paresy
Yupp, die Idee hatte ich auch schon - den Key aber nicht gleich gefunden.
Wie gesagt, Security selbst ist mir persönlich nicht so wichtig (andern klarerweise schon).
Wichtig wäre das IPS einfach mit Nodes klarkommt die aus welchen Gründen auch immer nicht Secure included werden konnten, aber trotzdem diese 0x98 oder 0x9f Klasse melden.
Du sagtest ja mal das die diese Information hernimmst um Secure weiterzuarbeiten.
schönen Tag noch
bb
@bb: Ich denke einen Fix für dein „Laden“ Problem zu haben. Kommt im nächsten Update
@herbertf: Das Problem mit den Assoziationen scheint mit dem seit API Version 6 verfügbaren TxStatusReports zusammen zu hängen. Diese deaktivieren wird jetzt explizit, sodass der Effekt weg sein sollte.
Wir haben die Optionen für Acknowledge/Explore wieder entfernt. Acknowledge wird nun automatisch für alle FLiRS Nodes aktiviert. Explore wird automatisch nach dem 2. Fehlversuch (also beim 3. Versuch aktiviert als „letzte“ Rettung), sofern es kein FLiRS Node ist (diese unterstützen Explore nicht)
Das Timeout wird für FLiRS Nodes (die 1000ms Variante) bei Funk-Sendebefehlen immer um 500ms erhöht. (Ansonsten kann es bei 1 Sekunde Timeout etwas knappt werden)
Die ProtocolInfo Meldungen sind nun auch alle weg. Dies habe ich umgearbeitet.
paresy
Hier auch. Hab wie angegeben die aus dem ersten Beitrag neu geladen.
bb
Eine #2 ist im ersten Beitrag.
paresy
Hi
Die aktuelle 600311a4261a ist leider eher ein Rückschritt.
Weder das Spirit Thermostat noch die CoolCam Plugs laufen halbwegs vernünftig durch.
Auf was wollen wir uns konzentrieren um nichts durcheinanderzubringen ?
gruß
bb
Hast du Details? Ich denke die coolcams sind einfacher. Geht denn das Laden immerhin?
paresy
