[Aufruf] IKEA-Trådfri Adapter testen
-
> mdns@2.3.3 install /opt/iobroker/node_modules/mdns > node-gyp rebuild make: Entering directory '/opt/iobroker/node_modules/mdns/build' CXX(target) Release/obj.target/dns_sd_bindings/src/dns_sd.o In file included from ../src/dns_sd.cpp:1:0: ../src/mdns.hpp:32:20: fatal error: dns_sd.h: Datei oder Verzeichnis nicht gefunden #include <dns_sd.h> ^ compilation terminated. dns_sd_bindings.target.mk:149: recipe for target 'Release/obj.target/dns_sd_bindings/src/dns_sd.o' failed make: *** [Release/obj.target/dns_sd_bindings/src/dns_sd.o] Error 1 make: Leaving directory '/opt/iobroker/node_modules/mdns/build'</dns_sd.h> ```` `Da haben wir's doch! Ich schau, wie man das beheben/verhindern kann. `
Das ist nicht das Problem. Da fehlen ein nur ein paar Abhängigkeiten für mdns.
Ein apt-get install libavahi-compat-libdnssd-dev behebt den Fehler beim Installieren von mdns.
Ich hab auch schon libcoap installiert bzw. kompiliert. Aber auch damit bringt der Adapter den bekannten Fehler.
Nochwas:
Ich weiß nicht obs Dir beim Fehler suchen hilft, aber der Adapter schmiert nur ab, wenn man die IP vom Ikea-Gateway eingibt.
MfG
Chris
-
Danke für die zahlreichen Infos. Ich kann noch nichts versprechen, da ich aktuell nicht viel Zeit habe, aber ich versuche im Laufe der Woche nachzuvollziehen, was da bei euch schief läuft.
Dass keine Objekte angelegt werden, ist zu erwarten, da der Adapter keine Verbindung herstellt. Die Objekte sollten bei erfolgreicher Verbindung angelegt werden.
–-
Update: Ich kann euer Problem mittlerweile reproduzieren. Bei Ausführung über Konsole gibt es weitere Infos:
io.tradfri.0: ../../nan/nan.h:704: Nan::MaybeLocal <v8::object>Nan::CopyBuffer(const char*, uint32_t): Assertion `size <= imp::kMaxLength && "too large buffer"' failed.</v8::object>Wenn ich jetzt noch wüsste, warum das vorher bei mir funktioniert hat…
-
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 ....
-
Hallo zusammen!
Ich habe mal ein bischen angefangen zu debuggen- um einzugrenzen wo der crash passiert:
Es liegt an coapClient.js
Line 147 - 172
Mehr Details habe ich noch nicht, aber vielleicht hilft's ja ….
-
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 ist sicher eine gute Idee.
Ich bin auch noch einen Schritt weiter:
Das Problem liegt in coap-dtls/index.js , bei der Instantiierung des Agent ab Zeile 41 - 52.
-
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
-
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.
-
Ich habe gerade das erste Mal erfolgreich per DTLS mit dem Gateway kommuniziert.
Jetzt noch ein bisschen Code aufräumen, dann ist CoAP dran. Sollte also bald was zum Testen geben.
-
Ich steh schon in den Startlöchern
-
CoAP funktioniert auch
Jetzt noch kleine Änderungen am Adapter selbst und es kann losgehen! -
CoAP funktioniert auch
Jetzt noch kleine Änderungen am Adapter selbst und es kann losgehen! `
Na dann, ich sitze schon auf heißen Kohlen -
Schon mal eine Frage vorweg, kann ich über den Adapter auch direkt eine Lampe am Gateway anlernen oder muss ich da zwingend eine Fernbedienung haben?
