NEWS
[Aufruf] IKEA-Trådfri Adapter testen
-
Ich habe mal nach Alternativen geschaut:
-
mbed-dtls (aktuelle Lösung, problematisch)
-
tiny-dtls (in C geschrieben, schlecht bis nicht dokumentiert, muss ich irgendwie wrappen)
-
node-dtls (nodeJS, aber kann nur RSA, kein PSK wie von Tradfri benötigt, Code ist etwas… äääh unübersichtlich)
-
libcoap (kann kein DTLS, der beigelegte client erfordert pro überwachter Ressource [das sind einige] einen neuen Prozess)
Habe mich jetzt entschieden, DTLS und CoAP selbst zu implementieren, das wird aber noch ein bisschen dauern…
-
-
Hallo!
"Update: Ich kann euer Problem mittlerweile reproduzieren. Bei Ausführung über Konsole gibt es weitere Infos:
Code:
io.tradfri.0: ../../nan/nan.h:704: Nan::MaybeLocal v8::objectNan::CopyBuffer(const char*, uint32_t): Assertion `size <= imp::kMaxLength && "too large buffer"' failed.
Wenn ich jetzt noch wüsste, warum das vorher bei mir funktioniert hat…"
Nun, ohne der große JS Experte zu sein:
Ich würde vermuten das wenn das auf RPi NICH läuft, auf anderen Umgebungen schon würde ich schlicht vermuten das es daran liegt, das der standardmäßig für JAVA bereitgestellte Speicher auf dem RPi schlicht kleiner ist als in anderen Umgebungen.
Das ist denke ich aber eher Symptom und nicht Ursache. Die Frage ist: Was braucht denn im tradfri Adapter so eine Menge an Speicher, denn offensichtlich ist die Größe, also der Wert des 1. Parameters zu groß ....
Ich bekomme diese start/crash schleife auch ohne eigegebene IP/Securitycode ....</v8::object>
-
So, ich muss nun meinen Beitrag ergänzen - das Fehlerbild hat sich geändert.
Mein erstes Problem war: Die Prozedur zum Entfernen von node.js 4 hat wohl nicht funktioniert - und so hatte ich v4 und v7 parallel ( fieser weise hat die Command-line auf v7 zugegriffen, aber ioBroker auf v4).
Somit bin ich jetzt bei dem Status: Keine IP eingetragen –> Adapter läuft.
"Irgend eine IP - nur kein tradfri gate" --> Adapter sended coap request - und bekommt natürlich keine Antwort.
Sobald ich die IP vom Gate eingebe - auch ohne Securitycode crasht der Adapter mit
"host.csprint01 2017-05-30 16:43:38.925 error instance system.adapter.tradfri.0 terminated with code null ()
host.csprint01 2017-05-30 16:43:38.924 warn instance system.adapter.tradfri.0 terminated due to SIGABRT"
So ins Blaue geraten also dann wenn der client irgendwas antwortet ....
-
Danke für den Input. Mir ist bewusst, dass es an den 3rd-party libs liegt - irgendwas mit fehlerhafter Buffer-Größe. Hatte weiter oben auch schon mal einen Log gepostet mit dem exakten Fehler.
Was mich nur wundert:
Ich habe die erste Version auf einem Raspi 2 entwickelt, auf dem vorher schon einiges anderes installiert war. Da hats einwandfrei funktioniert. Die CI-Tests ebenfalls.
Dann kamen die ersten Nutzer, die es auf diversen Systemen nicht ausführen konnten. Auf einem frisch aufgesetzten Raspi (2 oder 3, weiß ich gerade nicht) ging es dann plötzlich auch bei mir nicht mehr. Irgendwas scheint also zu fehlen, nur was…?
Naja, ich werde die COAP und DTLS-Libraries demnächst durch eigenen Code ersetzen - ist nicht so schrecklich umfangreich auf der Client-Seite. Bin nur gerade im Umzugsstress, da ist keine Zeit für so Spielchen.
-
Das Problem müsste eigentlich im Paket mbed-dtls liegen, da hier die Bindings zum nativen C-Code liegen.
https://github.com/AlCalzone/node-mbed- … master/src
Wenn du die exakte Stelle finden solltest, lass es mich wissen. Ansonsten werde ich (sobald ich Zeit habe) die Libraries durch selbstgeschriebenen Code (reines JS) ersetzen.
-
Damit kann ich dienen:
in node-mbed-dstl\client_socket.js
Zeile 52: Bei der Instantiierung von mbed.DtlsClientSocket kracht's …..
Gruß
Smartie `
… ich nehm alles zurück und behaupte das Gegenteil ....
Dar Aufruf
const data = this.mbedSocket.receiveData(msg);
in client_socket.js macht das Problem. (So um Zeilennummer 85).
-
Gibts in dieser Richtung was neues ?
Häng auch da und warte auf ne Lösung oder nen workaround…...
Thx
Sunny
-
Bin dran, dauert leider noch etwas. Die Implementierung von (D)TLS ist recht aufwändig und ich war die letzten Wochen nur unterwegs. Bin auf jeden Fall dran, da ich den Adapter in meiner Wohnung auch brauche.
Gesendet von iPhone mit Tapatalk
-
Hallo AlCalzone,
ohne hetzen zu wollen,
gibts was neues?
SirTwist
-
Habe letzte Woche die ersten Kommunikationsversuche per DTLS unternommen und einige Fehler ausgebaut. Prinzipiell funktioniert der Handshake (Austausch der Verschlüsselungsinformationen).
Allerdings habe ich dabei gemerkt, dass das Gateway nur AEAD-Verschlüsselungsmethoden unterstützt, die ich noch nicht implementiert hatte. Da komme ich frühestens Donnerstag dazu… habe leider momentan fast jede Minute neben der Arbeit verplant. Dann kann ich endlich testen, ob der reguläre Datenaustausch auch funktioniert.
CoAP steht dann auch noch an. Das scheint zumindest in einer rudimentären Variante nicht besonders viel zu werden.
-
CoAP funktioniert auch :) Jetzt noch kleine Änderungen am Adapter selbst und es kann losgehen! `
Na dann, ich sitze schon auf heißen Kohlen ;) -
Du kannst (nur?) die Fernbedienung an ioBroker anbinden, dort aber die einzelnen Lampen auswählen.
So war es bei der ersten Version
Gruß
Rainer
-
Soweit ich mich erinnere wird die Fernbedienung benötigt, um die Lampen ans Gateway anzulernen. Es kann sein, dass sie danach nicht mehr benötigt wird.
Geräte anlernen etc. war im Adapter noch nicht unterstützt. Damals kam das ganze Inkompatibilitätsproblem auf, wo ich mich erst drum kümmern musste.
Vielleicht geht das später mal ohne Fernbedienung, aber da will ich mich nicht zu weit aus dem Fenster lehnen.
Support us
908
Online32.5k
Benutzer81.6k
Themen1.3m
Beiträge