UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[siggi85]

@sub1ne sagte in [Aufruf] deConz Adapter Testen 1.1.2:

@siggi85: wie ist dann der Post von Gerni zu verstehen:

@Gerni said in [Aufruf] deConz Adapter Testen 1.1.2:

@siggi85 wenn man das deconz Gateway öffnet, in Alexa neue Geräte sucht verbindet die sich mit dem Gateway und Geräte sind in Alexa vorhanden.

Der iot Adapter ist aber nicht die ioBroker Cloud Anbindung, oder?

Doch.
Ob es andere Möglichkeiten durch deConz gibt, wie @Asgothian sie beschreibt, wusste ich bisher nicht.

[wtfka]

Hallo,

ich habe heute das Ubuntu-Paket deconz auf die neueste Version upgedated und bekomme nun in iobroker folgende Fehlermeldungen:

host.nuc	2019-09-07 14:28:14.973	error	instance system.adapter.deconz.0 terminated with code 0 (OK)
host.nuc	2019-09-07 14:28:14.973	error	Caught by controller[0]: at endReadableNT (_stream_readable.js:1145:12)
host.nuc	2019-09-07 14:28:14.973	error	Caught by controller[0]: at IncomingMessage.emit (events.js:203:15)
host.nuc	2019-09-07 14:28:14.973	error	Caught by controller[0]: at Object.onceWrapper (events.js:286:20)
host.nuc	2019-09-07 14:28:14.973	error	Caught by controller[0]: at IncomingMessage.<anonymous> (/opt/iobroker/node_modules/request/request.js:1083:12)
host.nuc	2019-09-07 14:28:14.973	error	Caught by controller[0]: at Request.emit (events.js:198:13)
host.nuc	2019-09-07 14:28:14.973	error	Caught by controller[0]: at Request.<anonymous> (/opt/iobroker/node_modules/request/request.js:1161:10)
host.nuc	2019-09-07 14:28:14.973	error	Caught by controller[0]: at Request.emit (events.js:198:13)
host.nuc	2019-09-07 14:28:14.973	error	Caught by controller[0]: at Request.self.callback (/opt/iobroker/node_modules/request/request.js:185:22)
host.nuc	2019-09-07 14:28:14.973	error	Caught by controller[0]: at Request._callback (/opt/iobroker/node_modules/iobroker.deconz/main.js:692:28)
host.nuc	2019-09-07 14:28:14.973	error	Caught by controller[0]: at JSON.parse (<anonymous>)
host.nuc	2019-09-07 14:28:14.973	error	Caught by controller[0]: SyntaxError: Unexpected token < in JSON at position 0
deconz.0	2019-09-07 14:28:14.461	error	SyntaxError: Unexpected token < in JSON at position 0 at JSON.parse (<anonymous>) at Request._callback (/opt/iobroker/node_modules/iobroker.deconz/main.js:692:28) at Request.self.callback
deconz.0	2019-09-07 14:28:14.461	error	uncaught exception: Unexpected token < in JSON at position 0
deconz.0	2019-09-07 14:28:14.450	info	starting. Version 1.1.2 in /opt/iobroker/node_modules/iobroker.deconz, node: v10.16.3
host.nuc	2019-09-07 14:28:14.082	info	instance system.adapter.deconz.0 started with pid 5406
host.nuc	2019-09-07 14:27:44.074	info	Restart adapter system.adapter.deconz.0 because enabled
host.nuc	2019-09-07 14:27:44.074	error	instance system.adapter.deconz.0 terminated with code 0 (OK)
Caught	2019-09-07 14:27:44.073	error	by controller[0]: at endReadableNT (_stream_readable.js:1145:12)
Caught	2019-09-07 14:27:44.073	error	by controller[0]: at IncomingMessage.emit (events.js:203:15)
Caught	2019-09-07 14:27:44.073	error	by controller[0]: at Object.onceWrapper (events.js:286:20)
Caught	2019-09-07 14:27:44.073	error	by controller[0]: at IncomingMessage.<anonymous> (/opt/iobroker/node_modules/request/request.js:1083:12)
Caught	2019-09-07 14:27:44.073	error	by controller[0]: at Request.emit (events.js:198:13)
Caught	2019-09-07 14:27:44.073	error	by controller[0]: at Request.<anonymous> (/opt/iobroker/node_modules/request/request.js:1161:10)
Caught	2019-09-07 14:27:44.073	error	by controller[0]: at Request.emit (events.js:198:13)
Caught	2019-09-07 14:27:44.073	error	by controller[0]: at Request.self.callback (/opt/iobroker/node_modules/request/request.js:185:22)
Caught	2019-09-07 14:27:44.073	error	by controller[0]: at Request._callback (/opt/iobroker/node_modules/iobroker.deconz/main.js:692:28)
Caught	2019-09-07 14:27:44.073	error	by controller[0]: at JSON.parse (<anonymous>)
Caught	2019-09-07 14:27:44.072	error	by controller[0]: SyntaxError: Unexpected token < in JSON at position 0
deconz.0	2019-09-07 14:27:44.052	info	terminating
deconz.0	2019-09-07 14:27:43.546	error	at endReadableNT (_stream_readable.js:1145:12)
deconz.0	2019-09-07 14:27:43.546	error	at IncomingMessage.emit (events.js:203:15)
deconz.0	2019-09-07 14:27:43.546	error	at Object.onceWrapper (events.js:286:20)
deconz.0	2019-09-07 14:27:43.546	error	at IncomingMessage.<anonymous> (/opt/iobroker/node_modules/request/request.js:1083:12)
deconz.0	2019-09-07 14:27:43.546	error	at Request.emit (events.js:198:13)
deconz.0	2019-09-07 14:27:43.546	error	at Request.<anonymous> (/opt/iobroker/node_modules/request/request.js:1161:10)
deconz.0	2019-09-07 14:27:43.546	error	at Request.emit (events.js:198:13)
deconz.0	2019-09-07 14:27:43.546	error	at Request.self.callback (/opt/iobroker/node_modules/request/request.js:185:22)
deconz.0	2019-09-07 14:27:43.546	error	at Request._callback (/opt/iobroker/node_modules/iobroker.deconz/main.js:692:28)
deconz.0	2019-09-07 14:27:43.546	error	at JSON.parse (<anonymous>)
deconz.0	2019-09-07 14:27:43.546	error	SyntaxError: Unexpected token < in JSON at position 0
deconz.0	2019-09-07 14:27:43.545	error	uncaught exception: Unexpected token < in JSON at position 0
deconz.0	2019-09-07 14:27:43.522	info	starting. Version 1.1.2 in /opt/iobroker/node_modules/iobroker.deconz, node: v10.16.3

