Idee zu Zwischenspeicher gesucht

[willchr]

Hallo zusammen,

ich würde mich freuen, wenn jemanden eine Idee hätte zur Lösung folgenden Problems.

Ich habe Zigbee-Lampen installiert, die über ein Gateway kommunizieren ( ähnlich Hue-Bridge)

Dieses Gateway versendet bei Änderung von Stati (Farbwerten/AnAus/etc) diese geänderten Werte jeder Lampe just-in-Time über ein Websocket an Edomi in ein iKO (Json)
Eine Änderung dieses iKOs löst eine Logik aus, welche aus einer Kette verschiedener LBS besteht, am Ende wird der geänderte Wert in eine KNX-Gruppenadresse geschrieben.

Dieses funktioniert an sich sehr gut, jedoch:

Ändere ich über die HueApp einen Farbwert einer ganzen Lampengruppe (12lampen)und suche ich dann vielleicht noch etwas den richtigen Farbwert, in dem ich verschiedene Farbtöne ausprobiere, dann werden innerhalb weniger Augenblicke unzählige Stati über den Socket gemeldet. Die Folge ist ein Anschwellen der Queue in Größen, wo es oft sehr lange dauert, bis edomi diese queue abgearbeitet hat. In dieser Zeit sind andere Befehle an Edomi natürlich ebenfalls in Wartestellung, was die Familie veranlasst, die Befehle immer und immer wieder zu wiederholen, was nichts besser macht.

Jetzt interessiert mich im Prinzip ja aber eigentlich nur der letzte Status jeder Lampe. Wenn ich nur die letzten Änderungen in die Queue stellen könnte, wäre das Problem gelöst. Meine Idee ist nun eine Art Zwischenpuffer, welcher nur mit jedem letzten Wert einer Kette von Status-Änderungen einer Lampe die o.a. Verarbeitungs-Logik startet. Die letzte Änderung könnte erkannt daran erkannt werden, dass seit einem Zeitraum t keine weiteren Meldungen kamen.

Hat jemand ein ähnliches Problem schonmal gehabt oder hat eine Idee oder einen Ansatz, wie dies zu realisieren ist?

Viele Grüsse
Christian

[givemeone]

Was ist denn das langsame? Das zigbee Gateway, oder die Weitergabe an KNX? Vermutlich ersteres... Das zigbee device gibt sowas nicht her? Manche Gateways die ich kenne bieten eine Reduzierung des Busverkehrs an...

[MrIcemanLE]

Vielleicht mit dem LBS "Entprellen 16000001"

Dieser Baustein entprellt ein Signal an E1.

Jedes Telegramm ≠[leer] an E1 triggert den Baustein. Der Wert an E1 wird unmittelbar an A1 ausgegeben, der Baustein ist anschließend jedoch für die Dauer an E2 gesperrt (währenddessen werden alle Telegramme an E1 ignoriert).

E1: ≠[leer] = Signal. Jedes weitere Telegramm während der Laufzeit wird ignoriert!
E2: Entprellzeit (ms)
A1: Wert von E1

Oder besser noch der LBS "Verzögerung 16000112"

Dieser Baustein verzögert ein neues Telegramm an E1 um den an E2 angegeben Zeitraum (Millisekunden).

Wichtig: Trifft während der Verzögerung eines Telegramms ein weiteres Telegramm an E1 ein, startet der Baustein quasi neu. Das vorherige Telegramm wird verworfen!

E1: jedes Telegramm ≠[leer] triggert den Baustein
E2: Verzögerung in Millisekunden (Änderungen an E2 werden während(!) einer laufenden Verzögerung ignoriert)
A1: nach Ablauf der Verzögerungszeit wird E1 unverändert ausgegeben

[willchr]

Vielen Dank für den Input.

Was ist denn das langsame? Das zigbee Gateway, oder die Weitergabe an KNX?

Das Gateway liefert die geänderten Werte ohne Verzögerung. Edomi kommt beim Verarbeiten nicht hinterher. Vielleicht ist auch einfach die Hardware zu schlapp und ich brauch ne stärkere Maschine. Zunächst versuche ich aber erstmal den Code/Logic zu optimieren.

Manche Gateways die ich kenne bieten eine Reduzierung des Busverkehrs an...

Dieses wäre mir neu, aber ich werde beim Hersteller mal fragen.

Vielleicht mit dem LBS...

Werde mal antesten. Besonders das Neustarten des Verzögerungsbausteines klingt nach einem Ansatz!

Viele Grüße
Christian

[jonofe]

Ich würde versuchen das Problem an der Quelle zu lösen. Welches Gateway ist es denn? Und wie genau werden die Daten vom Gateway an EDOMI gesendet? Remote API? Oder hast du einen eigenen Websocket LBS gebaut?

