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

[klassisch]

Noch eine Frage: Gibt es eine Möglichkeit, den kompletten Parametervektor auf einmal zur Leuchte zu übertragen? Ich habe den Eindruck, daß das serielle Schreiben nicht immer übernommen wird, oder daß man rel. lange Pausen zwischen den Paramtern einbauen muß.

[Asgothian]

@klassisch sagte in ZigBee neue Version 1.4.4:

Ich habe noch nicht den richtigen Umgang mit dem Pinprozess bzw. dessen zyklischen Aufrufen gefunden.

Der Ping Prozess ist explizit nicht für einen zyklischen Aufruf gemacht. Das liegt daran das die Tests gezeigt haben das ein häufiges Nutzen des Pings sich negativ auf das Netzwerk auswirken kann. Insbesondere wenn Geräte nicht oder nur sporadisch antworten kann eine einzelne Abfrage auch mal 60 oder 90 sekunden dauern. Aus diesem Grund ist im Code eine Absicherung eingebaut die eine zu häufige Benutzung blockiert.

Das erkennen des aktuellen Standes und wiederherstellen sollte auf Basis der im ioBroker hinterlegten States erfolgen und keine Anfrage am Gerät über den aktuellen Status benötigen.

@klassisch sagte in ZigBee neue Version 1.4.4:

Statt eines harten Auschaltens nach einem BWM Event oder einem timeout schicke ich die Floalt auf eine langsame ramp down.
Vor der Rampe speichere ich mir die Werte ab.
Am Ende der Rampe stehen hier andere Werte, die ich nicht eigeschrieben habe.
Kann es sein, daß die Werte zyklisch geupdatet werden und damit die Istwerte währnd der ramp down Zeit gefangen werden?
Könnte man dieses zyklische Abfragen abschaltbar machen?

Da musst du schon mehr Details heraus geben. => code ?

A.

[Asgothian]

@klassisch sagte in ZigBee neue Version 1.4.4:

Noch eine Frage: Gibt es eine Möglichkeit, den kompletten Parametervektor auf einmal zur Leuchte zu übertragen? Ich habe den Eindruck, daß das serielle Schreiben nicht immer übernommen wird, oder daß man rel. lange Pausen zwischen den Paramtern einbauen muß.

Das kann insbesondere dann passieren wenn deine Geräte die gesendeten Nachrichten nicht bestätigen, da der Koordinator 10 sekunden auf eine Antwort wartet bevor er eine neue Nachricht zum gleichen Gerät schickt. Bei Geräten die dieses Verhalten nicht zeigen habe ich tests gemacht. Bei guter Verbindung sind pausen von 50 bis 100 ms ausreichend um beliebig viele 'Requests' an ein Gerät zu senden. Da die wenigsten "Parametervektoren" bei Leuchten mehr als 3 Datenpunkte haben (Helligkeit, Farbe (oder Farbtemperatur), on/off Status) sollte auch ein senden ohne Verzögerung problemlos sein.

Ein Senden von allen Parametern auf einmal geht aktuell nicht - selbst wenn wir alle auf einmal an die Zigbee Bibliothek übergeben werden sie nach Zigbee-Standard in einzelne Telegramme zerlegt.

A.

[klassisch]

@asgothian Vielen Dank für die Info. Schade, daß die Telegramme zerlegt werden.
In meinem speziellen Fall kommt manchmal noch die tranfertime dazu, die dann auch zuerst gesendet werden muß.
Bei mir haben sich delayy im Bereich 0.1 bis 0.5 Sekunden bewährt.
Eine abschließende Aussage möchte ich noch nicht treffem. Das Netz ist noch im Ausbau, ich spiele noch zu viel rum, noch einige Komponenten im Zulauf.
Da könnte sich auch noch einiges verschieben.
Ich experimentiere auch noch mit der richtigen Anbindung der Karte. Über ser2Lan zum guten Funkstandort konnte ich irgendwann neue Panels nur anlernen, wenn ich die anderen ausgeschaltet habe. Direkt am ioBroker Rechner geht das Anlernen zuverlässiger, aber da ist der Funkstandort schlechter.
Ich habe auch schon kleine Einbauschalter geordert, damit ich die Panels im eingebauten Zustand und mit der geänderten Verdrahtung auch mal einzeln vom Netz nehmen kann, ohne gleich einen ganzen Sicherungszweig abzuschalten.
Besonders auch, wenn man noch eine Direktverbindung zu Fernbedienungen für Notfallzwecke mit einbaut, gibt es seltsame Dinge. So haben sich auch mal zwei Panels statt des eigentlich intendierten angelernt - quer durchs Haus.

