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

[v522533]

@matdos1gmx-de

Bei mir ist auch das ganze Log voll mit diesen Meldungen, funktionieren tut aber alles, kann also kein Funkproblem sein. Das liegt am Adapter vermute ich, davor mit dem sheperd hat alles ohne Fehler funktioniert. nach der Umstellung massive fehler und warns im log, aber dennoch geht alles

[Matdos]

Das ist zb ein Xiaomi Tür Fenster Kontakt direkt nach dem Anlernen wenn man auf das i klickt also das funktioniert auf jeden Fall auch, wie halt Asgothian schon erwähnt hat bei den Batterie betriebenen nach längerer Zeit einmal auf die Taste drücken und dann gleich auf das i klicken so lange die wach sind.

@v522533

na die Warn und Fehlermeldungen sind mir wurst die kann ich ohne Probleme ignorieren :joy: , aber mir ist eben aufgefallen das ich mit den Plugs Probleme habe und wenn die auch noch als Router ausfallen dann habe ich eben auch Probleme wie z.b. mit der Lampe weil die dahinter hängt und keine extra Verbindung zum Coordinator hat.

So weit läuft alles gut bis jetzt aber das muss man jetzt erst mal ne Woche beobachten wie sich die xiaomi Geräte verhalten mit Batterie, die haben sich (nicht alle aber ein paar waren sehr auffällig z.B der kleine Taster mit dem runden Knopf) mit dem alten Adapter „abgemeldet“ so das ich se neu anlernen musste. Da bin ich mal gespannt ob das jetzt besser ist.

[LichtAn]

@v522533 said in Zigbee Adapter mit neuem Converter:

@matdos1gmx-de

Bei mir ist auch das ganze Log voll mit diesen Meldungen, funktionieren tut aber alles, kann also kein Funkproblem sein. Das liegt am Adapter vermute ich, davor mit dem sheperd hat alles ohne Fehler funktioniert. nach der Umstellung massive fehler und warns im log, aber dennoch geht alles

Die Meldung hab ich auch. Sowohl mit einem einem CC2531 als auch mit CC2538 Stick. Ich hab allerdings festgestellt dass ich ein massives reichweiten Problem dadurch habe. Im Keller hab ich so Schaltzeiten meiner Osram Plugs von 5 und mehr Sekunden. Mit passenden Timout Fehlermeldungen im Log. Im Adapter 0.11.5 treten diese langen Latenzzeiten nicht auf.

Denke also auch das das am Adapter liegt.

warn: zigbee.0 (16974) Failed to execute routing table for '0x7cb03eaa0a0048ed'. "Error: AREQ - ZDO - mgmtRtgRsp after 10000ms\n at Timeout.object.timer.setTimeout [as _onTimeout] (/opt/iobroker/node_modules/iobroker.zigbee/node_modules/zigbee-herdsman/dist/utils/waitress.js:44:24)\n at ontimeout (timers.js:498:11)\n at tryOnTimeout (timers.js:323:5)\n at Timer.listOnTimeout (timers.js:290:5)"

error: zigbee.0 (16974) Error on send to 0x7cb03eaa0a0048ed command: Error: Timeout - 32534 - 3 - 100 - 6 - 11 after 15000ms

Ich denke die passenden Meldung, wenn es funktioniert, zur warn Meldung sollte diese hier sein. Die bekomme ich unter 0.11.5

info: zigbee.0 (14589) Dev 0x7cb03eaa0a0048ed Plug 01 not configured yet (1), will retry on next incoming message.
und dann
info: zigbee.0 (14589) new dev 0x7cb03eaa0a0048ed 20246 Plug 01

[Xsev]

@Asgothian
@arteck
Ich hab mal eine technische Frage,
wie ist das denn mit dem command Befehl, der bei Hue Geräten gerne verwendet wird für transmitiontime,farbe etc.?
Besteht da die Möglichkeit diesen langfristig ebenfalls über den Adpater ansprechen zu können oder ist dies technisch nicht möglich/umsetzbar und nur der Huebrige vorbehalten?

[arteck]

@Xsev das ist ein künstlich erzeugter Befehl.. der wird nicht direkt durch die Bridge unterstützt sonder immer auseinander genommen und einzeln abgearbeitet

man könte den auch im Adapter einbauen

[Matdos]

@Asgothian @arteck

Was sollte man eigentlich bzw. was habt Ihr hier eingestellt beim Admin?

Habt Ihr Latest oder default zu erst?

[Xsev]

@arteck Das hört sich ja grundsätzlich schon mal gut an. Wenn ihr mal "Luft" habt ;-) wäre das echt noch ein feines feature, gerade die individuellen transition time Möglichkeiten finde ich super, diese lassen sich doch nur über den command Befehl steuern oder kann ich den via script auch jetzt schon individuell mitschicken? Und das Hue Farbwidget setzt meines Wissens nach auch den Command voraus, zumindest hab ich es ohne noch nicht damit hinbekommen.

[arteck]

@matdos1gmx-de die Reihenfolge ist doch egal

[arteck]

@Xsev ich glaube du missverstehst des Befehl...
es kann nur das verarbeten was die einzelnen Datenpunkte auch hergeben... man gibt halt nur anstaat 3 Befehle (mach an, level 60, farbe rot)
nur ein als command.. (an, 60, rot)...