Der Adapter startet auch nicht mehr. Hat jemand eine Idee? Ist natürlich auch gut möglich, dass das Update damit nichts zu tun hat und das nur Zufall war.

Danke!

[Glasfaser]

@wtfka

Ich vermute mal , da fehlt was in den Einstellungen .
Zeig mal bitte deine Adapterkonfiguration vom deConz Adapter als Screenshot .

[wtfka]

@Glasfaser

Gerne und danke :)

Edit: Aus Spaß mal Port 8080 eingetragen und schon wird der Adapter grün. Bin mir ziemlich sicher, dass das vorher genau andersrum war?

[Glasfaser]

@wtfka

Der Eintrag Bridge Port fehlt

[GiuseppeS]

@Jey-Cee @Asgothian
Die deconz API liefert ja aktuell die States unter der bekannten fortlaufenden ID. Allerdings wird mit jeder Message über den WebSocket auch die UniqueID (MAC-Adresse) des Sensors / Lichts übertragen. Rein vom Scripting wäre es möglich die Uniqueid zu nutzen. Oder gibt es, abgesehen vom Aufwand der Programmierung, weitere Gründe, die dagegen sprechen?
Bei Sensors wäre die ID unwichtig, da Daten eh nur empfangen werden. (zur Not, wie z.B. Zeit für BWM, könnte Sensors komplett abgefragt werden und daraus die ID entnommen werden).
Bei aktiven Geräten könnte die ID als State unter der Geräte MAC gespeichert werden, da hier später auch über die Rest API aktiv ein State gesetzt werden muss. Über die MAC des geänderten Object könnte dann auf das State mit der ID zugegriffen und ein PUT request über die ID erfolgen.
Nur kurz erwähnt: bin mit meinen Scripting Skills weit davon entfernt einen Adapter zu programmieren. Im main.js verstehe ich einiges nicht wirklich.
Will aber gerne nach den JS Grundlagen auch weiter dazulernen :blush:

