[Aufruf] ZigBee CC253x Adapter Version 0.10.x
-
@Findus
Für diesen Zweck hat der Adapter eine "Queue" eingebaut, über die die Befehle an die Hardware abgesetzt werden können.Und nur der Vollständigkeit halber - du kannst fast jede Hardware dadurch umlegen das du ihre Kommunikatonskanäle mit zu vielen / zu schnellen Requests bombardierst.
-
@Wildbill sagte in [Aufruf] ZigBee CC253x Adapter Version 0.10.x:
Hat jemand mit einem Raspbee oder Conee (Deconcz) evtl. Erfahrung, wie sich da Tradfri-Leuchten bei Stromausfall verhalten. Kommt dann ein Status true im Adapter an, wenn die Leuchte nach Stromausfall leuchtet, worauf man reagieren kann? Läuft das ganze stabiler als mit einem CC2531/CC2530?
Ich kann bestätigen das der deconz erkennt das die Lampe an ist, wenn sie nach einem Stromausfall wieder Strom bekommt und dann an ist. Auch scheint das System bei mir stabil - ich hatte bisher keine Ausfälle, hatte aber auch bisher keine Stromausfälle.
Warum das beim Zigbee-stick nicht der Fall ist werde ich mir auf jeden Fall anschauen.
A.
-
@Asgothian: Sehe ich ein - eine Queue sollte dies aber genau verhindern. Wenn du in Bluefox hue adapter code rein schaust lässt er genau 10 Commands in 10 sec zu. (dies ist natürlich Hue adapter spezifisch)
Ich habe eine Fernbedienung und wenn man damit die Farbe ändern will drückt man ja dann mehrmals schnell auf die Farbknöpfe soll heißen es kommen auch mal 3 - 4 Farbbefehle / Sekunde rein die ich an die Lampe weiterreiche und dies kann ich ja nicht verhindern. Und genau hier müsste die Queue greifen -> tut sie aber nicht -> es kommen timeout Fehler die das System lahm legen.
Ich kann natürlich meine eigenen Queue programmieren - aber das ist ja überflüssig da ja schon eine da ist. Ich denke halt sie funktioniert nicht richtig.
-
habe ein Backup von heute 3:00 eingespielt, jetzt geht wieder alles!
-
@Findus Hier kann ich nur sagen das die Queue des Zigbee-Adapters durchaus greift. Über den Hue-Adapter kann und will ich nichts sagen.
A.
-
@Asgothian sagte in [Aufruf] ZigBee CC253x Adapter Version 0.10.x:
Ich kann bestätigen das der deconz erkennt das die Lampe an ist, wenn sie nach einem Stromausfall wieder Strom bekommt und dann an ist. Auch scheint das System bei mir stabil - ich hatte bisher keine Ausfälle, hatte aber auch bisher keine Stromausfälle.
Danke, vielleicht steige ich ja doch nochmal darauf um. Kurz noch OT: Hast Du damit zufällig auch Ikea Bewegungsmelder gepairt und kannst mri noch kurz sagen, ob die Datenpunkte erzeugen?
Gruss, Jürgen
-
@Wildbill sagte in [Aufruf] ZigBee CC253x Adapter Version 0.10.x:
Hast Du damit zufällig auch Ikea Bewegungsmelder gepairt und kannst mri noch kurz sagen, ob die Datenpunkte erzeugen?
Leider nicht. Ich nutze die Xiaomi Bewegungsmelder. Sind kleiner. Ich gehe aber davon aus das sie es tun.
A.
-
@Asgothian: Wenn die Queue greifen würde, bekäme ich aber diese Timeouts nicht. Wenn ich die Frequenz auf 1 Event / sec reduziere kommt ja auch kein Timeout. Probier dies doch mal bei dir aus.
Ich wollte ja nur sicherstellen, dass andere User das gleiche Problem haben. -
kann es sein das doch nur 15 Aktoren angelernt werden können, ich kann keinen mehr anlernen, obwohl ich eine Philips Hue im Verbund habe!
Bei den Xiaomi macht sich das durch dauerblinken bemerkbar, wenn ich mich nicht täusche, im Pairinglog kommt kein Meldung auch keine FM
-
nein.. ich hab 30 am laufen
-
sorry doppelpost
-
ich bekomme nichts mehr angelernt, egal was ich auch mache! Auch die Philips Hue war ein Desaster angelernt zu bekommen, keine Reaktion, hab sie die ganze Nacht brennen lassen und siehe da in der Früh war sie eingebunden, ohne das sie vorher in der Zigbee DB war!
Habe jetzt die Version Zigbee Adapter 10.2 --> mein Stick ist 20190223 und habe von @Asgothian den Zusatz per Katze "https://github.com/asgothian/ioBroker.zigbee/tarball/Admin_Changes" installiert
ich versteh es nicht, völlig unlogisch!
-
Auch wenn es vielleicht den einen oder anderen nervt, habe ich nochmals ein paar Tests bezüglich der Queue gemacht.
Bei eingeschalteter Queue verschluckt sich das System schon bei ca. 1 Event pro Sekunde und kommt außer Tritt. (Timeouts). Danach wird es Übel. Die Queue speichert die Events und versucht sie auch abzuarbeiten. Da jedoch Timeouts kommen und die Queue vermutlich das Processing per Job nicht abbricht kommt Alles in stocken.
Bei ausgeschalteter Queue funktioniert 1 Event / Sekunde noch gut und es wird erst kritisch bei mehr als 2 Events / Sekunde.
Meiner Ansicht nach funktioniert die Queue nicht richtig. Sie muss sicher stellen, dass Jobs die länger brauchen als eine Vorgabe z.B. 200 ms abgebrochen werden und auch sollte die max Queue Länge begrenzt werden.
Ziel sollte es doch sein, dass das System nicht außer Tritt gerät. -
@Findus Ziel ist die abarbeitung der Queue..das Problem ist nach deiner Beschreibung, dass bei "einem Problem" die Queue weiter die Befehle mit einem OK abarbeiten will ...
das ist aber nur der Fall wenn das Gerät einen Fehler meldet.. (ACK error oder was auch immer)
bei einem sauberen Netzwerk funktioniert es.... bei mir zumindest.. -
@arteck: Hast du dies mit meinem Script oder ähnlichem selber ausprobiert? Ich habe alle Komponenten im selben Raum - Netzwerk sollte also gut funktionieren.
-
ja hab ich .. ich habe 4 Hue Lampen .. die geschaltet werden bei Taster druck.. mit an -> farbenwechsel -> helligkeit
alles hintereinander...bei allen 4 ..per Script -
in der shepherd.db ist der Switch noch drinnen, obwohl ich ihn entfernt habe aus den Geräten, kann es daran liegen , das er sich deswegen nicht anlernen lässt?
kann ich die Zeile einfach selbst aus der shepherd.db löschen ?
-
lösch die ganze Zeile mal..
aber ich meine nicht..
-
habe die Zeile gelöscht und die zigbee.0 Instanz neu gestartet --> jetzt reagiert der Xiaomi Switch völlig anders, was sein blinkverhalten betrifft und auch im Pairinglog kommt nun eine Meldung, wenn auch keine Positive, aber immerhin:
weißt du was damit gemeint ist ?
-
hatte ich öffters auch...
probiermal mit
stopmal den adapter zieh den stick kurz raus und dann starte den adapter wieder