der brightness und state funktionieren ähnlich ist der state auf true wird brightness auf 100 gesetzt
wird birgntess auf 0 gesetzt wird der state auf false ...und umgekehrt

[Xsev]

@arteck Verstehe, danke für die Erklärung, dann kann ich den Wert Transition Time auch einfach mit übergeben und er wird mir je nach Script und einstellung individuell geschalten? Sorry ich frag deshalb so blöd weil ich bislang dachte, der Transmition Wert den wir im Adpter haben wäre eine Globale Einstellung für die Lampe.. Aber jetzt wo ich es schreibe kommt mir das es natürlich quatsch sein muss und ich den Wert vermutlich genauso schalten kann wie jeden anderen auch, dachte wie gesagt das diese Funktion der Hue brige vorbehalten sei und nur über command ginge.

[arteck]

@Xsev zeig mir die Objektliste der Lampe

[Xsev]

@arteck
Da der Wert leer ist hab ich diesem auch nie wirklich beachtung geschenkt.

[arteck]

@Xsev dann schreib da eine 2 rein und drück enter..oder 1.. oder 5 oder oder..ads ist doch die Dimmgeschwindgkeit in sec angabe

[Xsev]

@arteck OK, gerade getestet egal ob 1 5 oder 100 keine Änderung Lampe schaltet normal schnell, laut Objektet ist es ja kein Level oder switch.

[arteck]

@Xsev schau mal bei der LWB010...

[Xsev]

@arteck Leider auch ohne Erfolg bei der LWB010, egal welcher Wert 2-5000 (bei Hue direkt wird der Wert soweit mir bekannt in Msek angegeben).

Was mir noch aufgefallen ist, das ist die Meldung die @LichtAn bekommt, bei mir ebenfall im Log auftreten, sobald ich die Map öffne, das komische ist, es sind nur Osram Geräte betroffen (alle Plugs und eine Osram Birne). Anbei mein Log eintrag. Dieser kommt bei jeder Mapaktualisierung.

zigbee.0	2020-01-07 08:38:54.842	warn	(748) Failed to execute routing table for '0x7cb03eaa0a06f717'. "Error: AREQ - ZDO - mgmtRtgRsp after 10000ms\n at Timeout.object.timer.setTimeout [as _onTimeout] (/opt/iobroker/node_modules/iobrok
zigbee.0	2020-01-07 08:38:44.589	warn	(748) Failed to execute routing table for '0x7cb03eaa00b0a8e1'. "Error: AREQ - ZDO - mgmtRtgRsp after 10000ms\n at Timeout.object.timer.setTimeout [as _onTimeout] (/opt/iobroker/node_modules/iobrok
zigbee.0	2020-01-07 08:38:34.584	warn	(748) Failed to execute LQI for '0x7cb03eaa00b0a8e1'. "Error: AREQ - ZDO - mgmtLqiRsp after 10000ms\n at Timeout.object.timer.setTimeout [as _onTimeout] (/opt/iobroker/node_modules/iobroker.zigbee/
zigbee.0	2020-01-07 08:38:23.631	warn	(748) Failed to execute routing table for '0x7cb03eaa0a06d9b0'. "Error: AREQ - ZDO - mgmtRtgRsp after 10000ms\n at Timeout.object.timer.setTimeout [as _onTimeout] (/opt/iobroker/node_modules/iobrok
zigbee.0	2020-01-07 08:38:13.467	warn	(748) Failed to execute routing table for '0x7cb03eaa00afa4c3'. "Error: AREQ - ZDO - mgmtRtgRsp after 10000ms\n at Timeout.object.timer.setTimeout [as _onTimeout] (/opt/iobroker/node_modules/iobrok
zigbee.0	2020-01-07 08:38:02.652	warn	(748) Failed to execute routing table for '0x7cb03eaa00b0dfe8'. "Error: AREQ - ZDO - mgmtRtgRsp after 10000ms\n at Timeout.object.timer.setTimeout [as _onTimeout] (/opt/iobroker/node_modules/iobrok

[v522533]

@Xsev

bei mir auch, genau das gleiche.

[Matdos]

@arteck

Ja aber wenn ich auf dem testbroker die zwei vertausche das latest oben steht bekomme ich zb gleich ein Update beim Host was mir bei meinem richtigen Iobroker dann noch nicht angezeigt wird wenn ich default als erstes stehen habe somit habe ich zwei unterschiedliche Aktualisierungen bzw bin bei default nicht immer up to date.

[Asgothian]

@matdos1gmx-de
Die Frage welche Reihenfolge besser ist hängt vom Einsatzfall / Zweck ab.

Default vor Latest priorisiert die Adapter die als "stable" bezeichnet werden.
Latest vor Default priorisiert die neueren Versionen der Adapter (die zu NPM gespiegelt wurden), auch wenn sie noch nicht im Stable Zweig aufgenommen sind.

Ich würde immer Default vor Latest setzen und bei den Adaptern wo ich neue Features benötige von Hand die Latest Versionen installieren. Ansonsten gilt: nur dann ein update fahren wenn es notwendig ist, nicht "nur weil eine neuere Version verfügbar ist"

A.

[Niko0816]

Habe auf 1.0.0-c umgestellt.

Leider immernoch die gleichen Fehlermeldungen und keinerlei Darstellungen im Geräte- und Netzwerkkartentab.