[Jey Cee]

@GiuseppeS die IDs auf die MAC zu ändern ist schon geplannt. Der Aufwand ist mässig, aber hat halt große Auswirkungen auf alte Installationen.
Ich werde versuchen Änderungen die ebenfalls so große Auswirkungen haben gleich mit rein zu nehmen.

[Asgothian]

@GiuseppeS
Ich habe auch ein wenig darüber nachgedacht, das aber dann schlussendlich verworfen. Eine Anordnung der Objekte im ioBroker die nicht 1:1 das abbildet was aus der RESTApi kommt bedarf bei jeder Nachricht eine Umsetzung zwischen den beiden Methoden. Das ist zwar erst einmal kein Problem, bedeutet aber entweder das die gesamte Struktur doppelt gespeichert wird (Einmal Organisiert wie in der API, einmal organisiert wie im ioBroker), oder das für jede Nachricht eine Umsetzung durch die Daten durchgeführt werden muss, was sich auf die Performance auswirkt.

Letztendlich stellt sich mir die Frage wozu das genau gut sein soll. Eine eindeutige Zuordnung zu bestimmten Hardware ID's wie sie im Zigbee Adapter genutzt wird hat Vor- aber auch Nachteile. Letztendlich müsste man das (um allen gerecht zu werden) konfigurierbar machen, so das sich die Anwender die Darstellung der Daten im IoBroker aussuchen können - was zu einem nennenswerten Mehraufwand bei der Betreuung führt. Ich sehe das aktuell nicht als machbar an.

A.

[GiuseppeS]

@Jey-Cee @Asgothian
Wenn direkt die UniqueID übernommen werden würde, wäre es nur ein mapping, daher kein Vorteil (mMn).
Aber wenn aus der UniqueID nur die MAC genutzt werden würde, könnten z.B. Multisensoren unter einem Objekt zusammengefasst werden.
Das wäre schon ein Fortschritt was die Übersicht angeht.

Bisher hatte ich noch keine Sensoren, bei denen relevante States mehrfach verteilt auf mehrere IDs verteilt werden. Beim MagicCube von Aqara könnte man das meinen, aber da wird allgemein der übergebene Parameter "gestures" nicht vom Adapter verarbeitet (will noch ein issue auf GH erstellen)

Andere Nachteile sehe ich jetzt nicht, wenn alles wie beim zigbee Adapter unter der MAC läuft.
Vorteil wäre nicht nur das Zusammenfassen mehrerer States unter einem Objekt; ein weiterer Vorteil wäre, dass nach einem Löschen und Neu-Anlernen von Zigbee Geräten die Skripte weiterhin funktionieren (da keine willkürlichen IDs sondern MAC).

[Jey Cee]

@Asgothian sagte in [Aufruf] deConz Adapter Testen 1.1.2:

Das ist zwar erst einmal kein Problem, bedeutet aber entweder das die gesamte Struktur doppelt gespeichert wird (Einmal Organisiert wie in der API, einmal organisiert wie im ioBroker), oder das für jede Nachricht eine Umsetzung durch die Daten durchgeführt werden muss, was sich auf die Performance auswirkt.