[willchr]

Welches Gateway ist es denn? Und wie genau werden die Daten vom Gateway an EDOMI gesendet? Remote API? Oder hast du einen eigenen Websocket LBS gebaut?

Es ist das Phoscon-Gateway von Dresden-Elektronics.
Die Daten werden von einem python-script, welches mit dem Socket verbunden ist, per RemoteApi an Edomi übergeben

Ich würde versuchen das Problem an der Quelle zu lösen.

Ich könnte natürlich auch versuchen, die Daten zu filtern noch bevor Edomi ins Spiel kommt. Nur hab ich dann die Logic an 2 verschiedenen Orten verteilt. Grundsätzlich müsste ich auch mit Python (oder jeder anderen Sprache) das gesendete Json erst auseinandernehmen und über Arrays weiterverarbeiten. Das gleiche, was ich dann später in Edomi erneut machen würde.

[willchr]

Oder besser noch der LBS "Verzögerung 16000112"

Aufgrund dieses Tipps habe Ich hab mir den Verzögerungs-Baustein mal angeschaut, dabei die Funktion setState / getState entdeckt und versuche nun genau wie der Verzögerungsbaustein meinen Puffer-LBS über einen Zeitraum t immer wieder neu triggern zu lassen, ohne dass er an Output A1 etwas weitergibt. Stattdessen schreibt er fleissig in ein Array rein, welches dann in Json-Form über setVar in V1 abgespeichert wird, um beim nächsten Triggern zunächst wieder in ein Array umgewandelt und nachfolgend modifiziert zu werden...uns so weiter.

Wenn t vorbei ist (und dann hoffentlich der Datenstrom zum erliegen gekommen ist), müsste er dann in einer Schleife die gemerkten Werte nach und nach an den Output A1 abgegeben, bis der Puffer V1 wieder leer ist.

Das versuche ich jetzt...

[jonofe]

Das mit dem Verzögerer hilft aber nicht die Telegramme in der Edomi Queue zu verringern.
Erfolgversprechender wäre vermutlich das Filtern im Python Skript zu machen oder das, was das Python Skript macht in einen LBS zu gießen und dort das Filtern zu machen.

[givemeone]

Das mit dem Verzögerer hilft aber nicht die Telegramme in der Edomi Queue zu verringern.

Der KNX-Bus ist aber deutlich langsamer als die EDOMI-QUEUE, weshalb das sicherlich schon helfen wird!
Ich bezweifle fast, dass Edomi selbst damit ein Problem hat, egal auf welcher Hardware.
Die EDOMI-Que ist ja standardmäßig auch 10/Sekunde beschränkt, die Edomi-KNX Schnittstelle auf 20/s.
((vermutlich könntest Du auch damit experimentieren, diese Werte zu erhöhen. Edomi als auch KNX schaffen etwas mehr. Das würde ich aber als letzten Ausweg nehmen)).
Sind die Stati _alle_ unterschiedlich? Vielleicht würde auch schon ein simpler "send by change (sbc)"-Baustein helfen.
Die Helligkeit bleibt dabei ja zB meist gleich, wenn sich nur die Farbe ändert..., der Status On/Off ebenfalls.

Joe

[jonofe]

Mein bisheriges Verständnis war, das KNX gar keine große Rolle bei dem Problem spielt, sondern die Verarbeitung der iKO Queue in Edomi. Wie voll wird denn die Queue, d.h. wie viele Telegramme generiert dein Python Skript ungefähr? Es wäre doch sicher recht einfach die Zahl der Edomi Remote API Calls an dieser Stelle zu begrenzen.

[willchr]

Mein bisheriges Verständnis war, das KNX gar keine große Rolle bei dem Problem spielt, sondern die Verarbeitung der iKO Queue in Edomi. Wie voll wird denn die Queue, d.h. wie viele Telegramme generiert dein Python Skript ungefähr? Es wäre doch sicher recht einfach die Zahl der Edomi Remote API Calls an dieser Stelle zu begrenzen.

Ich kann es leider nur bildlich erklären:
Wenn man Edomi startet erscheint das Fenster mit dem runden Kreis, welcher durch einen Klick die Konfigurationsoberfläche öffnet. Alternativ zum Kreis kann ich noch 3 Fenster nach links und 3 nach rechts scrollen. Wenn ich 2x nach links scolle erscheint eine Statistik in 6 Gruppen, in welchen die unterschiedlichen Queues (neben anderen Werten) gezeigt werden. Die obere mittlere Gruppe ist mit Logic tituliert, deren erster Wert nennt sich "queued" -> und genau diesen Wert meine ich.