[klassisch]

@asgothian sagte in ZigBee neue Version 1.4.4:

Der Ping Prozess ist explizit nicht für einen zyklischen Aufruf gemacht. Das liegt daran das die Tests gezeigt haben das ein häufiges Nutzen des Pings sich negativ auf das Netzwerk auswirken kann. Insbesondere wenn Geräte nicht oder nur sporadisch antworten kann eine einzelne Abfrage auch mal 60 oder 90 sekunden dauern. Aus diesem Grund ist im Code eine Absicherung eingebaut die eine zu häufige Benutzung blockiert.

dank für die Info. Bedeutet das auch, daß der Abdapter selbst das auch nicht tut?

Das erkennen des aktuellen Standes und wiederherstellen sollte auf Basis der im ioBroker hinterlegten States erfolgen und keine Anfrage am Gerät über den aktuellen Status benötigen.

Ja, so weit das möglich ist, mache ich das auch.
Ich verwende aber auch Synfonisk Drehsteller, die ich per Binding an die entsprechenden Floalt angebunden habe. Damit ist die Bedienung präziser und starffer als es mir per JScript gelungen ist. Leider differieren dann aber die internen states von den wahren. Deshalb muß ich nach einem erkannten Drehstop die akuelle Helligkeit explitzit abholen. Wenn der Nutzer dann kurz danach wieder dreht, dann wird die Abfrage blockiert. Mal sehen, wie ich das umschiffe.

Da musst du schon mehr Details heraus geben. => code ?

Da hast Du vollkommen recht. Und der Beispiel Code stand heute früh auch schon im Code. Dann habe ich noch einige debugs zugefügt, damit man die Sache auch verstehen kann und in diesem Prozeß beschlossen, das Konzept zu ändern und mehr die Skriptvariablen zu nutzen und nicht das Panel als Memory zu mißbrauchen.
Wenn der Adapter jetzt tatsächlich keine eigenen pings auslöst, dann werde ich suchen, warum dennoch Im Verlauf der Rampe andere Werte in die objects kommen. Das kann dann ja nur durch mein Script selbst verursacht sein.

[Asgothian]

@klassisch sagte in ZigBee neue Version 1.4.4:

In meinem speziellen Fall kommt manchmal noch die tranfertime dazu, die dann auch zuerst gesendet werden muß.

Die Transition_time wird nie alleine an die Lampe gesendet. Diese wird im Adapter gehalten und bei jeder Anpassung der Helligkeit / des State mit an das Gerät geschickt.

A.

[klassisch]

@asgothian Vielen Dank, wieder was gelernt. Das heißt, ich kann die auch schon (weit) vorher setzen bzw. benötige keine oder nur eine kurze delay nach dem Setzen?

[Asgothian]

@klassisch Ja

[Wieger Daniel]