Wenn man das volle Potential der Objekte nutzt ist das kein Problem. Das hab ich auch und so ziemlich alles was die API an Daten hergibt wird auch in den Objekten gespeichert, nur halt nicht sichtbar.

@GiuseppeS sagte in [Aufruf] deConz Adapter Testen 1.1.2:

weiterer Vorteil wäre, dass nach einem Löschen und Neu-Anlernen von Zigbee Geräten die Skripte weiterhin funktionieren (da keine willkürlichen IDs sondern MAC).

Das ist auch mein Hauptgrund für die Änderung.

[Asgothian]

@Jey-Cee sagte in [Aufruf] deConz Adapter Testen 1.1.2:

@GiuseppeS sagte in [Aufruf] deConz Adapter Testen 1.1.2:

weiterer Vorteil wäre, dass nach einem Löschen und Neu-Anlernen von Zigbee Geräten die Skripte weiterhin funktionieren (da keine willkürlichen IDs sondern MAC).

Das ist auch mein Hauptgrund für die Änderung.

Problematisch sehe ich hier das durch die Anpassung alle Scripte/Visualisierungen/etc. die aktuell in Benutzung sind umgeschrieben werden müssen. Das war schon bei der Letzten grossen Änderung so und hat durchaus einiges an Verwirrung / Aufwand erzeugt. Allerdings konnte ich da vieles einfach im Quelltext ändern, da sich die Namen (zumindest bei mir) nicht systematisch geändert haben - aus dem alten Namen konnte ich immer direkt auf den neuen Namen schliessen und musste die Objekte nicht von Hand aus dem Baum heraus suchen.
Ich kann mir gut vorstellen das es noch Installationen mit der alten Version gibt, damit genau diese Umstellung nicht gemacht werden muss. Bei einer Umstellung auf MAC ist das dann noch mehr Aufwand.

A.

[siggi85]

Die Migration auf MAC würde auch bei mir Aufwand erzeugen, aber ich wäre definitiv dafür! :)

[GiuseppeS]

@Jey-Cee sagte in [Aufruf] deConz Adapter Testen 1.1.2:

Wenn man das volle Potential der Objekte nutzt ist das kein Problem. Das hab ich auch und so ziemlich alles was die API an Daten hergibt wird auch in den Objekten gespeichert, nur halt nicht sichtbar.

Das ist eine sehr gute Idee, die API ID könnte dann z.B. unter obj.native stehen, richtig? Oder können weitere zusätzliche Bereiche in der State-Object Struktur erstellt werden?
Habe gerade im alten Zigbee Adapter geschaut, da wird die MAC auch zusätzlich unter native.id gespeichert. Also kein unüblicher Weg.

Bzgl. MAC vs ID: Auf Facebook gab es auch schon mehrere Diskussionen. Wobei manche User vom Conbee abgeraten hatten, weil eben die Objekt-Struktur nicht so übersichtlich ist wie beim CC2531.

Ich selbst bin auch noch nicht komplett auf den conbee umgezogen, aber ich merke mit meinen wenigen Tests schon jetzt große Vorteile:

• die Signalstärke meiner Osram Plugs nimmt mit zunehmender Distanz nicht so stark ab wie früher, daher jetzt viel besser als Repeater geeignet.
• Aqara Sensoren anlernen (zumindest seit dem letzten FW Update) geht nun rasend schnell.

Ich bleibe definitiv beim conbee. Bleibt für mich nur noch die Frage, wann ganz grob mit dem Adapter Update von Jey Cee gerechnet werden darf :blush:

[K_o_bold]

Ich lese mich gerade in das Thema ein und mache den Umstieg vom CC2531 auf Conbee 2 ein Stück weit davon abhängig, wie sich der Vorschlag von GiuseppeS und Jey-Cee entwickelt.
Und ich bin mir ziemlich sicher, dass die meisten Anwender den einmaligen Aufwand in kauf nehmen, da es anschließend die genannten Vorteile gibt .