Dieser Wert hat im Maximum (meine Tochter spielte am Farbrad in der Hue-App, der Websocket mit Rückmeldungen hat geglüht) > 2000 ergeben. Natürlich war das das bisherige Maximum, aber auch eine Queue von 400 dauert ein paar Sekunden, bevor sie abgearbeitet ist. In dieser Zeit lassen sich die ebenfalls über Edomi realisierte Kommunikation "KNX-TASTER"->ZIGBEE-Gateway->Lampe/Gruppe ordentlich zeit mit der Informationsübertragung. Sprich, Lampen gehen nicht an/aus, reagieren stark zeitversetzt.

Das Gateway gibt pro Änderung eines Farbwertes einer Lampe stets 3 getrennte Rückmeldungen (x,y, brightness). Bei einer Gruppe von 12 Lampen sind das 3x12=36 Meldungen. Wischt man über ein Farbrad, werden aber während des WIschens bereits die jeweiligen Farbwerte gemeldet. Da kann es sehr schnell gehen, dass bei Änderung von Rot auf Grün 10 unterschiedliche Farbstati gemeldet werden, somit 360 Websocketmeldungen reinkommen. Wenn man dann doch entscheidet, dass Grün eher Blau sein sollte......

[givemeone]

Und du bekommst alle gruppen einzen gemeldet? Würde es nicht reichen, nur die Werte des "Gruppenmaster" zu übertragen? 360 "Telegramme" nach KNX schieben dauert nach EDOMI Standardregel >18s, der KNX Standard selbst sieht hier mindestens 6s vor. EIn LBS selbst sollte dagegen mit 360 Theoretisch recht gut
Was steht zu dieser Zeit auf dieser Seite in der Rubrik "KNX" unter QUEUE? Ist dieser Wert unauffällig nieder?

Was sagt zu diesem Zeitpunkt ein : "select * from edomiLive.RAMcmdQueue" auf die EDOMI-Datenbank?

[willchr]

Sind die Stati _alle_ unterschiedlich? Vielleicht würde auch schon ein simpler "send by change (sbc)"-Baustein helfen.
Die Helligkeit bleibt dabei ja zB meist gleich, wenn sich nur die Farbe ändert..., der Status On/Off ebenfalls.

Ein SendByChange ändert ja nichts, weil sich immer alle Werte ändern. Nur leider Gottes sind die erstgemeldeten Werte umsonst abgearbeitet wurden, da nur der letzte Farbwert der entscheidende ist und Bestand hat. Diese ersten unnötigen Meldungen zu ignorieren, da muss ich ansetzen.

Deshalb gefällt mir die Idee mit getState / setState . Über 2sekunden alle eingehenden Werte in ein assoziatives Array speichern (wobei neue Meldungen alte Werte einfach üebrschreiben) und wenn keine weiteren Meldungen mehr eingehen, dann via Schleife Wert für Wert in die übrige Logik schicken. Das wären dann genau 36 Werte bei einer 12er Gruppe. Klingt besser als x-hundert.

[willchr]

Und du bekommst alle gruppen einzen gemeldet? Würde es nicht reichen, nur die Werte des "Gruppenmaster" zu übertragen?

Ich schicke ein Änderungsbefehl an eine Gruppe via App und bekomme über den Websocket die Stati aller einzelnen Lampen zurück. Ich weiss nicht, was Du unter Gruppenmaster verstehst. Der Websocket pusht mir ausschliesslich die Farbwerte x,y,bri zum Zeitpunkt der Änderung.

Was steht zu dieser Zeit auf dieser Seite in der Rubrik "KNX" unter QUEUE?

Dieser ist unauffällig. Die Schwachstelle ist dieser Queue unter Logic. Ein Test ohne KNX-Schreibens brachte keine Verbesserung.

Was sagt zu diesem Zeitpunkt ein : "select * from edomiLive.RAMcmdQueue" auf die EDOMI-Datenbank?

muss ich austesten...

[givemeone]

Ok! Ich hätte gewettet, dass KNX langsamer ist als die Logik-QUEUE.
Ich würde vermutlich mit LBS 19001173 hier experimentieren, das macht genau das!
Der Parameter 1|2|1 könnte ein guter Anfangspunkt sein.
Interessieren würde mich auch, wie deine Logik dazu aussieht....

Ich weiss nicht, was Du unter Gruppenmaster verstehst. Der Websocket pusht mir ausschliesslich die Farbwerte x,y,bri zum Zeitpunkt der Änderung.

Wenn Du erkennst, dass die Ergebnisse an die Gruppe geschickt werden, bekommt doch jede Lampe den selben Wert, oder?
Also von den 3x12=36 Meldungen sind nur 3 unterschiedlich, die anderen werden alle wiederholt. Oder wird die Lichszene über samtliche Lampen eigens berechnet?
Dann könnte man hier ebenfalls ansetzen!