@wieger-daniel so nun läufts mal im grunde wieder, leider verlieren manche schalter trotzdem die verbindung, obwohl in der stable keine Probleme waren :(

[klassisch]

Hatte heute Nacht auch etliche Verbindungsverluste zur COM-Schnittstelle, an der die Adapterplatine hängt.
Begann wohl gestern Nacht

zigbee.0	2021-02-20 21:34:16.038	info	(10148) Coordinator firmware version: {"type":"zStack30x","meta":{"transportrev":2,"product":2,"majorrel":2,"minorrel":7,"maintrel":2,"revision":20200211}}
zigbee.0	2021-02-20 21:34:14.443	info	(10148) Installed Version: iobroker.zigbee@1.4.4
zigbee.0	2021-02-20 21:34:14.440	info	(10148) Starting Zigbee npm ...
zigbee.0	2021-02-20 21:34:14.439	info	(10148) Try to reconnect. 4 attempts left
zigbee.0	2021-02-20 21:34:04.430	info	(10148) Installed Version: iobroker.zigbee@1.4.4
zigbee.0	2021-02-20 21:34:04.429	error	(10148) Error: Error while opening serialport 'Error: Opening COM4: File not found' at Znp.<anonymous> (C:\Program Files\iobroker\ioBrMain026\node_modules\zigbee-herdsman\dist\adapter\z-stack\znp\
zigbee.0	2021-02-20 21:34:04.429	error	(10148) Failed to start Zigbee
zigbee.0	2021-02-20 21:34:04.424	info	(10148) Starting Zigbee npm ...
zigbee.0	2021-02-20 21:34:04.423	info	(10148) Try to reconnect. 5 attempts left
zigbee.0	2021-02-20 21:33:54.412	error	(10148) Adapter disconnected, stopping

heute Morgen hat dann der reconnect anscheinend nicht mehr funktioniert

zigbee.0	2021-02-21 04:12:08.384	warn	(10148) Failed to ping 0xbc33acfffed57c9d FLOALT panel WS 60x60
zigbee.0	2021-02-21 04:08:03.824	warn	(10148) Failed to ping 0xbc33acfffed7b833 FLOALT panel WS 60x60
zigbee.0	2021-02-21 04:04:22.008	info	(10148) Installed Version: iobroker.zigbee@1.4.4
zigbee.0	2021-02-21 04:04:22.007	error	(10148) Error: Error while opening serialport 'Error: Opening COM4: Access denied' at Znp.<anonymous> (C:\Program Files\iobroker\ioBrMain026\node_modules\zigbee-herdsman\dist\adapter\z-stack\znp\z
zigbee.0	2021-02-21 04:04:22.007	error	(10148) Failed to start Zigbee
zigbee.0	2021-02-21 04:04:21.997	info	(10148) Starting Zigbee npm ...
zigbee.0	2021-02-21 04:04:21.996	info	(10148) Try to reconnect. 0 attempts left

Heute morgen haben die Leuchten dann auch nicht mehr reagiert. Alles dunkel.
Bin in die Adaptereinstellungen, den bisherigen COM Port nochmals aktiv ausgewählt, gespeichert und der Adapter wurde wieder grün, alle Leuchten reagieren wieder.
Was kann ich zur Ursachensuche beitragen?
Der Adapter hängt derzeit zusammen mit einem MX885 Drucker und einem Brother Labeldrucker an einem Hub.
Der Gerätemanager zeigt für diesen Com-Port weder Fehler noch Warnung und hat auch kein Ereignis gemeldet, seit ich am 18.2. von ser2net auf diese direkte Verbindung umgezogen bin.

[Yodameister]

Ich habe auch Probleme nach Update auf 1.44
Ich habe 63 Geräte am Start , Board CC1352P , die meisten Geräte Xiaomi Aqara , Miijja

Nach dem Update gingen 4 ( ! ) Geräte in der Verbindung auf false. Alles Geräte die vorher ohne Probleme verbunden waren , die ich mehrfach besitze ( Bewegungsmelder , Öffnungssensor ) .

Ich habe versucht die Batterien zu entfernen , warten , Gerät löschen , neu anlernen. Das Geräte wird korrekt erkannt , geht aber sofort auf Verbindung false.

Nach vielen Versuchen habe ich den Adapter downgegradet auf Version 1.20 ....siehe da alles wieder Tutti

Hat da jemand eine Idee ?

[Asgothian]

@yodameister sagte in ZigBee neue Version 1.4.4:

Hat da jemand eine Idee ?

Erst einmal zwei Fragen:

• bist du wirklich zurück auf 1.2.0 gegangen ?
• wo siehst du das die Verbindung auf false geht ?

Hintergrund: bei batteriebetriebenen Geräten wird der „available“ state abhängig davon wann das Gerät das letzte mal gesehen wurde gesetzt. Der State kann also direkt nach einem Update nicht auf false gehen.
Das auf der Kachel die Verbindung rot dargestellt wird liegt daran das nicht klar ist ob das Gerät verbunden ist. Das ändert sich erst wenn das Gerät eine Nachricht sendet. Ich gehe aktuell davon aus das du ein Gespenst jagst. Die entscheidende Frage ist: bekommst du von den Geräten Nachrichten wenn du sie triggers ?

A.

[Asgothian]

@klassisch
Hier ist davon auszugehen das die emulation des seriellen Ports auf dem Board selber ein Problem hat.

Welche Firmware hast du auf dem Board ?

A.

[arteck]

@asgothian sagte in ZigBee neue Version 1.4.4:

Welche Firmware hast du auf dem Board ?

ne daran wird es nicht leigen da ist die 20200211..aber hier mach ich mir sorgen es ist ein Linux system

Error: Error while opening serialport 'Error: Opening COM4: Access denied'

@klassisch hast du js-controller update gemacht ??

@Yodameister lese bitte nochmal den Eingangsbeitrag ich habe da ein Nachtrag verfasst

[Yodameister]

@asgothian
Moin ,
bist du wirklich zurück auf 1.2.0 gegangen ? > Ja , IOBROKER hat mir nur 1.41 und 1.20 angeboten

wo siehst du das die Verbindung auf false geht ? > Unter Objekte / Zigbee /

[Yodameister]

@arteck

@klassisch hast du js-controller update gemacht ?? >>> Ja , sozusagen alles zusammen , erst JS Update dann Zigbee auf 1.44

Wenn ich gewusst hätte das ein JS Update so viel Probleme mit sich bring im Stable , dann hätte ich das wohl erstmal gelassen

Siehst du hier den Fehler ?

[Yodameister]

@arteck
@Nachtrag da es hier zu vielen Fragen kommt
die batteriebenen Geräte .. diese müssen sich erst melden. das dauert da sich diese selten Melden vor allem Aqara bzw. Xiaomi .. man kann es selbst antrigern per drücken des Knopfes am Gerät. erst dann sieht man die richtige Link Quality..

Ich hatte 1 Tag dazwischen und zb der Bewegungsmelder wurde bewusst mehrfach angesteuert , hätte sich also melden müssen , passierte trotzdem nichts , das mit der LinkQualität von 10 war mir aufgefallen , ging aber schnell weg

[klassisch]

@arteck sagte in ZigBee neue Version 1.4.4:

@asgothian sagte in ZigBee neue Version 1.4.4:

Welche Firmware hast du auf dem Board ?

Der Controller-Tag sagt

type:zStack30x
version:2-2.2.7.2.
revision:20200211
port:COM4
channel:11

ne daran wird es nicht leigen da ist die 20200211..aber hier mach ich mir sorgen es ist ein Linux system

 Error: Error while opening serialport 'Error: Opening COM4: Access denied'

Mein ioBroker laptop hat Win 10 Pro drauf. Win 10 kommt mit USBs problemlos klar. Oder besser gesagt, ICH komme bei Win 10 mit USB problemlos klar. Bei den Linux SBC habe ich damit mmer einen K(r)ampf.
Auf dem Rechner läuft noch eine virtuelle COM-SW, die einen Link zu einem TCP-Server hält, mit dem ich RF-Link angebunden habe. Das läuft stabil.
Der smartmeter-Adapter geht auch via Ethernt und TCP-Server.
Versuche prinzipiell von den USB Verbindungen wegzukommen.
Hatte den Zigbee-Adapter auch über ser2net eingebunden. Aber ab dem dritten Panel gab es Probleme mit dem Anlernen. Muß keine Kausalität sein, könnte auch eine Koinzidenz sein. Jdenfalls bin ich dann probehalber wieder zurück direkt auf den USB des Win PC was auch augenscheinlich sofort eine Verbesserung gebracht hat.

@klassisch hast du js-controller update gemacht ??

Bin da noch zurückhaltend bis von berufener Seite geklärt ist, wie das mit den Win 10 Installer Varianten geht. Mein System läuft derzeit recht gut und so soll es auch bleiben. Habe zu wenig Ahnung von npm, node.js etc um da Pionier sein zu wollen.

 node.js   v10.17.0
NPM     6.11.3

    Typ: js-controller
    Titel: JS controller
    OS: win32
    Verfügbar: 3.2.16
    Installiert: 3.1.6
    Ereignisse: ↦27 / ↦12

[Peter213]

Hallo,
ich habe seit eben wie aus dem nichts folgende Fehler: Meine ganzen Danfoss Ally Thermostatköpfe koppeln sich nicht mehr.
Hat einer eine Idee was ich machen kann?
Version ist 1.4.4

[Ein ehemaliger Benutzer]

@arteck @Asgothian

Dankeschön an euch Entwickler dieses tollen Adapters!!

Bin jetzt mit 140 Devices umgestiegen von 9 Xiaomi Gateways auf einen CC26X2R, hat auf Anhieb alles super geklappt.