Mein KFOB-S ist eingetroffen.
Die beiliegende Anleitung ist verwirrend (insb. die Seitenreihenfolge koennte patentiert werden), ich empfehle das Geraet mit mcaAdd zu konfigurieren (siehe auch mein ZWave.me Remote HOWTO (http://forum.fhem.de/index.php/topic,35513.0.html) , nur die ersten beiden mcaAdds durchfuehren), und die beschriebene Assoziation mit der Gruppen A-D zu ignorieren. Ich habe config 11-14 auf 2 (Switch On/Off only) gestellt, die anderen Werte habe ich nicht probiert. Damit bekomme ich in FHEM fuer zwei Geraete basicSet:00/ff Meldungen, das Geraet ist mit FHEM also grundlegend verwendbar. ModelId ist 0115-0100-0102, und ist noch nicht in unserem (ahem, openzwave) Config-Datenbank zu finden.
Ich habe das Geraet gekauft, um damit Security zu ueben, das wird aber spannend: ein Klasse SECURITY wird gar nicht gemeldet, und im Beipackzettel steht: This devicesupport secure communication when included by a controller that also supports secure communication. Da kann ich ja noch jede Menge lernen. Falls man mir dabei helfen moechte, nur zu :)
Habe den KFOB-S gerade bestellt.
ZitatThis devicesupport secure communication when included by a controller that also supports secure communication.
Dieser Satz taucht bei einigen (allen?) Z-wave plus Geräten mit Security auf. Habe das aber noch nicht im Zwave.me Forum hinterfragt, wie im anderen Thread angekündigt.
ZitatModelId ist 0115-0100-0102, und ist noch nicht in unserem (ahem, openzwave) Config-Datenbank zu finden
Ist bei openzwave schon drin und habe verstanden ;). Wenn Du es kurzfristig brauchst, müsste Du das bitte noch mal selbst einchecken. Bei mir müsstest Du noch bitte ca. 2 Wochen warten....
Bei meinem Z-Wave plus Sensor PST02-1A wird SECURITY im NIF gemeldet und der obige Satz taucht auch in der Anleitung auf. Laut http://www.pepper1.net/zwavedb/device/562 wird bei KFOB-S in der "alten" Hardwareversion 101 auch SECURITY in NIF gemeldet.
Gibt es beim NIF in der "Zwave ohne Plus"-Fassung nicht eine (Längen-)Beschränkung der maximal meldbaren Klassen? Meine ich hätte das mal irgendwo gelesen, finde aber Quelle nicht mehr und könnte das auch verwechseln.
ZitatIst bei openzwave schon drin und habe verstanden
Keine Sorge, wenn ich das so gemeint haette, haette ich es auch so geschrieben.
Dringend ist es nicht, da ich nicht glaube, dass ich das fuer die Security-Spielereien brauche.
Das Ding meldet ZWave Plus (siehe Anhang). Was hat das eigentlich mit den icons auf sich?
ZitatWas hat das eigentlich mit den icons auf sich?
Dadurch kann man wohl programmgesteuert das passende Icon einem Gerät zuordnen. Die Liste für V1: http://220.135.186.178/zwave/example/ZWAVEPLUS%20INFO/Icon_Type/index.html.
Aeon Labs Sirene Gen5 hat 0x0F00 (ICON_TYPE_GENERIC_SIREN) für beide Icon-Typen bei Class V2.
Danach hätte KFOB-S den Generic Type "Remote Control Multi Purpose".
ZitatDas Ding meldet ZWave Plus (siehe Anhang).
Das hatte ich schon vermutet.
Spekuliere eher, dass ZWave plus - Geräte eine neue Variante bei Abfrage NIF anbieten, um alte Längenbeschränkungen bei Anzahl Klassen zu umgehen. Werde bei Gelegenheit noch mal suchen.
Gibt es eigentlich einen Grund, warum in Fhem bei get-Abfragen der ControllerCommands auf die Antwort gewartet wird? Habe bei meinen Experimenten mit den ZWave-Plus Geräten das Problem, dass manche get-ControllerCommands in den Timeout laufen, obwohl eine Antwort danach noch kommt.
ZitatGibt es eigentlich einen Grund, warum in Fhem bei get-Abfragen der ControllerCommands auf die Antwort gewartet wird?
Nur Gewohnheit, das mit "bestellt und kommt irgendwannmal" ist halt gewoehnungsbeduerftig. Wir koennen das Timeout aber gerne hochsetzen, oder die Befehle von get nach set verlagern.
Zitat von: krikan am 13 Mai 2015, 09:11:29
Danach hätte KFOB-S den Generic Type "Remote Control Multi Purpose".
Das war Quatsch. Das wäre umgesetzt auf KFOB-S bei 0x0B "Remote Control Simple".
Zitat
Wir koennen das Timeout aber gerne hochsetzen, oder die Befehle von get nach set verlagern.
Da bin ich nicht tief genug drin, um eine sinnvolle Entscheidung abliefern zu können. Das Problem habe ich im Übrigen bei der gleichen get Abfrage mal und dann wieder nicht.
Also ich hab zwar (noch) kein so ein Gerät, aber interessieren tuts mich trotzdem :)
Kann mir das von der http://zwave.me/index.php?id=31 Seite mal jemand ins deutsche übersetzen:
This device support secure communication when included by a controller that also supports secure communication. The device will then send all commands as secure commands unless the receiving device can not accept them. Then the command is send the normal way automatically.
d.h. bekommst du immer 2 Nachrichten? oder muß das schon beim der Inklusion geschehen?
im z-way-tool könnte ich auf secure/non-secure klicken, wenn ich Geräte hinzufügen will, aber ich befürchte, mein Razberry-Dongle kann das nicht...
Ist zwar nicht direkt KFOB/SECURITY Thema, will aber kein Thread dafuer oeffnen: beim Inclusion wird nicht nur ein "associationAdd 1 ctrlId" durchgefuehrt sondern auch ein "get Name model", natuerlich nur, falls das Geraet die passende Klasse unterstuetzt. Das Ganze ist konfigurabel (init Zeiger in der zwave_class/zwave_deviceSpecial), damit koennen wir je nach Model was anstellen.
Auch eine Ergaenzung mit zusaetzlichen Klassen/etc ist moeglich, allerdings noch nicht programmiert.
Falls jemand eine Wunschliste hat, bitte melden.
Ich habe das Abschicken der Befehle beim WAKE_UP etwas angepasst, mit meinem KFOB kann ich jetzt beim wakeUp auch zwei gets direkt verarbeiten. Hoffentlich habe ich damit nichts kaputtgemacht, wenn doch, bitte melden.
Zitat von: rudolfkoenig am 14 Mai 2015, 21:16:14
Ich habe das Abschicken der Befehle beim WAKE_UP etwas angepasst, mit meinem KFOB kann ich jetzt beim wakeUp auch zwei gets direkt verarbeiten. Hoffentlich habe ich damit nichts kaputtgemacht, wenn doch, bitte melden.
sry. ich bin neu, aber: ging das bisher nicht?
wenn ich 4mal "get config xxx" auf ein wake_up device geschickt hätte, kam nur das letzte an?
Nach etwas Nachdenken bin ich wg. dem alten Verhalten unsicher.
Ich meine, dass ein via notify auf wakeupNotification ausgeloestes get, was nach einem set folgte, in der Warteschlange gelandet ist, und erst nach dem naechsten wakeupNotification abgearbeitet wurde. Oder so :)
So, mein KFOB-S ist angekommen und ich habe die erste Hürde des Seitenzusammenstellung überstanden. Bin aber dafür von der Haptik und Optik positiv überrascht. Kein Vergleich zu meinen bisherigen Erfahrungen mit EnO-Fernbedienungen.
Werde mich ans Testen und Probieren begeben. Rudi, wenn Du besondere Wünsche hast, dann bitte mitteilen. Ansonsten gehe ich zunächst auf Suche nach Class SECURITY; oder hast Du die fehlende Mitteilung bereits geklärt?
Bin nicht wirklich weiter. Irgendwie muessen wir bei der Inclusion dem Geraet signalisieren, dass wir Security koennen/wollen, habe aber noch keine Ahnung wie. Da OpenZwave das angeblich kann, koennte man deren Code studieren, oder jemanden, der sich damit auskennt, fragen.
Leider (jedenfalls was meine Security-Forschung-Prioritaet betrifft) haben die Autoren von Z-Force auf meine Anfrage geantwortet und mir eine CC1101 Konfiguration geschickt, und das macht mich ganz kribbelig: ich will endlich Pakete nativ aus dem CUL sehen. Wenn das klappt, dann hat die Security-Forschung natuerlich sofort mehr Sinn :)
Also die beiden Kommandos im z-way-log zum inkludieren sind schon minimal unterschiedlich. Will gar nicht wissen, wie verschlüsselt das weiter geht... Aber soweit bist sicherlich auch selber gekommen...
Hab leider kein sicheres Gerät :(
Aber ich könnte mir eins bestellen.... :)
[2015-05-15 22:02:24.179] [D] [zway] SETDATA controller.data.secureInclusion = True
[2015-05-15 22:02:26.604] [I] [zway] Adding job: Add/re-include node to network
[2015-05-15 22:02:26.614] [D] [zway] SENDING (cb 0x03): ( 01 05 00 4A C1 03 72 )
wohingegen ohne security:
[2015-05-15 22:01:48.545] [D] [zway] SETDATA controller.data.secureInclusion = False
[2015-05-15 22:01:53.737] [I] [zway] Adding job: Add/re-include node to network
[2015-05-15 22:01:53.743] [D] [zway] SENDING (cb 0x01): ( 01 05 00 4A C1 01 70 )
01 Senden
05 Laenge
00 ??
4A ZZW_ADD_NODE_TO_NETWORK
C1 Parameter
03 Callback-Identifier (damit man weiss, auf welche Frage die Antwort kam)
72 Checksum
D.h. du sendest in beiden Faellen mit dem Parameter C1, der Rest ist gleich oder egal.
Bleibt 0xC1. Hab nicht rausgeriegt, was das Bit 0x40 bedeutet, der Rest ist geich bei
unserem FHEM-Modul, das 0x81 sendet (ANY:0x01 + HIGH_POWER:0x80)
Zitatwas das Bit 0x40 bedeutet,
Tippe auf "network wide inclusion":
- NETWORK_WIDE ist die einzige in der offiziellen Doku erwähnte weitere Option neben HIGH_POWER
- alle opensource-Programme können das AFAIK laut Forum/Quelltext nicht (nutzen alle auch 0x81)
- z-way kann nwi und im Internet habe ich Logs von ISY gefunden, die auch 0xC1 nutzen und nwi unterstützen (http://wiki.universal-devices.com/index.php?title=ISY_Developers:API:REST_Interface)
SECURITY:
Hieraus https://github.com/OpenZWave/open-zwave/commit/e67a4df6f67246e0786035ef98e92d7ee62da63f entnehme ich, dass wohl manche Geräte SECURITY über die Device Classes mitteilen, statt über NIF.
Das WakeupInterval der KFOB-S lässt sich aufgrund eines "known Problem" nicht anpassen: http://forum.z-wave.me/viewtopic.php?f=3423&t=21325&p=56252&hilit=kfob#p55399 . Leider habe ich das erst gesucht und gefunden, nachdem ich schon Ewigkeiten probiert hatte... Alternativlösung zur Batterieschonung steht dort auch.
Mein wakeupInterval scheint zu funktionieren. War urspruenglich zwar auf "604800 0" eingestellt, ich konnte es aber auf "240 1" einstelen (die Nachricht kommt regelmaessig alle 4 Minuten), und danach wieder auf "604800 1", und ich habe jetzt seit ueber 15 Minuten nichts empfangen. Vlt. habe ich eine neue Version (Lib 3 Prot 3.92 App 1.1)
Wg bit 0x40 bin ich noch unsicher, ob wir das auch verwenden sollten, da ich nicht weiss, ob ich sonstnochwas dafuer machen muss. Weiterhin finde ich dass es nicht tragisch ist, ein neues Geraet fuers Inkludieren unweit vom Dongle zu haben.
Meinst du mit "manche Geräte SECURITY über die Device Classes mitteilen, statt über NIF" den Befehl ZW_REQUEST_NODE_INFO bzw createNode?
KFOB-S hat bei mir die gleiche Version. Ich kann beim wakeupInterval einstellen, was ich will. Es bleibt immer bei den 240 Sek, obwohl get den abweichend gesetzten Wert meldet. Ruhe habe ich nur, wenn ich Parameter 25 auf 0 (blocked) setze. Dann kommt keine wakeup notification mehr und ich muss einen Wakeup manuell im Managementmode auslösen.
0x40: Habe testweise mal so inkludiert und kein Problem festgestellt, was aber nichts bedeuten muss. Der openhab-Entwickler hatte in der Mailing-List geschrieben, dass er Explorer Frames nicht eingebaut hat, weil er nicht weiß, was noch zu machen ist. Eigentlich dachte ich, dass Explorer Frames rein hardwargesteuert ablaufen, aber nach der Aussage des Openhab-Entwicklers und einem Blick in zwapi habe ich an meinen Gedanken zu den Explorer Frames meine Zweifel. Inkludieren mit großem Abstand fände ich schon nicht schlecht, kann aber das Risiko nicht abschätzen.
"ZW_REQUEST_NODE_INFO bzw createNode": so verstehe ich openzwave, habe aber selbst noch nicht verstanden, wie man das an der Device Class festmachen soll. Welche soll SECURITY haben und welche nicht? Hatte auf Deine Idee gehofft; suche mal weiter.
Habe mich noch einmal mit dem Thema SECURITY beim KFOB-S beschäftigt; die Erkenntnisse sind aber schmal:
- Abfrage der versionClass SECURITY ergibt 1, also ist die vorhanden - ansonsten müsste es 0 sein - leider habe ich keine Ahnung, wie ich Funktionsfähigkeit von SECURITY testen kann
- bei openzwave wird gerade darüber spekuliert, ob neben den DEVICE Class Angaben aus dem NIF auch die Infos aus CC ZWAVEPLUS_INFO beim Festlegen von CC berücksichtigt werden müssen. Aus der Device Class wird nach SDS10242-17 abgeleitet, welche CCs das Gerät pflichtgemäß haben muss und dies gesetzt (BASIC also immer!). Wie das bei CC ZWAVEPLUS_INFO funktionieren soll, habe ich nicht gefunden, vielleicht hat noch jemand Infos dazu.
Hi,
hab' mich damit jetzt nicht wirklich beschäftigt, aber soweit ich das verstehe, muss direkt beim Includieren ein Key übertragen werden, ansonsten wird Security nicht angeboten...
https://github.com/OpenZWave/open-zwave/blob/master/cpp/src/command_classes/Security.cpp
/* in order to communicate with a Secure Device, we need to send the Network Key to the
* Device with a SecurityCmd_NetworkKeySet packet containing our Network Key.
* Fairly simple right?
*
* BUT
*
* The NetworkKeySet should be done during a inclusion of the device (there is technically a timeout)
* and not at any random time. This means that when including Secure Devices, we must use the OZW AddNode
* Controller Commands, and then once the Inclusion is complete, initiate a NetworkKeySet. Including a
* Secure Device by say using the button on a Z-Stick is technically not possible, as OZW needs to send
* the Network Key right away after negotiating the SecurityScheme (before the timeout).
*
*/
Und laut der Doku zu SECURITY_V1 ist da ja gleich das "volle" Programm nötig:
-Scheme Get / Scheme Report
-Nonce Get / Nonce Report
-Key Set (verschlüsselt!) / Nonce Get
-Nonce Report / Key verify (verschlüsselt!)
Das ganze dann noch mit Timern "gesichert"
Da ist wohl noch 'ne Menge an offenen Punkten zu klären ,-) Die vorhandene Doko ist für mich jedenfalls nicht auf den ersten Blick zu verstehen...
Welche "Quellen" habt Ihr denn? Momentan habe ich dieses SDS11060 und OpenZwave, Krikan hatte dann noch SDS10242 ins Spiel gebracht.
Gibt es eigentlich schon eine AES Implementation in fhem / perl mit der verschlüsselt werden könnte?
Die Befehle von Security kennt Ihr bestimmt schon, oder:
SecurityCmd_SupportedGet = 0x02,
SecurityCmd_SupportedReport = 0x03,
SecurityCmd_SchemeGet = 0x04,
SecurityCmd_SchemeReport = 0x05,
SecurityCmd_NetworkKeySet = 0x06,
SecurityCmd_NetworkKeyVerify = 0x07,
SecurityCmd_SchemeInherit = 0x08,
SecurityCmd_NonceGet = 0x40,
SecurityCmd_NonceReport = 0x80,
SecurityCmd_MessageEncap = 0x81,
SecurityCmd_MessageEncapNonceGet = 0xc1
Gruß,
Andreas.
ZitatUnd laut der Doku zu SECURITY_V1 ist da ja gleich das "volle" Programm nötig
Leider, daher bin ich da programmiertechnisch raus. Hoffe daher auf Forscherdrang von anderen und bin zu Tests bereit.
Keine der von Dir aufgeführten Befehle von SECURITY reagieren -wie eigentlich zu erwarten- auf unverschlüsselte Telegramme.
ZitatSDS10242-17
Das Dokument gibt "nur" Infos zum NIF und den diversen ZWave-Geräteklassen. Problem ist, dass ich mit KFOB-S ein Gerät hier "beworben" habe, dass SECURITY im NIF nicht meldet.
Mehr Infos zu SECURITY kenne ich auch nicht. Am Besten habe ich aber sowieso die Laienerklärung in der Mailinglist von openzwave verstanden.
AES wird vom EnOcean-Modul genutzt. Habe aber keine Ahnung, ob das nicht eine besondere Form ist. Zudem nutzt das WMBUS-Modul AES.
Hi,
mir fehlen da auch noch die Grundlagen von Z-Wave, aber auch Grundlagen zu den internen Abläufen von fhem... Aber man muss sich ja Ziele setzen...
WMBus nutzt eine AES-Implementierung von perl/OpenSSL:
use Crypt::CBC; # libcrypt-cbc-perl
use Digest::CRC; # libdigest-crc-perl
# there seems to be no debian package for Crypt::OpenSSL::AES, so use
# sudo apt-get install libssl-dev
# sudo cpan -i Crypt::OpenSSL::AESDas wäre also schon mal eine Grundlage.
Zitat von: krikan am 23 Mai 2015, 22:12:06
Keine der von Dir aufgeführten Befehle von SECURITY reagieren -wie eigentlich zu erwarten- auf unverschlüsselte Telegramme.
Das Dokument gibt "nur" Infos zum NIF und den diversen ZWave-Geräteklassen. Problem ist, dass ich mit KFOB-S ein Gerät hier "beworben" habe, dass SECURITY im NIF nicht meldet.
Wobei ich das nicht so ganz verstehe... Ein SecurityCmd_NonceGet = 0x40 müsste ja erst einmal mit einem unverschlüsselten SecurityCmd_NonceReport = 0x80 beantwortet werden. Wahrscheinlich wird bei dem Teil die gesamte Security Class abgeschaltet, wenn das nicht bei der Inclusion irgendwie ausgehandelt wurde.
If Network Key Verify fails or the timeout is reached , Trust Center
informs installer and the node must be excluded and included
using same process again. If the process is not attemped again
the included node will not be part of the secure network but will be
present in the network as a non -secure node. The node may
communicate with other non-secure nodes in the networkHast Du evtl. mal die Logmessages/Rohwerte von einem NIF? Am besten wäre natürlich mal zu sehen ob sich der NIF eventuell ändert, nachdem das Gerät ohne Security angelernt wurde. So wie ich es verstanden habe wird ja momentan SECURITY nicht gemeldet, vor der Inclusion sollte das aber eigentlich der Fall sein. Im NIF ist das zweite Byte mit "Security" beschrieben, Bit 7 davon mit "Opt. Func.". Wenn es nichts damit bzw. mit dem NIF zu tun hat, sondern mit ZWAVEPLUS_INFO dann wird es wahrscheinlich erst mal schwierig da an Informationen zu kommen. Wobei das Ding ja bei OpenZWave angeblich voll unterstützt wird. Vielleicht sollte man da noch mal ein "wenig" im Code stöbern und schauen was die so gemacht haben.
Zitat von: krikan am 23 Mai 2015, 22:12:06
Mehr Infos zu SECURITY kenne ich auch nicht. Am Besten habe ich aber sowieso die Laienerklärung in der Mailinglist von openzwave verstanden.
Kannst Du vielleicht mal einen Link auf das Thema in der Maillingliste schicken? Ich habe versucht danach zu suchen, das einzige was ich da gefunden habe, ist das jemand die XML-Definitionsdatei für den KFOB-S erzeugt und eingepflegt hat...
Oh Mann, ich seh' mich schon auch noch so ein Teil kaufen... Habe aber in den nächsten 2 Monaten eigentlich gar keine Zeit für sowas.
Gruß,
Andreas.
Christian: kannst du rauskriegen, was alles was SECURITY betrifft mit openzwave funktioniert? Kann man damit das KFOB sicher ansprechen? Ich vermute wir muessen openzwave als "Doku" verwenden.
@Rudi: Werde testen und berichten. Openzwave hat für die ZwavePlus-SECURITY einen neuen Branch, da es wohl Probleme gab.
@Andreas: Antwort (Rohmessage) und Weiteres folgt in Kürze
Mittlerweile habe ich meine Zweifel, ob ein batteriebetriebenes Gerät ideal für solche Implementationspielereien ist; netzbetriebenes Gerät wäre für Tests einfacher.
Hi Krikan,
Zitat von: krikan am 24 Mai 2015, 12:36:51
@Rudi: Werde testen und berichten. Openzwave hat für die ZwavePlus-SECURITY einen neuen Branch, da es wohl Probleme gab.
Nutzt Du denn OpenZWave? Oder hast die Möglichkeit damit in "real" zu testen? Das wäre dann natürlich sehr hilfreich.
Zitat von: krikan am 24 Mai 2015, 12:36:51
@Andreas: Antwort (Rohmessage) und Weiteres folgt in Kürze
Mittlerweile habe ich meine Zweifel, ob ein batteriebetriebenes Gerät ideal für solche Implementationspielereien ist; netzbetriebenes Gerät wäre für Tests einfacher.
Was für ein netzbetriebenes Gerät würde denn noch Security unterstützen was zugleich günstig ist und leicht erhältlich?
Wenn mit in de pepper Datenbank nach Security filtert ist ja jedes zweite Gerät so ein amerikanisches Door-Lock, dann noch ein paar Sirenen / Rauchmelder.
Allerdings ist mir gerade was aufgefallen wenn man sich die Liste der Command Classes dieser Geräte anschaut:
Command Class Byte Version Support Control In NIF Secure Non Secure
Security 0x98 1 Yes Yes Yes No Yes KFOB-S ZWave.me
Security 0x98 1 Yes Yes Yes No Yes WALLC-S ZWave.me
Security 0x98 1 Yes No Yes Yes Yes SES3 AEON Labs
Es scheint Unterschiede zu geben ob man die Geräte nun Secure oder Non Secure genutzt werden. Wobei ich das irgendwie bei dem KFOB-S dann nicht verstehe... Sollte der SECURITY dann in nur in einer Non Secure Umgebung anbieten?
Die Spalte "In NIF" sagt eigentlich das Security im NIF auftauchen sollte...
Gruß,
Andreas.
P.S.: Der SES3 scheint recht teuer zu sein... ~60-65€
ZitatNutzt Du denn OpenZWave? Oder hast die Möglichkeit damit in "real" zu testen? Das wäre dann natürlich sehr hilfreich.
Noch nicht, aber bald ;). Mein Problem ist eher ein fehlender 2. Controller, damit hier bei den Experimenten nicht alles zusammenbricht.
Zitat
Was für ein netzbetriebenes Gerät würde denn noch Security unterstützen was zugleich günstig ist und leicht erhältlich?
Habe noch eine Aeon Labs Gen5-Sirene AEO_DSD31, die SECURITY kann. Dank der Unterstützung von ungebetenen Besuchern in der Nachbarschaft musste ich die sogar kaufen...
ZitatEs scheint Unterschiede zu geben ob man die Geräte nun Secure oder Non Secure genutzt werden.
Das ist eine der Merkwürdigkeiten, die ich eigentlich noch im Zwave.me Forum hinterfragen wollte. Scheint irgendwie mit den Neuerungen von ZWave+ zusammenzuhängen.
ZitatWobei ich das irgendwie bei dem KFOB-S dann nicht verstehe...
Das http://www.pepper1.net/zwavedb/device/562 ist eine andere Version als Rudi und ich haben. Unsere (0115-0100-0102) scheint neuer zu sein.
Hi Krikan,
Zitat von: krikan am 24 Mai 2015, 14:08:31
Noch nicht, aber bald ;). Mein Problem ist eher ein fehlender 2. Controller, damit hier bei den Experimenten nicht alles zusammenbricht.Habe noch eine Aeon Labs Gen5-Sirene AEO_DSD31, die SECURITY kann.
Yep, das wäre auch mein Problem, ich müsste einen Controller und ein Secure-Gerät kaufen.
Eine Sirene zum Testen ist vielleicht nicht ganz das geeignetste Gerät... Könnte laut werden... Die Experimente mit dem Rauchmelder habe ich noch nicht ganz verdaut...
Zitat von: krikan am 24 Mai 2015, 14:08:31
Dank der Unterstützung von ungebetenen Besuchern in der Nachbarschaft musste ich die sogar kaufen...
Yep, die alte Alarmanlage wurde auch nach einem Einbruchsversuch angeschafft. Nur gibt es da keine Teile, vor allem keine Fernbedienungen mehr zu kaufen. Daher bin ich ja erst mal auf den RFID Leser, Rauchmelder zum Krach machen und einen MP3-Gong für Ansagen umgestiegen (natürlich noch einen Türkontakt und einen Bewegungsmelder). Hat nur den Nachteil das ich die Alarmauslösung dann natürlich etwas verzögern muss, damit man auch Zeit hat das Ding zu entschärfen. (Aber zumindest geht schon mal Licht an und eine Stimme aus dem MP3-Player sagt: "Alarm, Haustür geöffnet"... Damit sollte auch einem Schwachmaten hoffentlich klar sein das er gerade eine Alarmkette ausgelöst hat.
Zitat von: krikan am 24 Mai 2015, 14:08:31
Das ist eine der Merkwürdigkeiten, die ich eigentlich noch im Zwave.me Forum hinterfragen wollte. Scheint irgendwie mit den Neuerungen von ZWave+ zusammenzuhängen.Das http://www.pepper1.net/zwavedb/device/562 ist eine andere Version als Rudi und ich haben. Unsere (0115-0100-0102) scheint neuer zu sein.
Mal sehen, die nächsten 2-3 Wochen ist wenig Zeit, dann ist erst mal Urlaub. Aber ein bischen was geht ja immer ,-)
Gruß,
Andreas.
Zitat von: A.Harrenberg am 24 Mai 2015, 15:02:49
Eine Sirene zum Testen ist vielleicht nicht ganz das geeignetste Gerät... Könnte laut werden... Die Experimente mit dem Rauchmelder habe ich noch nicht ganz verdaut...
Lautstärke kann man bei Sirene- im Gegensatz zum Rauchmelder- einstellen. Und man muss nicht zwangsweise jedesmal Alarm auslösen, Abfragen reichen auch. Eigentlich interessiert mich aber SECURITY bei KFOB-S mehr als bei der Sirene. Ersatzcontroller ist unterwegs...
Hallo Rudi,
KFOB-S lässt sich in openzwave (dieser Branch: https://github.com/OpenZWave/open-zwave/tree/Issue-352-Security) mit SECURITY einbinden. Anliegend Log über Inklusion (mit Network Key: 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, 0x10), manuellem Wakeup und ein bei Tastendrücken.
Secure Inklusion war nur nach Factory Reset und anschließenden Druck auf eine einzelne Taste (siehe Anleitung Seite 1 unter "Installation Guideslines") möglich. Eine secure-Inklusion durch Einschalten des Management Modes und Druck auf Taste 1 (nach vorheriger Exklusion) habe ich nicht hinbekommen.
Bei meinen Experimenten mit Fhem habe ich auch festgestellt, dass mein KFOB-S bei In- und Exklusion recht anspruchsvoll ist. Es funktioniert nicht immer auf Anhieb und ich brauche immer mehrere Anläufe. System habe ich noch nicht erkannt.
Wenn mehr notwendig ist, bitte Testwunsch nennen.
Gruß,Christian
Hi Christian,
Zitat von: krikan am 24 Mai 2015, 15:49:54
Lautstärke kann man bei Sirene- im Gegensatz zum Rauchmelder- einstellen. Und man muss nicht zwangsweise jedesmal Alarm auslösen, Abfragen reichen auch. Eigentlich interessiert mich aber SECURITY bei KFOB-S mehr als bei der Sirene. Ersatzcontroller ist unterwegs...
wie LEISE kann man die denn stellen? Evtl. könnte mir das Ding auch gefallen... Kann man die auf leisester Stufe als Voralarm nutzen der nicht gleich das ganze Haus aufweckt? Und kann man dann jederzeit auf lauten Alarm umstellen?
Gruß,
Andreas.
Hier hat der openzwave-Entwickler Justin allgemein zu SECURITY geschrieben https://groups.google.com/d/msg/openzwave/jIaj0PZ_llc/jOxWlq7I6AYJ . Das stammt aber wohl aus der Zeit vor ZWave+.
@Andreas:
Neben den Dir bekannten SDSxyx-Dokus und den anderen im Wiki verlinkten Quellen, habe ich zum Verständnis der Zusammenhänge bei ZWave nur noch das ZWave-Buch von Paetz. Muss aber gestehen, dass ich das noch nicht von Anfang bis Ende durch habe; es hilft aber oft. Man muss nur bedenken, welche Funktion Paetz hat.
ZitatLEISE kann man die denn stellen? Evtl. könnte mir das Ding auch gefallen... Kann man die auf leisester Stufe als Voralarm nutzen der nicht gleich das ganze Haus aufweckt? Und kann man dann jederzeit auf lauten Alarm umstellen?
Die Lautstärke (und "Melodie") kann man per Config-Parameter einstellen. Lautstärkeunterschiede versuche ich morgen zu testen; bisher habe ich es immer auf max. stehen und das ist LAUT.
Hi Christian,
Zitat von: krikan am 24 Mai 2015, 19:47:41
Hallo Rudi,
KFOB-S lässt sich in openzwave (dieser Branch: https://github.com/OpenZWave/open-zwave/tree/Issue-352-Security) mit SECURITY einbinden. Anliegend Log über Inklusion (mit Network Key: 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, 0x10), manuellem Wakeup und ein bei Tastendrücken.
Secure Inklusion war nur nach Factory Reset und anschließenden Druck auf eine einzelne Taste (siehe Anleitung Seite 1 unter "Installation Guideslines") möglich. Eine secure-Inklusion durch Einschalten des Management Modes und Druck auf Taste 1 (nach vorheriger Exklusion) habe ich nicht hinbekommen.
wow, das hat Dir dann wohl keine Ruhe gelassen... ,-)
Ich habe mal kurz in die Datei reingeschaut, auf Anhieb aber noch nicht viel davon verstanden. Aber eine Frage hätte ich schon mal, was ist Node 1 und Node 6? Der KFOB wird ja unter Node 2 eingebunden...
EDIT: Die Frage nach Node 1 ziehe ich zurück... ,-) Node 6 bleibt aber weiter offen...
Aber das sind jetzt "mal eben" 1100 Zeilen, da muss man erst mal die interessanten Stellen finden und rauspicken. Ich denke mal Rudi und Du ihr seid da wesentlich effektiver als ich, aber ich schau da trotzdem noch mal rein und versuche nachzuvollziehen was da passiert. Kann das dann ja mit euren Erkenntnissen abgleichen ,-)
Gruß,
Andreas.
Zitat von: A.Harrenberg am 24 Mai 2015, 20:19:41
Ich habe mal kurz in die Datei reingeschaut, auf Anhieb aber noch nicht viel davon verstanden. Aber eine Frage hätte ich schon mal, was ist Node 1 und Node 6? Der KFOB wird ja unter Node 2 eingebunden...
1 ist der Controller.
6 ist Fehlversuch. Warum 6 erschließt sich mir leider nicht, da der Controller vorher zurückgesetzt war.
Zitat6 ist Fehlversuch. Warum 6 erschließt sich mir leider nicht, da der Controller vorher zurückgesetzt war.
Gegen Fehlversuch spricht nach nochmaliger Durchsicht, dass 6 auch nach 2 noch auftaucht. Verstehe ich gerade nicht.
Hi,
Zitat von: krikan am 24 Mai 2015, 20:40:59
Gegen Fehlversuch spricht nach nochmaliger Durchsicht, dass 6 auch nach 2 noch auftaucht. Verstehe ich gerade nicht.
macht nix, da tauch zwischendurch ja auch noch eine Node 15 auf ;-)
Soweit ich mich gerade durchgearbeitet habe wird bein Include schon noch SECURITY gemeldet.
Gruß,
Andreas.
Gleicher Test noch einmal; Log wieder angehängt:
Es gibt wieder für mich nicht verständliche Nodes: 6, 15, 22, 32 45 146, 156, 172 und 215.
In der "richtigen" Nodeliste von Openzwave tauchen die nicht auf; Bedeutung?
Inkludiere jetzt mal die Sirene und liefer das Log.
Anliegend openzwave-Log für secure-Inklusion von DSD31.
Nach Durchsicht openzwave-Mailinglist dürften die meisten SECURITY-Geräte mit openzwave funktionieren. Probleme gab es wohl noch mit den ZWave+-Geräten, die ich hier ausschließlich eingebunden habe. Der von mir genutzte Branch soll in Kürze im Master übergehen; wird aber derzeit von den auf openzwave aufsetzenden Programmen teilweise schon eingesetzt. Dürfte also einen gewissen Reifegrad erlangt haben.
Ich habe angefangen KFOB-S-SECURITY 2.Test.txt zu lesen. Aufgefallen:
- bei der Initialisierung der Dongle werden ueberfluessig erscheinende Calls wie GET_RANDOM/SET_TIMEOUTS abgesetzt.
- bei der Inclusion wird dasselbe Befehl/Parameter wie im FHEM Modul gesendet (addNode on), allerdings meldet (um 22:18:45.075) Node 2 auch die Klasse SECURITY zurueck (0x98). Vmtl sind die vorherigen Befehle gar nicht so ueberflussig.
- danach geht es los mit dem Schluesselspiel: SchemeGet,SchemeReport,NetworkKeySet,NonceGet,NonceReport.
- ein anschliessendes GET_NODE_PROTOCOL_INFO meldet aber security false. (?)
- danach wird NO_OP(?), wakeupInterval get/set, model get gesendet, scheinbar alles ohne Verschluesselung.
- das naechste Befehl wird verschluesselt gesendet/empfangen, verstehe es aber noch nicht so gut, da ich security nicht kenne.
-> Als naechstes muessen wir mMn beim Controller-Initialisieren set_timeout/get_random absetzen, und schauen, ob es bei der Inklusion SECURITY gemeldet wird.
Hi Krikan, hi Rudi,
uff, Information overflow...
Ich habe Schwierigkeiten die Nachrichten von OpenZWave zu decodieren/verstehen...
Laut SDS10243-2 ist das Frame Layout
Home ID [..]
Source Node ID
Frame Header [..]
Length
Destination address [..]
Data byte 0-x
[..]
Checksum
Wobei ich die [..] so deute das hier mehrere Bytes stehen können. Für den Frame Header und die Destination address kann ich das nachvollziehen, aber für die Home ID??
Hier mal als Beispiel die Zeile 39 aus dem ersten File von Krikan
2015-05-24 19:20:35.914 Info, Node002, Sending (Security) message (Callback ID=0x0d, Expected Reply=0x04)
SecurityCmd_SchemeGet (Node=2): 0x01, 0x0a, 0x00, 0x13, 0x02, 0x03, 0x98, 0x04, 0x00, 0x25, 0x0d, 0x53
"Wo" im Transfer Layer befindet man sich hier? Was ich "rausfischen" kann ist:
0x01, Node ID?
0x0a, Länge
0x00, ??
0x13, 'ZW_SEND_DATA'??
0x02, ?? Destination Node ??
0x03, ?? Länge ??
0x98, COMMAND_CLASS_SECURITY
0x04, SECURITY_SCHEME_GET
0x00, Supported Security Schemes (0=normal Power)
0x25, ??
0x0d, ?? Callback ID ??
0x53 Checksum?
Das kann ich aber nicht dem Format des Transfer Layers zuordnen. Für was stehen die ganzen anderen Werte? Scheme_Get hat z.B. nur einen Parameter, in diesem Fall 0x00, für was steht dann die 0x25?
Und was hat es mit dieser CallbackID auf sich? Kann man hier Nachrichten "nummerieren" und die Antwort enthält diese Nummer?
Für einen "Schubs" in die richtige Richtung wäre ich sehr dankbar. Ohne richtige Doku ist das schon recht mühselig, gibt es da Doku ich mir ansehen kann um das zu verstehen? Bisher habe ich da leider so gut wie gar nichts im Netz gefunden.
Danke,
Andreas.
Hallo Rudi,
Zitat von: rudolfkoenig am 25 Mai 2015, 09:35:38
Ich habe angefangen KFOB-S-SECURITY 2.Test.txt zu lesen. Aufgefallen:
- bei der Initialisierung der Dongle werden ueberfluessig erscheinende Calls wie GET_RANDOM/SET_TIMEOUTS abgesetzt.
- bei der Inclusion wird dasselbe Befehl/Parameter wie im FHEM Modul gesendet (addNode on), allerdings meldet (um 22:18:45.075) Node 2 auch die Klasse SECURITY zurueck (0x98). Vmtl sind die vorherigen Befehle gar nicht so ueberflussig.
- danach geht es los mit dem Schluesselspiel: SchemeGet,SchemeReport,NetworkKeySet,NonceGet,NonceReport.
- ein anschliessendes GET_NODE_PROTOCOL_INFO meldet aber security false. (?)
- danach wird NO_OP(?), wakeupInterval get/set, model get gesendet, scheinbar alles ohne Verschluesselung.
- das naechste Befehl wird verschluesselt gesendet/empfangen, verstehe es aber noch nicht so gut, da ich security nicht kenne.
-> Als naechstes muessen wir mMn beim Controller-Initialisieren set_timeout/get_random absetzen, und schauen, ob es bei der Inklusion SECURITY gemeldet wird.
zu den Timer steht in der Doku das die auf jeden Fall ab "Nonce report" gesetzt werden müssen, der Timer für "Nonce get" ist nur "recommended". Für die Inclusion sind da aber auch 10 sekunden Timer angegeben. Falls das ganze an irgendeiner Stelle mal länger als 10 sekunden für einen der Schritte benötigt wird die "secure Inclusion" abgebrochen.
SDS11060-7 S. 238 (250 im PDF) und Grafik auf S. 240 (252 im PDF).
Ich würde das aber so verstehen als ob die Timer da nicht gesetzt werden müssen. Aber vielleicht ist das ja eine Änderunge in ZWavePlus?
Security wird auch im ersten File (2015-05-24 19:20:34.745) gemeldet. Meine Vermutung war ja, das bei der Inclusion Security im NIF gemeldet wird, wenn das "secure Inclusion" fehlschlägt die Klasse danach aber nicht mehr gemeldet wird.
Ist denn wirklich sicher das der KFOB direkt bei der Inclusion mit fhem das Security nicht sendet? Oder wird das evtl. erst nach der Inclusion noch mal abgefragt?
Der KFOB-S unterstützt security auch nicht für alle Klassen, sondern nur für diese: (laut Pepper)
Multi Command Encapsulated 0x8F
Central Scene 0x5B
Basic 0x20
Scene Activation 0x2B
Multilevel Switch 0x26
Door Lock 0x62
Multi Channel 0x60
, alle anderen sind "non Secure".
Gruß,
Andreas.
Zitat von: rudolfkoenig am 25 Mai 2015, 09:35:38
- bei der Initialisierung der Dongle werden ueberfluessig erscheinende Calls wie GET_RANDOM/SET_TIMEOUTS abgesetzt.
Solche Initialisierungen macht zway auch. Habe ich nach meiner Erinnerung im zway-Log von Micha80 aus einem anderen Thread gesehen. Würde ich mir im Detail anschauen, wenn ich wieder zu Hause bin.
Zitat von: A.Harrenberg am 25 Mai 2015, 09:38:15
Und was hat es mit dieser CallbackID auf sich? Kann man hier Nachrichten "nummerieren" und die Antwort enthält diese Nummer?
Beim Verschicken der Nachricht übergibt man eine laufende Callback-ID. Die passende Antwort enthält dann die Callback-ID als Zuordnungskriterium, da die irgendwann kommt. Bei meinen Forschungen zu den Explorer Frames habe ich noch Probleme mit den Callback-IDs, da (Vermutung) Fhem keine fortlaufende Nummer vergibt.
ZitatDer KFOB-S unterstützt security auch nicht für alle Klassen, sondern nur für diese: (laut Pepper)
Vorsicht, da das eine andere Version des KFOB-S ist. Die hat SECURITY im NIF und dass wir die SECURITY im NIF nicht erkennen, obwohl es überall sonst in FHEM funktioniert ist ungewöhnlich. Laut http://www.intellihome.be/en/z-wave-usb-stick.html und der Angabe dort "Extended support Node Information Frame (up to 20 Command Classes possible)" ist aber nichts unmöglich. Kann dazu aber keine weiteren Infos im Netz finden.
Zitat
Ohne richtige Doku ist das schon recht mühselig, gibt es da Doku ich mir ansehen kann um das zu verstehen?
Mehr kenne ich auch nicht.
Hi Krikan,
Zitat von: krikan am 25 Mai 2015, 11:10:53
Beim Verschicken der Nachricht übergibt man eine laufende Callback-ID. Die passende Antwort enthält dann die Callback-ID als Zuordnungskriterium, da die irgendwann kommt. Bei meinen Forschungen zu den Explorer Frames habe ich noch Probleme mit den Callback-IDs, da (Vermutung) Fhem keine fortlaufende Nummer vergibt.
In den OpenZWave Logfiles von Dir ist das ja so der Fall, da kommen immer wieder Antworten die dann auch diese Callback-IDs haben. Allerdings sind dazwischen auch "received" messages ohne diese Callback-IDs, das dürften dann Nachrichten sein die automatisch geschickt werden, also ohne Anfrage, wie z.B. ein Tastendruck. Ob fhem diese Nummern vergibt habe ich mir noch nicht angesehen, könnte sein das dies in ZWDongle intern passiert und der Teil der Nachrichten gar nicht mehr gemeldet/angezeigt wird.
Zitat von: krikan am 25 Mai 2015, 11:10:53
Vorsicht, da dass eine andere Version des KFOB-S ist. Die hat SECURITY im NIF und das wir die SECURITY im NIF nicht erkennen, obwohl es überall sonst in FHEM funktioniert ist ungewöhnlich. Laut http://www.intellihome.be/en/z-wave-usb-stick.html und der Angabe dort "Extended support Node Information Frame (up to 20 Command Classes possible)" ist aber nichts unmöglich.
Das ist ja gerade das Merkwürdige, bei der Inclusion in OpenZWave wird ja SECURITY in dem NIF gesendet, in fhem aber anscheinend nicht. Habt Ihr eventuell auch ein Logfile von der Inclusion in fhem? Wird die Information über die Klassen in fhem aus dem NIF während der Inclusion gebildet oder wird der später noch mal abgefragt?
Was das mit dem "extended" soll kann ich mir auch nicht erklären. Warum sollen da 20 CC was besonderes darstellen? Die Anzahl der CCs im NIF ist ja eigentlich nicht beschränkt, außer das die gesamtlänge des Frames beschränkt ist, das reicht aber für weit mehr 20 CCs... Und an dem Format kann ich jetzt auch nichts besonderes erkennen, es kommen die supported CCs dann MARK dann die controlled CCs.
Die Frage wäre was sich in den "reserved" Bytes/Bits des NIF versteckt.
Im ersten Byte ist ja bit 7 das "listening", der KFOB meldet hier 0x03
Im zweiten Byte ist bit 7 "opt.func.", der KFOB meldet hier 0x02
das dritte Byte ist "reserved, Z-Wave protocol specific part" und meldet 0x19
D.h. hier sind noch drei Werte die eventuell etwas im Zusammenhang mit Security zu bedeuten haben, Ich denke da müsste man (auch) mal im Code von OpenZWave schauen ob diese Info dekodiert wird und für irgendwas wichtig ist.
Zitat von: krikan am 25 Mai 2015, 11:10:53
Kann dazu aber keine weiteren Infos im Netz finden.Mehr kenne ich auch nicht.
Schade, dann ist wohl wirklich die Analyse des Codes gefragt, bzw. die Links die Rudi in ZWDongle hinterlegt hat.
Gruß,
Andreas.
Das FHEM Modul vergibt z.Zt. das Geraete-NodeID als Callback-Id, ausgewertet wird es aber nicht. Im IODev (ZWDongle) gibt es auch einen CallbackNr, der wird aber nur fuer die ZWDongle Funktionen verwendet. Um den CallbackNr sinnvoll zu verwenden, musste man Threads (oder sowas aehnliches) mit Suspend/Terminate/etc implementieren, und das ist mir im Moment noch zuviel.
Hi,
wollte nur mal mitteilen das ich mir jetzt gerade so eine Sirene und einen weiteren USB-Stick bestellt habe...
Dürfte einfacher sein mit Hardware zum spielen und wenn man selbst ein paar Logeinträge zum debuggen setzen kann. Mit meinem RFID-Keypad zu spielen macht auch keinen "Spass", das ist ja auch Batteriebetrieben und hängt im Flur...
Wie sieht das eigentlich damit aus einen ZWave-USB-Stick in fhem durch einen anderen zu ersetzen? In Homematic wird der USB-Stick ja über ein LAN-Modul eingebunden, dem kann man eine beliebige ID zuordnen und er wird unter eine IP angesprochen. Tauscht man den Stick aus läuft das System einfach weiter. (Ist erfolgreich getestet, meinen ersten Stick hab' ich mal abgebrochen, ersetzt und später wieder durch den reparierten ausgetauscht...)
Das geht dann ja bei ZWave nicht, hier müsste man alle Geräte ablernen und neu einbinden, oder?
Gruß,
Andreas.
Zitat von: rudolfkoenig am 25 Mai 2015, 12:02:17
Das FHEM Modul vergibt z.Zt. das Geraete-NodeID als Callback-Id, ausgewertet wird es aber nicht. Im IODev (ZWDongle) gibt es auch einen CallbackNr, der wird aber nur fuer die ZWDongle Funktionen verwendet. Um den CallbackNr sinnvoll zu verwenden, musste man Threads (oder sowas aehnliches) mit Suspend/Terminate/etc implementieren, und das ist mir im Moment noch zuviel.
Funktional sehe ich derzeit keine Einschränkungen. Es gehen nach meinem Verständnis doch nur die Angaben zu fehlenden Antworten im Modul verloren=Statistik. Das ist unwichtig. Bei den Explorer Frames war mir das Thema nur aufgefallen, da die Logs bei verbose 5 momentan teilweise "komisch" sind; Funktional auch bei Explorer Frames kein Problem. Ich habe versucht das Log-Thema zu lösen, bin aber nicht weiter. Vielleicht sollte ich mal mit einer aktuellen 10_ZWave.pm aus dem svn neu anfangen und das "Problem" löst sich von alleine, da ich mich verbastelt habe...
@Andreas: So sieht eine Inklusion des KFOB-S in Fhem aus:
2015.05.23 14:18:07 5: SW: 0105004a810233
2015.05.23 14:18:08 5: ZWDongle/RAW: /060107004a02010000b1
2015.05.23 14:18:08 5: SW: 06
2015.05.23 14:18:08 5: ZWDongle_Read ZWDongle_0: 004a02010000
2015.05.23 14:18:08 5: ZWDongle_0 dispatch 004a02010000
2015.05.23 14:18:08 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:01 ARG:0000
2015.05.23 14:18:08 4: ZWDongle_0 ZW_ADD_NODE_TO_NETWORK learnReady
2015.05.23 14:18:18 5: ZWDongle/RAW: /0107004a02020000b2
2015.05.23 14:18:18 5: SW: 06
2015.05.23 14:18:18 5: ZWDongle_Read ZWDongle_0: 004a02020000
2015.05.23 14:18:18 5: ZWDongle_0 dispatch 004a02020000
2015.05.23 14:18:18 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:02 ARG:0000
2015.05.23 14:18:18 4: ZWDongle_0 ZW_ADD_NODE_TO_NETWORK nodeFound
2015.05.23 14:18:21 5: ZWDongle/RAW: /0107004a02070700b0
2015.05.23 14:18:21 5: SW: 06
2015.05.23 14:18:21 5: ZWDongle_Read ZWDongle_0: 004a02070700
2015.05.23 14:18:21 5: ZWDongle_0 dispatch 004a02070700
2015.05.23 14:18:21 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:07 ARG:0700
2015.05.23 14:18:21 4: ZWDongle_0 ZW_ADD_NODE_TO_NETWORK failed
2015.05.23 14:19:11 5: SW: 0105004a0503b6
2015.05.23 14:19:11 5: ZWDongle/RAW: /060107004a03060700b0
2015.05.23 14:19:11 5: SW: 06
2015.05.23 14:19:11 5: ZWDongle_Read ZWDongle_0: 004a03060700
2015.05.23 14:19:11 5: ZWDongle_0 dispatch 004a03060700
2015.05.23 14:19:11 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:06 ARG:0700
2015.05.23 14:19:11 4: ZWDongle_0 ZW_ADD_NODE_TO_NETWORK done
2015.05.23 14:19:12 5: ZWDongle/RAW: /0107004a03060700b0
2015.05.23 14:19:12 5: SW: 06
2015.05.23 14:19:12 5: ZWDongle_Read ZWDongle_0: 004a03060700
2015.05.23 14:19:12 5: ZWDongle_0 dispatch 004a03060700
2015.05.23 14:19:12 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:06 ARG:0700
2015.05.23 14:19:12 4: ZWDongle_0 ZW_ADD_NODE_TO_NETWORK done
2015.05.23 14:19:30 5: SW: 0105004a810435
2015.05.23 14:19:31 5: ZWDongle/RAW: /060107004a04010000b7
2015.05.23 14:19:31 5: SW: 06
2015.05.23 14:19:31 5: ZWDongle_Read ZWDongle_0: 004a04010000
2015.05.23 14:19:31 5: ZWDongle_0 dispatch 004a04010000
2015.05.23 14:19:31 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:01 ARG:0000
2015.05.23 14:19:31 4: ZWDongle_0 ZW_ADD_NODE_TO_NETWORK learnReady
2015.05.23 14:19:42 5: SW: 0105004a0505b0
2015.05.23 14:19:43 5: ZWDongle/RAW: /060107004a05060700b6
2015.05.23 14:19:43 5: SW: 06
2015.05.23 14:19:43 5: ZWDongle_Read ZWDongle_0: 004a05060700
2015.05.23 14:19:43 5: ZWDongle_0 dispatch 004a05060700
2015.05.23 14:19:43 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:06 ARG:0700
2015.05.23 14:19:43 4: ZWDongle_0 ZW_ADD_NODE_TO_NETWORK done
2015.05.23 14:20:01 5: SW: 0105004a810637
2015.05.23 14:20:01 5: ZWDongle/RAW: /060107004a06010000b5
2015.05.23 14:20:01 5: SW: 06
2015.05.23 14:20:01 5: ZWDongle_Read ZWDongle_0: 004a06010000
2015.05.23 14:20:01 5: ZWDongle_0 dispatch 004a06010000
2015.05.23 14:20:01 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:01 ARG:0000
2015.05.23 14:20:02 4: ZWDongle_0 ZW_ADD_NODE_TO_NETWORK learnReady
2015.05.23 14:20:07 5: ZWDongle/RAW: /0107004a06020000b6
2015.05.23 14:20:07 5: SW: 06
2015.05.23 14:20:07 5: ZWDongle_Read ZWDongle_0: 004a06020000
2015.05.23 14:20:07 5: ZWDongle_0 dispatch 004a06020000
2015.05.23 14:20:07 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:02 ARG:0000
2015.05.23 14:20:08 4: ZWDongle_0 ZW_ADD_NODE_TO_NETWORK nodeFound
2015.05.23 14:20:08 5: ZWDongle/RAW: /011e004a06030a170412025e8f7398867270852d8e80845a595bef205b2627f6
2015.05.23 14:20:08 5: SW: 06
2015.05.23 14:20:08 5: ZWDongle_Read ZWDongle_0: 004a06030a170412025e8f7398867270852d8e80845a595bef205b2627
2015.05.23 14:20:08 5: ZWDongle_0 dispatch 004a06030a170412025e8f7398867270852d8e80845a595bef205b2627
2015.05.23 14:20:08 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:03 ARG:0a170412025e8f7398867270852d8e80845a595bef205b2627
2015.05.23 14:20:08 2: autocreate: define ZWave_SWITCH_REMOTE_10 ZWave e345c452 10 5e8f7398867270852d8e80845a595bef205b2627
2015.05.23 14:20:08 2: autocreate: define FileLog_ZWave_SWITCH_REMOTE_10 FileLog ./log/ZWave_SWITCH_REMOTE_10-%Y.log ZWave_SWITCH_REMOTE_10
2015.05.23 14:20:09 2: ZWave set ZWave_SWITCH_REMOTE_10 associationAdd
2015.05.23 14:20:09 5: SW: 010a00130a04850101010569
2015.05.23 14:20:10 5: ZWDongle/RAW: /0107004a06050a00bb180107004a06050a00bb
2015.05.23 14:20:10 5: SW: 06
2015.05.23 14:20:10 5: ZWDongle_Read ZWDongle_0: 004a06050a00
2015.05.23 14:20:10 5: ZWDongle_0 dispatch 004a06050a00
2015.05.23 14:20:10 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:05 ARG:0a00
2015.05.23 14:20:10 4: ZWDongle_0 unhandled command ZW_ADD_NODE_TO_NETWORK
2015.05.23 14:20:10 4: ZWDongle_0: CANCEL received, retransmitting.
2015.05.23 14:20:10 5: SW: 010a00130a04850101010569
2015.05.23 14:20:10 5: SW: 06
2015.05.23 14:20:10 5: ZWDongle_Read ZWDongle_0: 004a06050a00
2015.05.23 14:20:10 5: ZWDongle_0 dispatch 004a06050a00
2015.05.23 14:20:10 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:05 ARG:0a00
2015.05.23 14:20:10 4: ZWDongle_0 unhandled command ZW_ADD_NODE_TO_NETWORK
2015.05.23 14:20:10 5: ZWDongle/RAW: /060104011301e8
2015.05.23 14:20:10 5: SW: 06
2015.05.23 14:20:10 5: ZWDongle_Read ZWDongle_0: 011301
2015.05.23 14:20:10 5: ZWDongle_0 dispatch 011301
2015.05.23 14:20:10 2: ZWave get ZWave_SWITCH_REMOTE_10 model
2015.05.23 14:20:10 1: ZWAVE INIT: get ZWave_SWITCH_REMOTE_10 model: Scheduled for sending after WAKEUP
2015.05.23 14:21:13 5: SW: 0105004a0507b2
2015.05.23 14:21:14 5: ZWDongle/RAW: /060107004a07060a00b9
2015.05.23 14:21:14 5: SW: 06
Zitat von: A.Harrenberg am 25 Mai 2015, 12:49:43
wollte nur mal mitteilen das ich mir jetzt gerade so eine Sirene und einen weiteren USB-Stick bestellt habe...
Dürfte einfacher sein mit Hardware zum spielen und wenn man selbst ein paar Logeinträge zum debuggen setzen kann. Mit meinem RFID-Keypad zu spielen macht auch keinen "Spass", das ist ja auch Batteriebetrieben und hängt im Flur...
Schön, ein Angesteckter ;)
ZitatDas geht dann ja bei ZWave nicht, hier müsste man alle Geräte ablernen und neu einbinden, oder?
Grundsätzlich leider ja. Außer Du hast UZB1 mit zway, der kann Backup/Restore.
Hi Krikan,
Zitat von: krikan am 25 Mai 2015, 13:18:53
@Andreas: So sieht eine Inklusion des KFOB-S in Fhem aus:
Danke, werde ich mir aber wahrscheinlich erst heute abend oder sogar morgen abend ansehen können.
Gruß,
Andreas.
Hab in ZWDongle random, timeouts und setNIF implementiert, und das wird bei jedem define (genauergesagt im ZWave_DoInit) auch ausgefuehrt. Wenn ich jetzt das KFOB inkludiere, dann kriege ich die SECURITY Klasse angezeigt.
Die Parameter habe ich von openzwave kopiert, wirklich verstanden habe ich sie nicht.
Hi Rudi,
Zitat von: rudolfkoenig am 25 Mai 2015, 15:44:05
Hab in ZWDongle random, timeouts und setNIF implementiert, und das wird bei jedem define (genauergesagt im ZWave_DoInit) auch ausgefuehrt. Wenn ich jetzt das KFOB inkludiere, dann kriege ich die SECURITY Klasse angezeigt.
Die Parameter habe ich von openzwave kopiert, wirklich verstanden habe ich sie nicht.
seh' schon, Du hast das wieder fertig implementiert bevor ich angefangen habe das zu verstehen ,-)
Hast Du evtl. mal probiert ob Security auch angezeigt wird wenn Du random und/oder timeout weglässt?
Wenn ich per SVN synchroniseren, kriege ich dann eigentlich die Änderungen sofort mit? Oder hast Du die noch nicht eingecheckt?
Gruß,
Andreas.
Danke Rudi. Habe jetzt auch SECURITY beim KFOB-S.
setNIF setzt jetzt den NIF des Controllers und man bekommt dann SECURITY von den Geräten gemeldet?
Steht vielleicht im Zusammenhang mit KFOB-S Anleitung: This device support secure communication when included by a controller that also supports secure communication.
ZitatWenn ich per SVN synchroniseren
Ja
ZitatHast Du evtl. mal probiert ob Security auch angezeigt wird wenn Du random und/oder timeout weglässt?
Ohne Random geht es bei mir auch; timeout nicht probiert.
Meldet auch ohne Timeout und Random nur mit setNIF die CC SECURITY. Aber es schadet so nicht. Vielleicht ist das später wichtig. Oder Rudi hat schon mehr Infos..
Timeout bei zway ist:
SENDING: ( 01 05 00 06 0A 0A FC )
RECEIVED ACK
RECEIVED: ( 01 05 01 06 96 0F 64 )
SENT ACK
Job 0x06 (Set Serial API timeouts): Old timeouts are: ACK timeout 1500 ms and Byte timeout 150 ms
SETDATA controller.data.oldSerialAPIAckTimeout10ms = 150 (0x00000096)
SETDATA controller.data.oldSerialAPIByteTimeout10ms = 15 (0x0000000f)
SETDATA controller.data.curSerialAPIAckTimeout10ms = 10 (0x0000000a)
SETDATA controller.data.curSerialAPIByteTimeout10ms = 10 (0x0000000a)
Hi,
hab' mir mal die Inclusion mit OpenZWave und mit dem (alten) fhem angesehen,
OpenZwave fhem
0x01, 1
0x20, Node + Länge 1e = 30
0x00, 0
0x4a, ZW_ADD_NODE_TO_NETWORK 4a add node
0x0c, 6
0x03, Capability -> not listening 03 Cap
0x02, Security -> no opt. func. 0a Sec
0x19, Reserved 17 Res
0x04, Basic BASIC_TYPE_ROUTING_SLAVE 04 Basic BASIC_TYPE_ROUTING_SLAVE
0x12, Generic Remote Switch 12 Generic Remote Switch
0x02, Specific Multilevel Remote Switch 02 Specific Multilevel Remote Switch
Command Classes ab hier:
0x5e, ZWAVEPLUS_INFO 5e ZWAVEPLUS_INFO
0x8f, Multi_CMD 8f MULTI_CMD
0x73, PowerLevel 73 POWERLEVEL
0x98, Security 98 SECURITY
0x86, Version 86 VERSION
0x72, Manufacture_Specific 72 MANUFACTURER_SPECIFIC
0x70, Configuration 70 CONFIGURATION
0x85, Association 85 ASSOCIATION
0x2d, SCENE_CONTROLLER_CONF 2d SCENE_CONTROLLER_CONF
0x8e, MULTI_CHANNEL_ASSOCIATION 8e MULTI_CHANNEL_ASSOCIATION
0x80, BATTERY 80 BATTERY
0x84, WAKE_UP 84 WAKE_UP
0x5a, DEVICE_RESET_LOCALLY 5a DEVICE_RESET_LOCALLY
0x59, ASSOCIATION_GRP_INFO 59 ASSOCIATION_GRP_INFO
0x5b, CENTRAL_SCENE 5b CENTRAL_SCENE
0xef, MARK ef MARK
0x20, BASIC 20 BASIC
0x5b, CENTRAL_SCENE 5b CENTRAL_SCENE
0x26, SWITCH_MULTILEVEL 26 SWITCH_MULTILEVEL
0x27, SWITCH_ALL 27 SWITCH_ALL
0x2b, SCENE_ACTIVATION f6 Checksum
0x60, MULTI_INSTANCE
0x8f Multi_CMD
in beiden Fällen wird SECURITY gemeldet, aber insgesamt gibt es da doch einige Unterschiede die ich nicht erklären kann.
Das Byte nach der 4a ist unterschiedlich, ich bin nicht mal sicher ob die 4a an der Stelle wirklich "add node" bedeutet.
Interessant ist (vielleicht) der Unterschied in Byte 2 vom NIF: Unter OpenZWave wird 02, unter fhem 0a gemeldet. Auch der Wert des folgenden Bytes ist unterschiedlich, hier ist in der Doku aber gar nichts angegeben ausser "protocol specific".
Interessant ist aber auch das unter OpenZWave drei Klassen mehr als controlled gemeldet werden: SCENE_ACTIVATION, MULTI_INSTANCE und MULTI_CMD.
Wirft glaube ich mehr Fragen auf als es Antworten gibt...
@Krikan, kannst Du vielleicht noch mal die Inklusion mit der neuen Version aus Deinem Logfile rausschnippeln?
Gruß,
Andreas.
Wenn es gleich ist, frage ich mich, wie sich SECURITY voher verstecken konnte.
Hier Inklusion mit den heutigen Modulversionen:
2015.05.25 18:13:15 5: SW: 0105004ac10170
2015.05.25 18:13:15 5: ZWDongle RAW buffer: 060107004a01010000b2
2015.05.25 18:13:15 5: SW: 06
2015.05.25 18:13:15 5: ZWDongle_Read ZWDongle_0: 004a01010000
2015.05.25 18:13:15 5: ZWDongle_0 dispatch 004a01010000
2015.05.25 18:13:15 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:01 ARG:0000
2015.05.25 18:13:16 4: ZWDongle_0 ZW_ADD_NODE_TO_NETWORK learnReady
2015.05.25 18:13:31 5: ZWDongle RAW buffer: 0110000410040a32022144000000080000a8
2015.05.25 18:13:31 5: SW: 06
2015.05.25 18:13:31 5: ZWDongle_Read ZWDongle_0: 000410040a32022144000000080000
2015.05.25 18:13:31 5: ZWDongle_0 dispatch 000410040a32022144000000080000
2015.05.25 18:13:31 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0a32022144000000080000
2015.05.25 18:13:35 5: ZWDongle RAW buffer: 0107004a01020000b1
2015.05.25 18:13:35 5: SW: 06
2015.05.25 18:13:35 5: ZWDongle_Read ZWDongle_0: 004a01020000
2015.05.25 18:13:35 5: ZWDongle_0 dispatch 004a01020000
2015.05.25 18:13:35 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:02 ARG:0000
2015.05.25 18:13:36 4: ZWDongle_0 ZW_ADD_NODE_TO_NETWORK nodeFound
2015.05.25 18:13:36 5: ZWDongle RAW buffer: 011e004a01030b170412025e8f7398867270852d8e80845a595bef205b2627f0
2015.05.25 18:13:36 5: SW: 06
2015.05.25 18:13:36 5: ZWDongle_Read ZWDongle_0: 004a01030b170412025e8f7398867270852d8e80845a595bef205b2627
2015.05.25 18:13:36 5: ZWDongle_0 dispatch 004a01030b170412025e8f7398867270852d8e80845a595bef205b2627
2015.05.25 18:13:36 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:03 ARG:0b170412025e8f7398867270852d8e80845a595bef205b2627
2015.05.25 18:13:36 2: autocreate: define ZWave_SWITCH_REMOTE_11 ZWave e345c452 11 5e8f7398867270852d8e80845a595bef205b2627
2015.05.25 18:13:36 2: autocreate: define FileLog_ZWave_SWITCH_REMOTE_11 FileLog ./log/ZWave_SWITCH_REMOTE_11-%Y.log ZWave_SWITCH_REMOTE_11
2015.05.25 18:13:37 2: ZWave set ZWave_SWITCH_REMOTE_11 associationAdd
2015.05.25 18:13:37 5: SW: 010a00130b04850101010568
2015.05.25 18:13:38 5: ZWDongle RAW buffer: 0107004a01050b00bd0107004a01050b00bd18
2015.05.25 18:13:38 5: SW: 06
2015.05.25 18:13:38 5: ZWDongle_Read ZWDongle_0: 004a01050b00
2015.05.25 18:13:38 5: ZWDongle_0 dispatch 004a01050b00
2015.05.25 18:13:38 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:05 ARG:0b00
2015.05.25 18:13:38 4: ZWDongle_0 unhandled command ZW_ADD_NODE_TO_NETWORK
2015.05.25 18:13:38 5: SW: 06
2015.05.25 18:13:38 5: ZWDongle_Read ZWDongle_0: 004a01050b00
2015.05.25 18:13:38 5: ZWDongle_0 dispatch 004a01050b00
2015.05.25 18:13:38 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:05 ARG:0b00
2015.05.25 18:13:38 4: ZWDongle_0 unhandled command ZW_ADD_NODE_TO_NETWORK
2015.05.25 18:13:38 4: ZWDongle_0: CANCEL received, retransmitting.
2015.05.25 18:13:38 5: SW: 010a00130b04850101010568
2015.05.25 18:13:38 5: ZWDongle RAW buffer: 060104011301e8
2015.05.25 18:13:38 5: SW: 06
2015.05.25 18:13:38 5: ZWDongle_Read ZWDongle_0: 011301
2015.05.25 18:13:38 2: ZWave get ZWave_SWITCH_REMOTE_11 model
2015.05.25 18:13:38 1: ZWAVE INIT: get ZWave_SWITCH_REMOTE_11 model: Scheduled for sending after WAKEUP
2015.05.25 18:14:08 5: SW: 0105004a0502b7
2015.05.25 18:14:08 5: ZWDongle RAW buffer: 060107004a02060b00bd
2015.05.25 18:14:08 5: SW: 06
2015.05.25 18:14:08 5: ZWDongle_Read ZWDongle_0: 004a02060b00
2015.05.25 18:14:08 5: ZWDongle_0 dispatch 004a02060b00
2015.05.25 18:14:08 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:06 ARG:0b00
2015.05.25 18:14:09 4: ZWDongle_0 ZW_ADD_NODE_TO_NETWORK done
2015.05.25 18:14:14 5: ZWDongle RAW buffer: 010b0004000b055b0331000196
2015.05.25 18:14:14 5: SW: 06
2015.05.25 18:14:14 5: ZWDongle_Read ZWDongle_0: 0004000b055b03310001
2015.05.25 18:14:14 5: ZWDongle_0 dispatch 0004000b055b03310001
2015.05.25 18:14:14 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:0b ARG:055b03310001
2015.05.25 18:14:21 5: ZWDongle RAW buffer: 010b0004000b055b0332000296
2015.05.25 18:14:21 5: SW: 06
2015.05.25 18:14:21 5: ZWDongle_Read ZWDongle_0: 0004000b055b03320002
2015.05.25 18:14:21 5: ZWDongle_0 dispatch 0004000b055b03320002
2015.05.25 18:14:21 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:0b ARG:055b03320002
2015.05.25 18:14:25 5: ZWDongle RAW buffer: 010b0004000b055b0333000590
2015.05.25 18:14:25 5: SW: 06
2015.05.25 18:14:25 5: ZWDongle_Read ZWDongle_0: 0004000b055b03330005
2015.05.25 18:14:25 5: ZWDongle_0 dispatch 0004000b055b03330005
2015.05.25 18:14:25 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:0b ARG:055b03330005
2015.05.25 18:14:27 5: ZWDongle RAW buffer: 010b0004000b055b0334000496
2015.05.25 18:14:27 5: SW: 06
2015.05.25 18:14:27 5: ZWDongle_Read ZWDongle_0: 0004000b055b03340004
2015.05.25 18:14:27 5: ZWDongle_0 dispatch 0004000b055b03340004
2015.05.25 18:14:27 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:0b ARG:055b03340004
Hi Krikan,
Zitat von: krikan am 25 Mai 2015, 19:41:10
Wenn es gleich ist, frage ich mich, wie sich SECURITY voher verstecken konnte.
Hier Inklusion mit den heutigen Modulversionen:
die Inklusion mit der neuen Modulversion ist (fast) identisch mit der alten! Es gibt nur einen Unterschied im zweiten Byte vom NIF, der ist diesmal 0b statt 0a, ich denke das ist eher ein interner Zähler oder so.
Nachdem ich jetzt ein wenig darüber nachgedacht habe, stelle ich mal folgende Theorie auf:
1. Das Gerät meldet bei der Inklusion IMMER Security
2, Wenn aber nicht innerhalb von 10 Sekunden nach der Inklusion die Prozedur mit der Schlüsselübertragung gestartet wird (SDS11060-7 S. 238 (250 im PDF) und Grafik auf S. 240 (252 im PDF)) dann wird die Klasse vom Gerät deaktiviert und bei WEITEREN Anfragen nicht mehr gemeldet.
3. Ich VERMUTE das die Fähigkeiten des Gerätes bei fhem nicht aus den Daten bei der Inklusion, sondern durch eine gesonderte Abfrage gebildet werden, bei der die Klasse dann bereits deaktiviert ist.
@Rudi: Kannst Du den dritten Teil beantworten?
Bei der Definition der Parameterdaten für das SetNIF (01 02 01 00) komme ich auch nicht so richtig weiter, der Sourcecode gibt dazu nur folgendes an:
Msg* msg = new Msg( "FUNC_ID_SERIAL_API_APPL_NODE_INFORMATION", 0xff, REQUEST, FUNC_ID_SERIAL_API_APPL_NODE_INFORMATION, false, false );
msg->Append( APPLICATION_NODEINFO_LISTENING );
msg->Append( 0x02 ); // Generic Static Controller
msg->Append( 0x01 ); // Specific Static PC Controller
msg->Append( 0x00 ); // Length
SendMsg( msg, MsgQueue_Command ); Die Definition für 0x02 für Generic Static Controller kann man vielleicht ja noch aus der Tabelle 1 S.10 (18) aus SDS10242-17 nachvollziehen, der Specific Teil dann nicht mehr, der müsste dann laut der nächsten Tabelle 0x10 sein. Und was da eine 0x00 als "Length" soll erschliesst sich mir auch nicht...
Gruß,
Andreas.
Habe angefangen security zu implementieren:
- ZWDongle hat Attribut networkKey
- falls gesetzt, und bei Inclusion die Klasse SECURITY gemeldet wird, dann wird
- secScheme gesendet/gefragt
- secKey gesendet
- secNonce gesendet/gefragt
Bis hierhin macht mein KFOB alles schoen mit.
Eure Romane lese ich spaeter :)
Hi,
hab' ich ja gesagt, Du hast das implementiert bevor ich angefangen habe das zu verstehen ,-)
Welche Klassen werden dann als secure-supported gemeldet?
SecurityCmd_SupportedGet = 0x02,
SecurityCmd_SupportedReport = 0x03,
Gruß,
Andreas.
Andreas: du magst mit deiner Theorie (Punkt 3) Recht haben, obwohl ich es noch nicht so recht glauben will:
- FHEM hat bis vor kurzem bei einem ZW_APPLICATION_UPDATE die Klassen ueberschrieben, solche Nachrichten kommen, wenn man auf dem Geraet auf dem Knopf herumfummelt. Das habe ich vor paar Tagen ausgebaut, damit ich bei einem eigentlich batteriebetriebenen Geraet, den ich jetzt mit einem Netzteil speise, nicht auf das wakeUpNotify warten muss (WAKE_UP aus classes einfach loeschen).
- ich habe bei der Inklusion der KFOB als allererstes auf die Klassen geachtet, weil ich das Geraet wg. Security gekauft habe, und da war nix.
- ich habe heute der Reihe nach die neuen Befehle auskommentiert, und es hat jeweils funktioniert. Ich erklaere es damit, dass der Controller was gemerkt hat.
SupportedGet habe ich auch kurz probiert, das will aber noch nicht. Ist wohl noch unfertig....
Mit dem schoenen Log von Christian und den funktionierenden Quellen bin ich zuversichtlich, dass wir Security in FHEM demnaechst am Laufen haben. Auch wenn der naechste Stueck (AES konfigurieren) vmtl. am aufwendigsten sein wird.
Hi Rudi,
ich kriege ja wahrscheinlich diese Woche noch die Sirene und einen zweiten Stick. Ich werde mir das dann auf eine virtuellen Maschine mal mit OpenZWave und fhem einrichten und kann dann ja noch mal selber damit rumprobieren ob/wo der Unterschied ist. Ich muss mir die Beschreibung zu der Security Class noch mal in Ruhe durchlesen, habe es bisher immer nur überflogen und dabei überliest man schon mal wichtige Nebensätze.
Vielleicht muss man zum Testen auch den Stick "resetten"? Speichert der seine Konfiguration vielleicht sogar in einem Flash? Sollte man ja eigentlich meinen...
Ja, AES wird sicherlich noch mal aufwändiger, vor allem wenn man da längere Messages auf mehrere Frames aufteilen muss.
Ich habe mir gerade noch mal den "header" von WMBus.pm angesehen, dabei wundert mich das dort beschrieben ist wie man das Packet unter debian installiert, es wird aber nicht mit use eingebunden. Der "Aufruf" ist dann aber direkt über ein hash mit:
-cipher => "Crypt::OpenSSL::AES",
Sollte das nicht besser mit use eingebunden werden?
Mal sehen wann meine Teile ankommen und wieviel Zeit ich noch dafür habe. Die nächste und übernächste Woche ist nämlich ziemlich blockiert wegen Besuch und Veranstaltungen, einige Vorbereitungen sind auch noch offen... Aber wahrscheinlich bist Du eh vor dem WE fertig ,-)
Gruß,
Andreas.
Hallo Rudi,
wenn Du SECURITY soweit drin hast, dass ich mittesten soll, bitte Bescheid geben.
Testobjekte mit SECURITY:
- KFOB-S
- Aeon Labs DSD31 Gen5
- Philio PST02-1A
Die Unterstützung von SECURITY beim Philio habe ich erst gestern wahrgenommen, darum direkt eine Bitte ;):
In der Endfassung Deiner SECURITY-Unterstützung bitte Wahlmöglichkeit, ob Secure oder Nicht-Secure Inklusion bei Geräten mit CC SECURITY. Macht openzwave und zway auch....
Gruß, Christian
Zitat von: A.Harrenberg am 26 Mai 2015, 07:38:36
Ich habe mir gerade noch mal den "header" von WMBus.pm angesehen, dabei wundert mich das dort beschrieben ist wie man das Packet unter debian installiert, es wird aber nicht mit use eingebunden. Der "Aufruf" ist dann aber direkt über ein hash mit:
-cipher => "Crypt::OpenSSL::AES",
Sollte das nicht besser mit use eingebunden werden?
Das habe ich dort mit Absicht so gemacht.
Wenn keine Entschlüsselung benötigt wird soll das Modul auch ohne installiertes AES Modul funktionieren.
Allerdings habe ich das Fehlerverhalten nicht getestet, wenn AES nicht installiert aber verwendet werden soll. Da gibt es mglw. Verbesserungsbedarf.
Hi,
AES ver-/entschlüsseln ist anscheinend recht einfach wenn Tante Google hilft...
use Crypt::CBC; # libcrypt-cbc-perl
use Digest::CRC; # libdigest-crc-perl
use Crypt::OpenSSL::AES;
my $cipher = Crypt::CBC->new(
{
'key' => 'length16length16',
'cipher' => 'Crypt::OpenSSL::AES',
'iv' => '1234567812345678',
'literal_key' => 1,
'header' => 'none',
keysize => 128 / 8
}
);
sub aes_encode() {
my $my_string = "hello";
my $my_coded = $cipher->encrypt_hex($my_string);
my $my_decoded = $cipher->decrypt_hex($my_coded);
#~ my $ma_decoded ) decode_base64(
Log3 "aes", 3, "aes_encode: $my_string -> $my_coded -> $my_decoded";
};
Es gilt allerdings herauszufinden wo welche Nonce als Init verwenden werden müssen, werde mal ein wenig im Code von OpenZWave suchen...
Und mal schauen ob da auch CBC verwendet wird.
Gruß,
Andreas.
Hi Kaihs,
Zitat von: kaihs am 26 Mai 2015, 20:27:22
Das habe ich dort mit Absicht so gemacht.
Wenn keine Entschlüsselung benötigt wird soll das Modul auch ohne installiertes AES Modul funktionieren.
Allerdings habe ich das Fehlerverhalten nicht getestet, wenn AES nicht installiert aber verwendet werden soll. Da gibt es mglw. Verbesserungsbedarf.
ok, wenn das absichtlich ist kann ich es nachvollziehen.
Fehlverhalten kann ich jetzt auch nicht (mehr) testen, jetzt ist ja alles installiert und ich habe keine Lust das wieder zu de-installieren ,-)
Das können wir dann probieren wenn das ganze mal funktioniert.
Danke für die Rückmeldung,
Andreas.
Hi,
also das mit dem Code für AES in OpenZWave ist für mich jedenfalls nicht auf den ersten Blick zu verstehen. Aber es wird anscheinend "ecb" und "ofb" anstelle von "cbc" bei der Verschlüsselung genutzt. (Wobei mindestens ecb eigentlich als unsicher gilt...)
Soweit ich das bisher erkennen konnte wir der Nonce erst mit "ecb" verschlüsselt, das Datenpaket dann mit "ofb"...
Den ganzen Ablauf konnte ich da jetzt bisher nicht wirklich nachvollziehen. Das System dort ist ja auch vollkommen anders aufgebaut. Und mit cpp habe ich auch noch nicht so wirklich gearbeitet.
Die wichtigsten Grundfunktionen sind aber in ZWSecurity.h / .cpp und in aes/aescpp.h / .cpp zu finden.
In Driver.h/ .cpp gibt es dann Funktionen wie:
SendEncryptedMessage
SendNonceRequest
SendNonceKey
GetNonceKey
DecryptBuffer
GetNetworkKey
...
Da ist dann noch ein wenig Forschung angesagt.
Gruß,
Andreas.
Nur zu Info: openzwave merged security rewrite to master https://groups.google.com/d/msg/openzwave/cPjrvJJaESY/toK7QxEgRn0J
Hi,
auch nur zur Info...
Meine Spielzeuge sind angekommen, dafür habe ich mir gerade meine Testinstallation von fhem irgendwie komplett geschrottet... ,-(
Und die neue Installation verhält sich SEHR merkwürdig... ,-(
Argl...
Gruß,
Andreas.
Hi,
mein ZWave-Stick hat gerade bei de Einrichtung "rumgezickt". Ich habe immer ein "ERROR: ZWDongle_0 homeId is not set!" bekommen. Ein get homeID wurde mit einer Meldung quittiert das dies nicht unterstützt wird. Eigentlich wurden so ziemlich alle Befehle nicht erkannt, die Liste der "Caps" war auch leer. Erst nach einem set reopen hat er da jetzt mal alles eingelesen...
Das war bei dem anderem Stick jedenfalls nicht so.
Gruß,
Andreas.
Hi,
ich habe gerade mal die Sirene inkludiert, dabei ist mir aber was merkwürdiges mit den IDs aufgefallen.
Die Sirene ist jetzt als ZWave_SWITCH_BINARY_4 mit der id 4 eingebunden.
Das ist allerdings das erste und einzige Gerät, im Logfile meldet sich auf das "Learn" erst Node 2, dann kommt im Logfile ein ZW_ADD_NODE_TO_NETWORK ID:03, dann kommt "autocreate: define ZWave_SWITCH_BINARY_4 ZWave e015dfed 4", anschliessend noch mal "CMD:ZW_ADD_NODE_TO_NETWORK ID:05 ARG:0400".
Wenn ich jetzt ein get nodelist mache, sind auch Node 1,2,3,4 definiert...
nodeInfo_2
SLAVE SWITCH_BINARY listening frequentListening:0 beaming:16 routing 40kBaud Vers:3 Security:0
nodeInfo_3
SLAVE SWITCH_BINARY listening frequentListening:0 beaming:16 routing 40kBaud Vers:3 Security:0
nodeInfo_4
ROUTING_SLAVE SWITCH_BINARY listening frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
Node 5 taucht hier dann aber nicht auf...
Im Log von Krikan tauchten ja auch merkwürdige IDs auf, denke mal ist der gleiche Effekt.
Ich habe mir den Code jetzt noch nicht dahingehend angeschaut, aber könnte es sein das die ID da aus der falschen Stelle im NIF Paket ausgelesen wird?
Oder ist das etwas so "normal"?
Gruß,
Andreas.
Hallo Andreas,
hast Du eine secure-Inklusion probiert?
Das habe ich mit der DSD31 noch nicht. Bei einer normalen inklusion habe ich das von Dir beschriebene Verhalten nicht beobachten können.
Gruß, Christian
Hi Krikan,
Zitat von: krikan am 29 Mai 2015, 08:02:13
Hallo Andreas,
hast Du eine secure-Inklusion probiert?
Das habe ich mit der DSD31 noch nicht. Bei einer normalen inklusion habe ich das von Dir beschriebene Verhalten nicht beobachten können.
Gruß, Christian
tja, was bezeichnen wir denn jetzt als secure-Inklusion? Also ich habe das mit dem aktuellen Stand gemacht, allerdings noch ohne einen networkkey einzutragen. D.h. es wurde weder das Sheme noch die Nonce ausgetauscht. Die ganze Geschichte mit den IDs geht aber sowieso früher los. Ich bin mir recht sicher das dies nichts mit den aktuellen Änderungen bzgl. Security zu tun hat.
Ich verstehe den Aufbau der Messages bei der Inklusion noch nicht so ganz, vor allem da es keine Doku gibt, außer andere Code-Quellen... Das passt aber nicht so ganz mit dem Aufbau von einem NIF zusammen der in der Doku enthalten ist. Allerdings passt die Rückmeldung auch nicht ganz zur Beschreibung... Argh, ich will eine vernünftige Doku...
Nach dem "Learn" kommt im Log schon so etwas zurück mit "Node: 02" gefunden, ich frage mich nun aber mal grundsätzlich wie das Gerät, das ja noch nicht im Netzwerk includiert ist, sich selbst eine Nodenummer geben kann und diese reported, um letztendlich dann mit node 4 eingebunden zu werden.
Wenn ich etwas Zeit finde werde ich da noch mal alles aus fhem entfernen und die neuen timer/random/setNIF auskommentieren und das noch mal inkludieren.
Kannst Du denn mal eine Nodelist aufrufen und dann für jede dort aufgeführte Node mal die NodeInfo abrufen? Ich vermute mal das in der Nodelist mehr Nodes drinstehen als real als Geräte da sind.
Gruß,
Andreas.
P.S.: Wie aufwändig ist es eigentlich OpenZWave zu installieren? Läuft das bei Dir unter Linux? Ich wollte das ja eigentlich auch noch "parallel" installieren, muss mir nur überlegen ob ich das gleichzeitig auf einer Maschine laufen lassen kann, bzw. was passiert wenn ich da zwischen fhem und OpenZWave hin-und herwechsel.
Dann hast Du nach meiner Definition keine secure-Inklusion gemacht und wie ich die "normale" Inklusion. Habe es aber noch mit der Fassung ohne timer/random/setNIF zuletzt inkludiert (glaube ich zumindest). Teste das bei Gelegenheit mit der aktuellen Fassung und poste nodeList usw. Welchen Controller nutzt Du?
Openzwave habe ich für die letzten Tests mit Windows auf einem separaten Rechner genutzt. Da ich zu faul war zu kompilieren, habe ich http://www.domoticz.com/ genutzt. Das ist schnell installiert. Im Prinzip kannst Du jedes Produkt nehmen, was https://github.com/OpenZWave/open-zwave/wiki/Projects-Using-OZW listet (nur nachschauen, wie aktuell die genutzte openzwave Version ist). Habe auch schon mit openzwave selbst und ozcp in der Vergangenheit experimentiert. Das ist aufwendiger (für mich) zu installieren.
random/timer/setNIF ist nur fuer secure notwendig. Und secure ist nicht aktiv, wenn networkKey nicht gesetzt ist, das sollte im Log vermerkt sein. Und ich hatte sowohl ohne als auch mit secure bei KFOB immer nur ein node auf einmal bekommen, und ich habe es bisher 24-mal inkludiert bzw. excludiert. Der Controller zaehlt aber schoen hoch, d.h. nodeList zeigt bei mir 1,2,25 an. Node 2 war vorher schon drin (eigentlich frech), und ich kriege es nicht weg.
Den nodeId vergibt der Dongle, er hat ja schliesslich einen Ueberblick.
Nachtrag: nach etwas Zaehlen muss ich es wohl 23-mal inkludiert haben :)
Hi Rudi,
Zitat von: rudolfkoenig am 29 Mai 2015, 13:46:11
random/timer/setNIF ist nur fuer secure notwendig. Und secure ist nicht aktiv, wenn networkKey nicht gesetzt ist, das sollte im Log vermerkt sein.
ja, das war im Log, aber das ganze mit den IDs war ja aber auch vorher.
Zitat von: rudolfkoenig am 29 Mai 2015, 13:46:11
Und ich hatte sowohl ohne als auch mit secure bei KFOB immer nur ein node auf einmal bekommen, und ich habe es bisher 24-mal inkludiert bzw. excludiert. Der Controller zaehlt aber schoen hoch, d.h. nodeList zeigt bei mir 1,2,25 an. Node 2 war vorher schon drin (eigentlich frech), und ich kriege es nicht weg.
Hmm, ich werde noch mal exkludieren und erneut inkludieren und schauen was passiert. Dann lösche ich mal wieder alles und fange noch mal von vorne an. Mal schauen.
Zitat von: rudolfkoenig am 29 Mai 2015, 13:46:11
Den nodeId vergibt der Dongle, er hat ja schliesslich einen Ueberblick.
Nachtrag: nach etwas Zaehlen muss ich es wohl 23-mal inkludiert haben :)
Ok, stimmt der Stick hat ja auch etwas eigene Intelligenz, d.h. er vergibt dann die ID und meldet die per USB/seriell an fhem...
Kann es sein das der Stick auch Geräte in dem anderen ZWave Netz findet und versucht die zu includieren, die das aber ablehnen da sie nicht in dem Mode sind und aber dennoch IDs vergibt?
Gruß,
Andreas.
P.S.: Krikan, die Controller sind beide ZWave.me UZB
ZitatEin get homeID wurde mit einer Meldung quittiert das dies nicht unterstützt wird.
Kannst du das reproduzieren? Neuerdings werden nur die ZWDongle Befehle "unterstuetzt", die in caps drin sind.
Deswegen wird als erstes nach dem ZWDongle Open automatisch "get caps" ausgefuehrt. Bei mir scheint das zu tun.
Ich habe gerade ein sporadisches "ERROR: D homeId is not set!" waehrend "define zwdongle" eliminiert.
Hallo Rudi,
ich kann noch einmal alles entfernen und versuchen den Stick noch mal neu anzulernen und sehen was passiert.
Das "Problem" mit den IDs beim Einbinden der Sirene besteht noch "halb". Irgendwas ist da nicht konsistent.
Ich habe ID2 und ID3 jeweils mit einem "SLAVE_BINARY_SWITCH" belegt den es nicht gibt. Löschen lässt sich das nicht. Beim zweiten Einbinden kommt immer noch ID2, ID3, die Siren wurde dann aber unter ID5 eingebunden ohne das noch eine weiter ID wie beim ersten Mal im Log auftauchte.
Beim dritten Einbinden wieder ID2, ID3 und dann ID6.
Ich schicke gleich mal ein LOG vom erneuten Einbinden des Sticks.
Gruß,
Andreas.
Hi,
ja, lässt sich reproduzieren...
#2015.05.29 19:23:18 0: Server shutdown
2015.05.29 19:23:20 1: Including fhem.cfg
2015.05.29 19:23:20 3: telnetPort: port 7072 opened
2015.05.29 19:23:20 3: WEB: port 8083 opened
2015.05.29 19:23:20 3: WEBphone: port 8084 opened
2015.05.29 19:23:20 3: WEBtablet: port 8085 opened
2015.05.29 19:23:20 2: eventTypes: loaded 0 events from ./log/eventTypes.txt
2015.05.29 19:23:20 1: Including ./log/fhem.save
2015.05.29 19:23:20 1: usb create starting
2015.05.29 19:23:21 3: Probing CUL device /dev/ttyACM0
2015.05.29 19:23:21 3: Probing TCM_ESP3 device /dev/ttyACM0
2015.05.29 19:23:21 3: Probing ZWDongle device /dev/ttyACM0
2015.05.29 19:23:22 1: define ZWDongle_0 ZWDongle /dev/ttyACM0@115200
2015.05.29 19:23:22 3: Opening ZWDongle_0 device /dev/ttyACM0
2015.05.29 19:23:22 3: Setting ZWDongle_0 baudrate to 115200
2015.05.29 19:23:22 3: ZWDongle_0 device opened
2015.05.29 19:23:23 1: ERROR: ZWDongle_0 homeId is not set!
2015.05.29 19:23:26 1: usb create end
2015.05.29 19:23:26 2: SecurityCheck: WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute. Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2015.05.29 19:23:26 0: Server started with 10 defined entities (version $Id: fhem.pl 8574 2015-05-14 07:59:32Z rudolfkoenig $, os linux, user fhem, pid 21144)
Ich habe die Siren excluded, aus der Konfig entfernt, das Filelog der Sirene aus dem Konfig entfernt, ZWDongle entfernt, Konfig gespeichert und einen "shutdown restart" gemacht.
Soll ich noch was testen?
Gruß,
Andreas.
Nutzen evtl. alle mit den homeId-Problemen UZB1 bzw. Razberry? zway fragt die homeId laut log 3x hintereinander ab und startet einen watchdog. Vielleicht gibt es da einen Zusammenhang. Mit meinem Vision EU1404 hatte ich das Problem mit der homeId noch nie und ich habe nicht wenige Neustarts gemacht.
Zitat2015.05.29 19:23:23 1: ERROR: ZWDongle_0 homeId is not set!
Dieses Problem habe ich doch vorhin behoben, du hast aber was von "wird nicht unterstuetzt" gesagt.
Diese Meldung lag daran, dass beim vom define automatisch ausgeloesten ersten get vor dem
eigentlichen Antwort der Dongle Daten schickt, die in ZWave.pm analysiert werden.
Da zu dieser Zeit weder die Attribute, noch die alten Readings aktiviert sind,
gibts noch kein homeId, und ZWave.pm plaerrt los.
Hallo Rudi,
Zitat von: rudolfkoenig am 29 Mai 2015, 20:52:59
Dieses Problem habe ich doch vorhin behoben, du hast aber was von "wird nicht unterstuetzt" gesagt.
Diese Meldung lag daran, dass beim vom define automatisch ausgeloesten ersten get vor dem
eigentlichen Antwort der Dongle Daten schickt, die in ZWave.pm analysiert werden.
Da zu dieser Zeit weder die Attribute, noch die alten Readings aktiviert sind,
gibts noch kein homeId, und ZWave.pm plaerrt los.
Ich habe das noch nicht mit der allerneuesten Version gemacht, auf dem Rechner habe ich noch kein SVN eingerichtet.
Das "wird nicht unterstützt" bekommt man wenn man in dem Status "home ID not set" versucht irgendwelche Befehle auslöst. Hab' mich vielleicht nicht klar genug ausgedrückt.
Ich werde mal SVN einrichten und das noch mal testen. Leider hatte ich gerade ein anderes Problem und habe daher hier nicht weiter probiert.
Gruß,
Andreas.
Guten Morgen Rudi,
so, jetzt habe ich doch noch mal etwas reproduzieren können.
ZWave Sirene entfernt, Logfile entfernt, ZWDongle entfernt, Save, shutdown restart
-> ZWDongle wird angelegt, homeID = initial
Wenn ich nun aus dem Menü get homeID anwähle bekomme ich die Rückmeldung: "homeId is unsupported by this controller"
Es sind dann auch noch keine Capabilities des Dongles ausgefüllt. Hier mal ein List des Dongles, Logfile hänge ich gleich an.
Internals:
CFGFN
CallbackNr 0
Clients :ZWave:
DEF /dev/ttyACM0@115200
DeviceName /dev/ttyACM0@115200
FD 4
NAME ZWDongle_0
NR 20
PARTIAL
RAWMSG 0120e015dfed01
ReadTime 1432965386.38986
STATE Initialized
TYPE ZWDongle
ZWDongle_0_MSGCNT 1
ZWDongle_0_TIME 2015-05-30 07:56:26
homeId initial
nrNAck 0
Matchlist:
1:ZWave .*
Readings:
2015-05-30 07:56:25 state opened
SendStack:
Attributes:
verbose 5
Aus diesem Zustand heraus ein Save, shutdown restart -> Nach dem Neustart ist die homeID gesetzt, die Capabilities sind gefüllt und der Stick scheint zu funktionieren.
List nach dem Neustart:
Internals:
CallbackNr 0
Clients :ZWave:
DEF /dev/ttyACM0@115200
DeviceName /dev/ttyACM0@115200
FD 10
NAME ZWDongle_0
NR 20
PARTIAL
RAWMSG 0106640f
ReadTime 1432965726.01563
STATE Initialized
TYPE ZWDongle
ZWDongle_0_MSGCNT 1
ZWDongle_0_TIME 2015-05-30 08:02:05
homeId e015dfed
nrNAck 0
Matchlist:
1:ZWave .*
Readings:
2015-05-30 08:02:05 caps Vers:5 Rev:1 ManufID:0115 ProductType:0400 ProductID:0001 SERIAL_API_GET_INIT_DATA SERIAL_API_APPL_NODE_INFORMATION APPLICATION_COMMAND_HANDLER ZW_GET_CONTROLLER_CAPABILITIES SERIAL_API_SET_TIMEOUTS SERIAL_API_GET_CAPABILITIES SERIAL_API_SOFT_RESET UNKNOWN_09 UNKNOWN_0a ZW_SET_R_F_RECEIVE_MODE ZW_SET_SLEEP_MODE ZW_SEND_NODE_INFORMATION ZW_SEND_DATA ZW_SEND_DATA_MULTI ZW_GET_VERSION ZW_SEND_DATA_ABORT ZW_R_F_POWER_LEVEL_SET ZW_SEND_DATA_META ZW_GET_RANDOM MEMORY_GET_ID MEMORY_GET_BYTE MEMORY_PUT_BYTE MEMORY_GET_BUFFER MEMORY_PUT_BUFFER UNKNOWN_27 UNKNOWN_28 UNKNOWN_29 UNKNOWN_2a UNKNOWN_2b UNKNOWN_2c UNKNOWN_2d ZW_GET_NODE_PROTOCOL_INFO ZW_SET_DEFAULT ZW_REPLICATION_COMMAND_COMPLETE ZW_REPLICATION_SEND_DATA ZW_ASSIGN_RETURN_ROUTE ZW_DELETE_RETURN_ROUTE ZW_REQUEST_NODE_NEIGHBOR_UPDATE ZW_APPLICATION_UPDATE ZW_ADD_NODE_TO_NETWORK ZW_REMOVE_NODE_FROM_NETWORK ZW_CREATE_NEW_PRIMARY ZW_CONTROLLER_CHANGE ZW_SET_LEARN_MODE ZW_ASSIGN_SUC_RETURN_ROUTE ZW_REQUEST_NETWORK_UPDATE ZW_SET_SUC_NODE_ID ZW_DELETE_SUC_RETURN_ROUTE ZW_GET_SUC_NODE_ID ZW_SEND_SUC_ID ZW_EXPLORE_REQUEST_INCLUSION ZW_REQUEST_NODE_INFO ZW_REMOVE_FAILED_NODE_ID ZW_IS_FAILED_NODE ZW_REPLACE_FAILED_NODE UNKNOWN_66 UNKNOWN_67 UNKNOWN_78 GET_ROUTING_TABLE_LINE LOCK_ROUTE_RESPONSE UNKNOWN_92 UNKNOWN_93 UNKNOWN_98 UNKNOWN_b4 ZW_WATCHDOG_ENABLE ZW_WATCHDOG_DISABLE ZW_WATCHDOG_CHECK ZW_SET_EXT_INT_LEVEL ZW_RF_POWERLEVEL_GET ZW_TYPE_LIBRARY ZW_SEND_TEST_FRAME ZW_GET_PROTOCOL_STATUS UNKNOWN_d2 UNKNOWN_d3 UNKNOWN_d4 UNKNOWN_ef UNKNOWN_f2 UNKNOWN_f4 UNKNOWN_f5
2015-05-30 08:02:05 homeId HomeId:e015dfed CtrlNodeId:01
2015-05-30 08:02:05 random 3fbfc5627659ba9bce8b70d886075780a608a3a55a6d494bed8c0a82fd77e26d
2015-05-30 08:02:04 state opened
SendStack:
Attributes:
verbose 5
Ich habe gerade gemerkt das ich global verbose auf 5 hatte, im angehängten File habe ich mal das meiner Meinung nach Unwichtige gelöscht. Vielleicht wirst Du ja daraus schlau...
Beim Einrichten des ersten Sticks hatte ich diese Probleme jedenfalls nicht, da habe ich mich an der Beschreibung im WIki orientiert und wäre bei so einem Problem sicherlich hängengeblieben.
Gruß,
Andreas.
Das nach dem Device-Open die caps nicht gefuellt sind, ist ein Problem.
Koenntest du den ersten Zustand (ohne caps) provozieren und mit verbose 5 protokollieren?
Guten Morgen Rudi,
wenn Du mir verräts wie ich ein Verbose 5 für den Dongle hinbekomme wenn der gerade erst eingebunden wird. Oder reicht global verbose=5 und das wirkt auf ALLE Module?
Hab gerade mal fhem komplett runtergeworfen und neu installiert, Verhalten lies sich reproduzieren, anstatt shutdown restart reicht auch ein set reopen.
Gruß,
Andreas.
Hi,
hab' das jetzt mit global verbose=5 noch einmal durchgespielt und das Logfile nicht bearbeitet.
Vorher: Device ZWDongle gelöscht, save
Im Logfile dann: shutdown restart, Kontrolle ob ZWDongle Caps enthält, set reopen
Gruß,
Andreas.
Schaut so aus, das du das Problem von gero dokumentiert hast (CANCEL nach eine Request). Vmtl. muss ich seinen patch mit LastMsg vollstaendig einbauen, allerdings brauchen wir noch einen Zaehler. Kommt noch.
Hallo Rudolf,
ok, mit dem momentanen Stand kann ich ja erst mal leben. Bis das Problem irgendwie gelöst ist könnte man das ja auch z.B. in der Wiki erwähnen und als Workaround das "set reopen" vorschlagen.
Ich such dann mal weiter nach Informationen zu dem Messageaufbau um das mit den IDs zu verstehen. Aber vorher werde ich mal den networkkey setzen und schauen was passiert. Soweit war ich ja noch gar nicht gekommen. ,-)
Das mit dem AES scheint doch was aufwändiger zu sein, diese blöden Block-Modes ecb und ofs scheinen nicht mit dem CRYPT::OpenSSL::AES zu funktionieren. Muss mal sehen ob das mit Rijndael funktioniert. Soweit ich das aus dem Code von OpenZWave verstanden habe wird dort zur Zeit noch keine multi-frame codierung unterstützt, aber soweit sind wir ja noch lange nicht.
Gruß,
Andreas.
Gruß,
Andreas.
Hab den Patch vom gero (ergaenzt mit einem RetransmitCount) eingecheckt. Waere nett, wenn du es testen koenntest, da das Problem bei mir nicht auftritt. Falls es immer noch auftreten sollte, bitte nochmal Log erstellen.
Hi Rudi,
Verhalten lässt sich leider weiterhin reproduzieren. Log im Anhang.
Wie finde ich eigentlich die Stellen raus an denen Du was geändert hast? Dann könnte ich da vielleicht auch mal schauen.
Gruß,
Andreas.
Zitat von: A.Harrenberg am 30 Mai 2015, 17:30:13
Wie finde ich eigentlich die Stellen raus an denen Du was geändert hast? Dann könnte ich da vielleicht auch mal schauen.
Meinst Du so etwas: http://sourceforge.net/p/fhem/code/8657/tree//trunk/fhem/FHEM/00_ZWDongle.pm?diff=51b78df35fcbc96f6b6b9d33:8656
Das kannst Du bei sourceforge ansehen, wenn es denn läuft. Bei mir eben nicht.
Hi Krikan,
ganau so etwas meinte ich. Danke!
Habt Ihr dann vielleicht auch noch eine Lösung dafür wie ich die Dateien aus SVN in fhem bekomme ohne da immer händisch an den Benutzern und Rechten ändern zu müssen?
Die Dateien aus dem SVN landen immer als "root:root" im Dateisytem, wenn ich da da in den fhem Ordner kopiere meckert fhem je nach Datei darüber.
Gruß,
Andreas.
P.S.: Werde in den nächsten Tagen weniger Zeit haben, kann aber sicherlich zwischendurch immer wieder mal das Init von dem Stick testen falls nötig.
@Andreas:
Fuer die Entwicklung liegt FHEM bei mir als sourceforge checkout rum (siehe README.SVN). Das wuerde ich jedem empfehlen, der aktiv mitmachen will, auch wenn man selbst nichts einchecken soll/darf. Ich verwende die svn Kommandozeile, es gibt aber auch grafische Frontends.
Nuetzliche Befehle der Kommandozeile:
- svn update . (holt die eingecheckten Aenderungen. Funktioniert sofort, waehrend update erst am naechsten Tag. Die lokalen Aenderungen bleiben erhalten)
- svn diff . (zeigt die lokalen Aenderungen, die Ausgabe kann man als Patch posten. Pflichtkommando vor jedem checkin)
- svn log filename (zeigt die Historie mit Versionsnummer und Eincheck Kommentaren)
- svn diff -r<R1>:<R2> filename (zeigt die Unterschiede zwischen den Versionen R1 und R2 an.)
- svn blame filename (zeigt fuer jede Zeile an, in welcher Revision sie zuletzt geaendert wurde)
Nach meinen Experimenten bin ich ziemlich sicher, dass du nicht die aktuelle Version verwendet hast, leider aber nicht 100%, weil ich die Meldung "CANCEL received, nothing to retransmit." nicht geaendert habe. Das habe ich hiermit getan. Kannst du bitte darauf achten, dass du 00_ZWDongle.pm version 8662 verwendest (siehe das FHEM version Befehl)
p.s.: Die Dateien gehoeren lokal immer dem, der das auscheckt. Auf der Testmaschine gibt es kein fhem-user, damit laeuft FHEM unter meinem Account, und meckert nicht ueber falsche Rechte. Ich starte FHEM in einem Terminal mit "attr global logfile -" in der config, damit landet der FHEM-Log im Terminal. Restart geht mit CTRL-C, Pfeil nach oben, return, ist einfacher als ein "reload modulname".
Hallo Rudi,
Zitat von: rudolfkoenig am 30 Mai 2015, 18:51:11
@Andreas:
Fuer die Entwicklung liegt FHEM bei mir als sourceforge checkout rum (siehe README.SVN). Das wuerde ich jedem empfehlen, der aktiv mitmachen will, auch wenn man selbst nichts einchecken soll/darf. Ich verwende die svn Kommandozeile, es gibt aber auch grafische Frontends.
Nuetzliche Befehle der Kommandozeile:
- svn update . (holt die eingecheckten Aenderungen. Funktioniert sofort, waehrend update erst am naechsten Tag. Die lokalen Aenderungen bleiben erhalten)
- svn diff . (zeigt die lokalen Aenderungen, die Ausgabe kann man als Patch posten. Pflichtkommando vor jedem checkin)
- svn log filename (zeigt die Historie mit Versionsnummer und Eincheck Kommentaren)
- svn diff -r<R1>:<R2> filename (zeigt die Unterschiede zwischen den Versionen R1 und R2 an.)
- svn blame filename (zeigt fuer jede Zeile an, in welcher Revision sie zuletzt geaendert wurde)
Als SVN habe ich es ja auch hier liegen. Habe es jetzt noch nicht probiert, aber ich denke das die svn diff und svn blame Befehle das liefer was ich suche, nämlich die zuletzt geänderten Stellen, Danke für die Zusammenfassung.
Zitat von: rudolfkoenig am 30 Mai 2015, 18:51:11
Nach meinen Experimenten bin ich ziemlich sicher, dass du nicht die aktuelle Version verwendet hast, leider aber nicht 100%, weil ich die Meldung "CANCEL received, nothing to retransmit." nicht geaendert habe. Das habe ich hiermit getan. Kannst du bitte darauf achten, dass du 00_ZWDongle.pm version 8662 verwendest (siehe das FHEM version Befehl)
Für die Tests war es 8657 von 12:57. Ich mach gleich noch mal ein svn update und dann einen neuen Versuch.
Zitat von: rudolfkoenig am 30 Mai 2015, 18:51:11
p.s.: Die Dateien gehoeren lokal immer dem, der das auscheckt. Auf der Testmaschine gibt es kein fhem-user, damit laeuft FHEM unter meinem Account, und meckert nicht ueber falsche Rechte. Ich starte FHEM in einem Terminal mit "attr global logfile -" in der config, damit landet der FHEM-Log im Terminal. Restart geht mit CTRL-C, Pfeil nach oben, return, ist einfacher als ein "reload modulname".
Hmm, das könnte ich natürlich auch mal versuchen anstatt das per Root zu machen, Danke auch hierfür.
Irgendwie sind es immer diese "Kleinigkeiten" die einen Einsteiger straucheln lassen.
Gruß,
Andreas.
Hallo Rudi,
ja, obwohl die Datei eine 8662 war, zeigte mir fhem eine noch viel ältere Version an, obwohl ich vorher shutdown restart gemacht habe. Jetzt habe ich fhem mal gestoppt, nur jetzt startet es nicht mal mehr... ,-(
Leider habe ich jetzt heute keine Zeit mehr da weiter nach zu suchen, werde mich morgen noch mal kurz damit beschäftigen.
Gruß,
Andreas.
Hallo,
irgendwie habe ich mir die virutelle Maschine zerschossen... ,-(
Hab fhem jetzt zwar wieder lauffähig, aber das System und auch die Weboberfläche von fhem reagiert jetzt teilweise anders als vorher. Werde wohl mal eine neue Maschine anlegen und dort weiterprobieren.
Ich habe aber noch mal das Einbinden des Sticks probiert, jetzt funktioniert es (mit Version 8662) im Log tauchen dann recht viele 2015.05.31 12:44:41 4: ZWDongle_0: CANCEL received, retransmit nr. 1
2015.05.31 12:44:41 5: SW: 01030007fb
2015.05.31 12:44:41 5: ZWDongle RAW buffer: 18
2015.05.31 12:44:41 4: ZWDongle_0: CANCEL received, retransmit nr. 1
2015.05.31 12:44:41 5: SW: 01030007fb
2015.05.31 12:44:41 5: ZWDongle RAW buffer: 18
2015.05.31 12:44:41 4: ZWDongle_0: CANCEL received, retransmit nr. 1
auf.
Der Stick scheint da intern "beschäftigt" zu sein, reagiert dann aber in weniger als 1 Sekunde wieder.
Logfile ist angehängt.
Noch eine kleine Fragen zu SVN, lässt Du fhem dann in dem SVN Verzeichnis laufen? Was passiert dann bei einem Update aus fhem? SVN würde das ja dann als lokale Änderung ansehen, oder?
Gruß,
Andreas.
Bitte pruefe es nochmal mit den heute frueh eingecheckten Patches von gero.
Fuer Timing-Probleme setze ich "attr global mseclog".
Mein Test-FHEM laeuft im SVN Verzeichnis, ich huete mich davor, hier ein fhem-update durchzufuehren. Wenn es doch passieren sollte, dann muss man ein "svn revert FHEM/*" ausfuehren. Fuer update-Tests habe ich ein separates Verzeichnis ohne SVN.
Hi,
so jetzt noch mal mit der Version 8670 aus dem SVN. Die "retransmit" Messages sind jetzt weg, dafür habe ich jetzt die ganzen "partial messages" ,-) Aber das soll ja wohl so sein ,-)
Das mit dem Starten von der Console und den Ausgaben in die Console ist wirklich praktisch, aber ein "echtes" Logfile hat auch Vorteile... Habe gerade mal ausprobiert das mit dem Befehl "tee" zu kombinieren um die Ausgaben in der Konsole UND in einem File zu haben, scheint zu funktionieren.
perl fhem.pl fhem.cfg | tee -a /opt/fhem/log/fhem.log
Danke für den Tip!
Gruß,
Andreas.
@Andreas: ich gehe davon aus, dass damit dein Problem geloest ist.
Das Problem der unfertigen Verschluesselung bleibt natuerlich.
Hallo Rudi,
Zitat von: rudolfkoenig am 31 Mai 2015, 14:20:31
@Andreas: ich gehe davon aus, dass damit dein Problem geloest ist.
Das Problem der unfertigen Verschluesselung bleibt natuerlich.
yep, Start und Einbinden des Sticks funktionieren jetzt.
Verschlüsselung ist weiter offen, Ich installiere mir jetzt erst mal eine neue virtuelle Maschine für das Testing mit fhem, richte mir das dann direkt unter SVN ein und schau mal was ich dann so rauskriege. Allerdings bin ich noch nicht dazu gekommen mir mal eine Installation von OpenZWave anzulegen. So wie ich das von Christian verstanden habe muss man das unter Linux selber kompilieren da es kein Paket gibt. Werde ich mir dann auf der neuen Maschine mal ansehen, dann könnte ich da direkte Vergleiche machen.
Danke für die ganze Arbeit die Du hier investierst, scheinst ja beinahe rund um die Uhr aktiv zu sein!
Andreas.
Ein über Fhemweb gesetztes Attribut
networkKey 12345678901234567890123456789012kann ich nicht über Link "deleteattr" bzw. den entspechenden Befehl löschen. Es erscheint dann immer die Meldung:
Zitatattr ZWDongle_0 networkKey: not a hex string with a length of 32
Es geht nur der Weg über direktes Edit der fhem.cfg.
Habs gefixt.
so. habs endlich geschafft, ein logfile von z-way zu erzeugen :) :) :)
(Gar nicht so einfach, das Gerät in managment modus zu versetzen, 1 zu drücken und gleichzeitig den Controller auf secure inclusion zu bringen; damit die re-inklusion gelingt!)
ich bin ja mal auf die Auswertung von euch gespannt...
Auf jeden Fall kommen jetzt beim Tastendruck 1 unterschiedliche Codes an.
zum LogFile: ich habe an 3 Stellen "changed_micha" eingefügt:
kurz bevor die Inklusion des Device.30 gelungen ist und bevor ich Taste 1 und Taste 2 jeweils 2mal gedrückt habe...
ab Zeile 623 gehts los :)
mfg
micha
p.s. Falls ich zuviel im Logfile gelöscht habe, kann ich den Rest gerne noch liefern, sind allerdings 2,9MB...
fhem output Button 2:
2015.06.12 04:31:30 5: ZWDongle RAW buffer: 01080004001e02984037
2015.06.12 04:31:30 5: ZWDongle_Read ZWDongle_0: ACK, processing 0004001e029840
2015.06.12 04:31:30 5: SW: 06
2015.06.12 04:31:30 5: ZWDongle_0 dispatch 0004001e029840
2015.06.12 04:31:30 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:029840
2015.06.12 04:31:30 5: Triggering ZWave_Node_30 (1 changes)
2015.06.12 04:31:30 5: Notify loop for ZWave_Node_30 UNPARSED: SECURITY 029840
2015.06.12 04:31:30 5: statistics mod_stats: Notify.260 Notification of 'ZWave_Node_30' received. Device not monitored.
2015.06.12 04:31:30 5: ZWave_ProcessSendStack: 0 items on stack, waitForAck 0
Warum genau sollten wir das logfile auswerten?
Wg. secure-inclusion habe ich vom krikan einen vmtl. perfekten Log, ich (oder sonstwer) muesste es nur weiter "abarbeiten".
Zunaechst muss ich gero's ACK-Code anpassen (secNonce wird vom controller nicht bestaetigt, und deswegen neuerdings 5-mal rausgeschickt, die Antwort kommt deswegen erst 5 Sekunden spaeter), und danach die AES Verschluesselung implementieren.
Hi,
Zitat von: rudolfkoenig am 12 Juni 2015, 08:38:23
Zunaechst muss ich gero's ACK-Code anpassen (secNonce wird vom controller nicht bestaetigt, und deswegen neuerdings 5-mal rausgeschickt, die Antwort kommt deswegen erst 5 Sekunden spaeter), und danach die AES Verschluesselung implementieren.
ab nächster Woche kann ich auch wieder ein wenig mitmachen, bin dann nur im Juli in Urlaub ,-)
Ich muss mich aber dann erst noch mal ein wenig mit den verschiedenen Blockmethoden bei der AES-Verschlüsselung auseinandersetzen, der benötigte Modus wird ja anscheinend von OpenSSL:AES nicht direkt unterstützt.
Eine Möglichkeit wäre natürlich "einfach" den cpp-Code von OpenZwave umzusetzen, fände ich aber umständlich.
Möglicherweise lässt sich da auch was mit der Rijndael Implementierung machen oder durch geschicktes initialisieren in einem anderen Blockmode.
Alles Arbeit für die nächste(n) Woche(n), wobei Du ja wahrscheinlich wieder fertig bist bevor wir hier halb durchgestiegen sind ,-)
Gruß,
Andreas.
Zitat von: rudolfkoenig am 12 Juni 2015, 08:38:23
Warum genau sollten wir das logfile auswerten?
Wg. secure-inclusion habe ich vom krikan einen vmtl. perfekten Log, ich (oder sonstwer) muesste es nur weiter "abarbeiten".
ja, wegen CC security dachte ich, vielleicht hilfts ja?
Dann hast du jetzt 2 Logfiles :) im Fall eins verloren geht
Hallo zusammen,
so, melde mich mal zurück...
Und hätte auch gleich eine Frage:
Klappt die "Secure"-Einbindung bei euch noch? Ich habe ja mein Testsystem auf einen anderen Rechner verlagert und dann nur ganz kurz damit rumprobiert und hatte dabei dieses Problem mit "homeID not set" durch die "cancel"-Antwort. Das war dann ja behoben und ich habe danach auch mindestens zwei mal die Sirene eingebunden und dabei wurde Security-Scheme, Networkkey und Nonce übertragen.
Ich habe nun eine Update vom System gemacht und das funktioniert nun leider nicht mehr. Die Sirene nur normal eingebunden, der ganze Security Ablauf wird nicht mehr gemacht. Bei der Sirene wird aber weiterhin Security in den Capabilities gemeldet.
Networkkey ist nachwievor definiert. Habe ich in der Zwischenzeit irgendetwas verpasst das noch gemacht werden muss damit das wieder funktioniert?
Und noch was, bei der Durchsicht der damaligen Logfiles ist mir aufgefallen das dort:
1.) Add-Node
2.) Scheme-Get / Scheme-Report
3.) Networkkey_Set
4.) Nonce-Get / Nonce-Report
abläuft.
Laut der Doku sollte es aber
2.) Scheme-Get/-Report
3.) Nonce-Get/-Report
4.) Networkkey-Set/-Verify
sein.
In meinen Logs kann ich aber auch keine Timer erkennen, da sind aber auch so etliche Pakete dabei die ich nicht zuordnen kann, vielleicht ist es eins davon.
Gruß,
Andreas.
ZitatKlappt die "Secure"-Einbindung bei euch noch?
Na geklappt hat es noch nie, aber es sollte keine Fehler produzieren, und bis nonceReport laufen.
Und auf irgendwelche timer wird noch gar nicht aufgepasst.
Hi,
es läuft aber jetzt erst gar nicht mehr bis Nonce-Report, selbst Scheme-Get wird nicht mehr gesendet.
Irgendein Tip was jetzt wieder klemmt?
Gruß,
Andreas.
Nein. Ich lass dir diesmal den Vortritt bei der Analyze :)
Dass Secure inclusion durch "addnode on sec" aufgerufen wird hast Du beachtet?
Hi,
Zitat von: krikan am 22 Juni 2015, 21:20:12
Dass Secure inclusion durch "addnode on sec" aufgerufen wird hast Du beachtet?
Nö... Seid wann das denn?
Sollte der Befehl im drop-down vom ZWDongle erscheinen? Ich habe da jedenfalls nichts...
Argh, klappt bei mir das svn update schon wieder nicht richtig?
00_ZWDongle.pm ist 8760
10_ZWave.pm ist 8749
Gruß,
Andreas.
Ist noch(?) nicht im DropdownMenu enthalten. Setze es über Eingabefeld ab. Ist seit Kurzem drin; war mein Wunsch.
Hi,
ok, hab' den anderen Thread gefunden und es bereits über Kommandozeile abgesetzt. Hat jetzt auch wieder was mit Security beim Einbinden gemacht.
Vielen Dank für den Hinweis, hatte gerade angefangen mir ein Log-Messages in den Code zu setzen um zu sehen wo der "falsch abbiegt".
Gruß,
Andreas.
Hallo,
so habe mir jetzt noch mal das erste Logfile von Krikan mit OpenZwave und dem KFOB genauer angesehen und verstehe nicht wie das funktionieren kann...
Da wird entgegen der vorhandenen Doku mehrmals der Networkkey im Klartext übertragen, wird aber auch nicht irgendwie vom KFOB bestätigt. Laut Doku müsste der Networkkey verschlüsselt übertragen werden und mit einer ebenfalls verschlüsselten NetworkkeyVerify Message beantwortet werden, die ich aber im Log nicht finden kann.
Dann gibt es das Scheme Get/Report, Nonce Get/Report und dann gibt es eine verschlüsselte Antwort, bei der aber anscheinend die CBC-MAC Verschlüsselung nicht passt und es weggeworfen wird.
Trotzdem kann später verschlüsselt ein SupportedGet / SupportedReport gesendet bzw. empfangen werden.
Ein einziges Mysterium...
Ich werde mir übermorgen mal das andere Logfile mit der DSD31-Sirene ansehen und mal schauen was da so im Logfile zu finden ist.
Ich habe noch ein paar verstreute Infos bzg. der AES-Implementierung gefunden, anscheinend braucht man drei verschiedene Blockmodi:
ECB, CBCMAC und OFB. Außerdem braucht man zwei "Passwörter", ich hoffe das ich die in dem OpenZwave Code finde.
Gruß,
Andreas.
Hallo Rudi, hallo Christian,
ich bräuchte mal wieder einen "Schubs" in die Richtige Richtung...
Ich verstehe zwar immer noch nicht wieso die Reihenfolge von OpenZWave funktioniert, wollte jetzt aber erst mal den gleichen Zustand herstellen. Habe mir daher mal das Log von Christian mit der Sirene angeschaut, die gleiche habe ich ja auch.
Vergleich der OpenZWave und FHEM Logs zeigt das bei "uns" momentan ein NonceGet/Report an der falschen Stelle ist und wir keinen NonceGet REQUEST vom Gerät erhalten:
[s=gesendet, r=empfangen]
OpenZWave:
01: s:SchemeGet / r:SchemeReport
02: s:NonceGet / r:NonceReport
03: s:NetworkkeySet
04: r:NonceGet / s:NonceReport
05: r: Encrypted Message
[einige unverschlüsselte Nachrichten]
06: s:NonceGet / r:NonceReport
07: s.SupportedGet
08: r:NonceGet / s:NonceReport
09: r: Encrypted Message
Fhem:
01: s:SchemeGet / r:SchemeReport
02: fehlt
03: s:NetworkkeySet
04: s:NonceGet / r:NonceReport
D.h. anscheinend gibt es ohne das NonceGet an Position 02 auch keine Rückanfragen bei 04.
Ich habe dann mal versucht das NonceGet in der Reihenfolge in ZWave_secureInit(@) zu ändern:
if($status == 1) {
ZWave_Set($hash, $name, "secScheme");
return ""; # not evaluated
} elsif($status == 2) {
ZWave_Set($hash, $name, "secNonce");
return undef; # No Event/Reading
} elsif($status == 3) {
Log3 $iodev, 4, "secScheme report: $param";
my $key = AttrVal($iodev->{NAME}, "networkKey", "");
ZWave_Set($hash, $name, ("secKey", $key));
return undef; # No Event/Reading
} elsif($status == 4) {
IOWrite($hash, "secKey ACK", "");
ZWave_Set($hash, $name, "secNonce");
return undef; # No Event/Reading
} else {
Log3 $iodev, 4, "secNonce report: $param";
delete $iodev->{secInitName};
delete $hash->{secStatus};
return ZWave_execInits($hash, 0);
}
Jetzt scheint aber die Reihenfolge der Befehle "durcheinander" zu geraten.
01: s:SchemeGet, r:SchemeReport
02: s:NonceGet
03: s:NetworkkeySet
04: r:NonceReport
D.h. der NetworkkeySet Befehl wird gesendet bevor die Antwort auf den NonceGet empfangen wurde. Die kommt dann zwar später, die Sirene sendet aber dann selbst keinen NonceGet Befehl mehr aus, ich habe sogar ein "Cancel" bekommen...
Ein gekürztes/kommentiertes Log habe ich angehängt.
Ich muss zugeben das ich das System nach dem die Nachrichten gesendet/empfangen werden nicht ansatzweise verstanden habe, daher habe ich jetzt auch keine Idee wie ich an einer Stelle gezielt auf eine Antwort warten kann bevor ich dann weitermache.
Wenn wir die "richtige" Reihenfolge hinbekommen würden müsste das Device im nächsten Schritt ja selbst noch mal nach der Nonce fragen und dann den Networkkey durch die verschlüsselte Nachricht (die ich noch nicht dekodieren kann...) bestätigen.
Gruß,
Andreas.
Hallo,
ich habe es nun doch hinbekommen die Befehle in der Reihenfolge:
01: s:SchemeGet / r:SchemeReport
02: s:NonceGet / r:NonceReport
03: s:NetworkkeySet
abzusetzen, allerdings passiert danach nichts, fhem macht mit Association, Manufacterspecific etc weiter.
Die SIrene fragt nicht mit NonceGet...
Hmm, wie geht das denn mit den Timern? Werden die vielleicht bei OpenZWave im Hintergrund verarbeitet und sind nicht im Logfile zu erkennen?
Jetzt bin ich erstmal wieder etwas ratlos warum sich da nicht das gleiche Verhalten ergibt...
Das von mir dabei benutzte 10_ZWave.pm habe ich mal angehängt, Logfile ebenfalls.
Gruß,
Andreas.
Andreas, du erwartest zu viel von mir, und vmtl. auch von Christian.
Wir wissen nicht im Detail wie die abgesicherte Kommunikation zu funktionieren hat, das was implementiert ist, ist weit von Fertig. Der naechste Schritt ist die Ver- bzw. Entschlueselung der Daten mit AES zu implementieren. Da in dem Log alle Schluessel, verschluesselter Text und Klartext enthalten ist, kann man das ohne Hardware machen. Wenn man es kann, ich jedenfalls noch nicht auf Anhieb. Ich brauche keine Tester, sondern viel Zeit dafuer, oder Patches.
Timer sind im Moment egal, die sichern nur, dass nicht jemand trotz aktivierten Security Befehle einschleusen oder wiederholen kann. Soweit sind wir aber noch gar nicht.
Hallo Rudi,
Zitat von: rudolfkoenig am 26 Juni 2015, 08:03:54
Andreas, du erwartest zu viel von mir, und vmtl. auch von Christian.
nicht das da Missverständnisse aufkommen, ich erwarte ja auch gar nichts fertiges, ich habe aber noch ziemliche Probleme den internen Ablauf in FHEM bei der Kommunikation mit dem ZWDongle zu verstehen. Das Problem mit der Reihenfolge der Befehle habe ich ja sogar doch noch selbst gelöst bekommen.
Zitat von: rudolfkoenig am 26 Juni 2015, 08:03:54
Wir wissen nicht im Detail wie die abgesicherte Kommunikation zu funktionieren hat, das was implementiert ist, ist weit von Fertig. Der naechste Schritt ist die Ver- bzw. Entschlueselung der Daten mit AES zu implementieren. Da in dem Log alle Schluessel, verschluesselter Text und Klartext enthalten ist, kann man das ohne Hardware machen. Wenn man es kann, ich jedenfalls noch nicht auf Anhieb. Ich brauche keine Tester, sondern viel Zeit dafuer, oder Patches.
Bis zu dem Zeitpunkt an dem die verschlüsselte Anfrage des "SupportedGet" erfolgt braucht man auf der Controller Seite ja anscheinend erst mal keine Verschlüsselung (zumindest nach den Logs von OpenZWave), daher dachte ich, es wäre schon mal gut so weit zu kommen dass das Device schon mal eine verschlüsselte Nachricht schickt, auch wenn wir die zur Zeit noch nicht entschlüsselen können. (Ich kann aber z.B. auch mit der entschlüsselten Antwort von OpenZWave nichts anfangen...)
Nur leider reagiert die Sirene trotz erst mal "richtigem" Ablauf nicht so wie sie es mit OpenZWave tut. ;-(
Ich werde mir dann wohl doch auch ein OpenZWave installieren und auch dort mal ein paar weitere Logzeilen erzeugen damit (für mich) klarer verständlich wird was da passiert. Momentan kann ich mir noch vorstellen das der NetworkkeySet bereits verschlüsselt gesendet wird, die Verschlüsselung aber nicht im Logfile angezeigt wird. Das würde dann auch wieder eher mit dem in der Doku beschriebenen Ablauf passen und würde dann erklären warum es keine verschlüsselte Bestätigung von der Sirene gibt.
Noch mal, ich erwarte nicht das Du das alles (alleine) machst, ganz im Gegenteil, Du machst hier schon mehr als man erwarten kann! Ich bin dabei mich einzuarbeiten und werde auch aktiv Patches schreiben wenn es denn Fortschritte gibt, nur leider fehlt mir (noch) das globale Verständnis wie fhem intern so arbeitet und der Einstieg ist da nun mal leider nicht soo leicht.
Was die AES Verschlüsselung angeht stehe ich da noch genauso auf dem Schlauch, habe aber inzwischen noch ein paar weitere Informationsfetzen im Internet finden können. Ich fürchte jedoch, dass es am effektivsten sein wird den OpenZWave Code zu analysieren und die Funktionen von dort nachzubilden.
Ich werde also mal OpenZWave installieren und mir den Code von dort mal genauer ansehen und dann versuchen die benötigten AES Funktionen dort zu extrahieren bzw. zu schauen ob die AES Implementation von Perl das nicht doch kann.
Sorry wenn die letzten Nachrichten "fordernd" rüberkamen, so war das wirklich nicht gemeint.
Gruß,
Andreas.
Hallo Andreas,
lese Deine Beiträge zwar mit, aber werde Dir mangels Kenntnissen nur wenig helfen können. Wenn es etwas zu testen gibt, bin ich dabei. Würde mich freuen, wenn Du am Thema dranbleibst ;).
Gruß Christian
Hi,
momentan bleibe ich ja meist bei allgemeinen Sachen hängen, da bin ich dann für jeden Tip dankbar.
Ich bleib' auf jeden Fall dran, auch wenn ich selbst Security momentan ja gar nicht brauche, ob die Sirene jetzt per SECURITY eingebunden ist macht für mich momentan keinen Unterschied. Ich brauchte damals den USER-CODE für den RFID-Leser, da habe ich von euch profitiert, da kann ich jetzt vielleicht auch noch was zum System beisteuern.
Sobald es wieder was gibt poste ich das hier, oder sollten wir vielleicht für SECURITY einen eigenen, neuen Thread aufmachen?
@Rudi, was sagst Du?
Ich bin aber ab Mitte nächster Woche auch erst einmal für 2.5 Wochen in Urlaub...
Gruß,
Andreas.
Ich habe kein Problem mit einem eigenen Thread.
Zitat von: rudolfkoenig am 14 Mai 2015, 21:16:14
Ist zwar nicht direkt KFOB/SECURITY Thema, will aber kein Thread dafuer oeffnen: beim Inclusion wird nicht nur ein "associationAdd 1 ctrlId" durchgefuehrt sondern auch ein "get Name model", natuerlich nur, falls das Geraet die passende Klasse unterstuetzt. Das Ganze ist konfigurabel (init Zeiger in der zwave_class/zwave_deviceSpecial), damit koennen wir je nach Model was anstellen.
Auch eine Ergaenzung mit zusaetzlichen Klassen/etc ist moeglich, allerdings noch nicht programmiert.
Falls jemand eine Wunschliste hat, bitte melden.
Für die langfristige (Off-Topic) Wunschliste:
Bei Inclusion in den Config-XMLs nachschauen und bei der/den Assoziationgruppe(n) mit dem Eintrag auto="true" zusätzlich "associationAdd GroupId ctrlId" durchführen.
Beispielsweise beim FGRM222 "associationAdd 3 ctrlId":
https://github.com/OpenZWave/open-zwave/blob/master/config/fibaro/fgrm222.xml
<!-- Association Groups -->
<CommandClass id="133">
<Associations num_groups="3">
<Group index="1" max_associations="16" label="Group 1" auto="false"/>
<Group index="2" max_associations="16" label="Group 2" auto="false" />
<Group index="3" max_associations="1" label="Device Status" auto="true"/>
</Associations>
</CommandClass>Bei ZwavePlus-Geräten kann man das wahrscheinlich auch ohne Config-XMLs über die CC ASSOCIATION_GROUP_INFO lösen. Nach meinem Verständnis ist die dort gemeldete Group "Lifeline" die entscheidende. Aber das ist meine Langfrist-Liste....
Habe das automatische associationAdd aus der configfile eingebaut, aber nur "trockentests" gemacht.
Wird fuer alle Gruppen ausgefuehrt, wo auto auf true steht, und index nicht 1 ist.
Das bisherige unkonditionale "set $name associationAdd 1 $CTRLID" bleibt weiterhin erhalten.
Danke. Du bist zu schnell; komme aber erst in den nächsten Tagen zum Testen.
Zitat von: rudolfkoenig am 13 Juli 2015, 18:55:37
Das bisherige unkonditionale "set $name associationAdd 1 $CTRLID" bleibt weiterhin erhalten.
Das war auch mein Gedanke, darum schrieb ich von "zusätzlich". Besser eins zu viel als eins zu wenig...