CometVisu maximale Anzahl GAs?

[peuter]

Also bei mir hat das nichts gebracht :-( Die URL mit r? ist immer noch immens lang und die Zeit nicht kürzer geworden.

Wieviele Adressen hast Du denn auf der Startseite, funktioniert das denn grundsätzlich das da zuerst ein Request mit weniger Adressen geschickt wird?

ich glaube du hast versehentlich (d)eine config/visu_config_main.xml mit committed?

Danke für den Hinweis, ist irgendwie mit reingerutscht.

[peuter]

Hab da nochmal eine kleine Änderung eingecheckt:
Bisher war es so dass nachdem die Adressen der Startseite abgefragt wurden im zweiten Request alle Adressen abgefragt wurden (also die von der Startseite nochmal). Das habe ich jetzt geändert, obs der Performance zuträglich ist weiß ich nicht. Da kann ich mit meinen 144 Adressen (18 auf der Startseite) einfach keine aussagekräftigen Tests machen.

Vielleicht kannst Du das mal testen. Wenns nichts bringt würde ich das wohl wieder rausnehmen, denn theoretisch wäre es möglich das die Visu so Änderungen der Startseite verpasst, wenn diese genau zwischen der Verarbeitung der ersten beiden Requests passiert.

[Chris M.]

Grundsätzlich: das Thema mit vielen GAs ist bisher noch nicht optimiert worden, da es einfach niemanden aufgefallen ist bzw. gar gestört hat.
Aber das können wir ja jetzt gerne mal angehen (nur die 0.8.5 erreicht das nicht mehr)

[eibread-cgi]
- es sollte m.E. standardmäßig dieses Limit hochgesetzt werden!

Grundsätzlich sehe ich das auch so.
Für's WireGate selbst hab ich gerade eine Diskussion diesbezüglich am laufen (nicht hier).
Für den Code selbst kann jeder gerne inzwischen im Git einen Patch einstellen

Weiteres Experimentieren lässt mich folgendes vermuten: die Grenze von 1024 gilt offenbar für die Gesamtzahl aller address-Tags. Obwohl nur 675 unterschiedliche GAs vorkommen, davon auch noch 117 mit mode="write", d.h. eigentlich nur etwas mehr als 500 GAs einzulesen sind, wird bei 1086 address-Tags NICHTS mehr angezeigt.

Wohlgemerkt: fünf Trigger-Buttons zur gleichen GA enthalten fünfmal den gleichen address-Tag, alle mit mode=write. Sollte eigentlich überhaupt keinen Effekt auf Ladezeiten usw haben...

Wenn ich mich noch richtig an den Code erinnere (am Wochenende kann ich auch wieder reinsehen):
Das write-only GAs mit gelesen werden kann sein (hat bisher nicht gestört, ist aber natürlich Müll).
Ansonsten sollten aber nur eindeutige GAs geladen werden, d.h. im "r"-Request keine doppelten GAs vorkommen.
=> Kannst Du mal im Debug-Modus des Browsers in dem Netzwerk-Reiter nach den HTTP-Anfragen mit der URL .../r?... suchen und mir den Anfrage-String schicken?

Das ist mir auch schon aufgefallen. Mit steigender Komplexität der Visu steigt auch die Wartezeit bis Daten angezeigt werden. Bei mir momentan auch ca 10-15sec. Wäre es möglich (als neues Feature) die *unique* GAs einzeln abzufragen und den Wert anzuzeigen? Und dann auch noch die der aktuellen Seite zuerst?

Wie viele GAs hast Du etwa in der Config?

10-15 Sec darf nicht sein (was ja nicht heißt, dass es aktuell nicht so kein könnte...)

Ich schau mir am Wochenende auf jeden Fall mal das Verhalten bei vielen GAs genauer an. Mal schaun was da geht

Noch ein Effekt ist mir subjektiv als wichtig aufgefallen: die address-Tags von trigger-Widgets sollten unbedingt auf mode=write gesetzt werden.

Wieso?
(Nicht das anders Sinn machen würde...)

Auch timeouts bei GA-Requests sind möglichst zu vermeiden. Hilft der Visu auch nicht.

Welche Timeouts meinst Du?
Die CV nutzt nur Timeouts im Sinne von Keep-Alive.

Übrigens bin ich (zwei linke Hände bei HTML usw) immer noch nicht drauf gekommen, wie ich im Firefox (mit Web Developer Addon) mir anzeigen lassen kann, welche GAs überhaupt angefragt werden.

Die reale Anfrage an sich: s.o.
Wie diese Anfrage zusammen gebaut wird steht im Source bzw. Script Reiter.
templateengine.js ist da quasi der Haupt-Code, der cometvisu-client.js als Lib zum Kommunizieren nutzt.

Wenn ja, wäre es meines Erachtens angeraten, das als Standard-Verhalten zu verwenden. Ich würde sogar soweit gehen, dass man gar kein anderes Verhalten zulässt, weil es keinen Sinn macht.

Wie oben geschrieben, ist das Viele-GA-Verhalten bisher nicht sonderlich optimiert. Gut möglich das wir dann auf genau so eine Lösung setzen.

Ich halte insgesamt wenig von der Verwendung dieser URL-Parameter. Das kann man meines Erachtens keinem normalen User zumuten, da irgendwelche kryptischen Parameter an seinen Visu-Aufruf dran zu klimpern. Es sollten alle Parameter, wenn es irgendwie geht, in die Config wandern. Wie seht ihr das?

Da muss man trennen.
Es gibt Einstellungen die schon vor der Config bzw. unabhängig von der Config einstellbar sein sollten.
Z.B. eine StartPage - die dazu gedacht ist Visu-PC individuell die Startseite festzulegen. (Also die Visu im Flur sollte immer die Flur-Seite zeigen, aber eben auch alle anderen Seiten anbieten. Und die Wohnzimmer-Visu eben die Wohnzimmer-Seite).
Oder das forceReload.
Oder gar die Info welche Config-Datei überhaupt genutzt werden soll.

Alles was sich auf eine Config selbst bezieht gehört aber in die Config. Wie z.B. das zu verwendende Backend.

Wir können gerne nochmal die URL-Parameter durchgehen und hier ggf. umsortieren.

Und um das den Anwendern einfacher zu machen, könnten wir durchaus den neuen Config-Manger (ab 0.8.5) entsprechend erweitern.

[mivola]

Wieviele Adressen hast Du denn auf der Startseite, funktioniert das denn grundsätzlich das da zuerst ein Request mit weniger Adressen geschickt wird?

Ich habe ca 20 Adressen auf der Startseite. Einen kurzen Request mit weniger Adressen konnte ich nicht finden.

=> Kannst Du mal im Debug-Modus des Browsers in dem Netzwerk-Reiter nach den HTTP-Anfragen mit der URL .../r?... suchen und mir den Anfrage-String schicken?

Wie viele GAs hast Du etwa in der Config?

Also ich habe ca 500 address-Tags in der Config (gefühlt ca 60-70% mit eindeutigen GAs).
Hier mal ein Beispiel-Request:

http://wiregate/cgi-bin/r?s=SESSION&a=7/6/32&a=7/6/33&a=7/6/30&a=7/6/31&a=4/6/34&a=7/6/33&a=7/6/34&a=4/6/41&a=4/6/40&a=9/6/32&a=9/4/40&a=9/4/41&a=7/4/62&a=7/4/63&a=7/4/60&a=7/4/61&a=4/4/120&a=7/4/122&a=7/4/121&a=9/7/186&a=9/7/187&a=7/5/20&a=7/5/23&a=7/5/21&a=7/5/22&a=7/5/24&a=7/7/32&a=7/7/37&a=7/5/90&a=7/5/93&a=7/5/91&a=7/5/92&a=7/5/94&a=7/6/32&a=7/6/37&a=7/5/80&a=7/5/83&a=7/5/81&a=7/5/82&a=7/5/84&a=7/7/38&a=7/6/38&a=7/7/150&a=7/7/151&a=9/7/152&a=9/7/153&a=7/7/152&a=7/7/157&a=7/5/61&a=7/5/62&a=7/5/64&a=7/5/51&a=7/5/52&a=7/5/54&a=10/7/150&a=7/7/180&a=7/7/181&a=7/7/60&a=7/7/61&a=7/7/90&a=7/7/91&a=7/7/120&a=7/7/121&a=7/6/60&a=7/6/0&a=7/6/90&a=7/6/91&a=7/6/120&a=7/6/121&a=7/6/180&a=7/7/0&a=8/0/10&a=8/0/11&a=8/0/12&a=8/0/13&a=8/0/20&a=4/7/31&a=4/7/126&a=4/7/151&a=4/7/155&a=4/7/156&a=4/7/153&a=4/7/154&a=4/7/181&a=4/7/183&a=4/6/157&a=4/6/30&a=4/6/60&a=4/6/210&a=4/4/122&a=4/6/32&a=4/6/62&a=4/6/212&a=9/7/158&a=9/7/159&a=9/7/150&a=9/7/151&a=9/7/154&a=9/7/155&a=9/7/156&a=9/7/157&a=11/7/0&a=11/7/1&a=11/7/3&a=11/7/8&a=11/7/11&a=11/7/12&a=11/7/6&a=11/7/4&a=10/7/125&a=10/7/121&a=10/7/122&a=10/7/124&a=10/7/145&a=10/7/141&a=10/7/142&a=10/7/143&a=4/7/150&a=9/7/92&a=9/7/93&a=9/7/96&a=9/7/97&a=9/7/90&a=9/7/91&a=10/7/105&a=10/7/101&a=10/7/102&a=10/7/107&a=10/7/104&a=10/7/85&a=10/7/81&a=10/7/82&a=10/7/87&a=10/7/83&a=4/7/120&a=4/7/125&a=4/7/124&a=4/7/122&a=4/7/123&a=11/7/16&a=11/7/17&a=11/7/18&a=11/7/19&a=13/7/1&a=11/7/12&a=7/0/4&a=11/5/2&a=11/5/22&a=13/5/1&a=13/7/4&a=13/7/7&a=13/7/6&a=7/5/30&a=7/5/33&a=7/5/31&a=7/5/32&a=7/5/34&a=7/5/40&a=7/5/43&a=7/5/41&a=7/5/42&a=7/5/44&a=7/7/212&a=7/7/213&a=9/7/210&a=9/7/211&a=10/7/185&a=10/7/181&a=10/7/182&a=10/7/187&a=10/7/184&a=4/7/210&a=4/7/211&a=4/7/214&a=4/7/215&a=4/7/212&a=4/7/213&a=7/5/100&a=7/5/103&a=7/5/101&a=7/5/102&a=7/5/104&a=7/6/152&a=7/6/157&a=9/6/150&a=9/6/151&a=9/6/152&a=9/6/153&a=7/6/158&a=10/6/155&a=10/6/151&a=10/6/152&a=10/6/157&a=10/6/154&a=4/6/150&a=4/6/151&a=4/6/154&a=4/6/155&a=4/6/152&a=4/6/153&a=4/7/60&a=7/7/182&a=4/6/60&a=4/6/90&a=4/6/120&a=4/6/180&a=4/4/125&a=4/4/126&a=4/4/127&a=8/5/55&a=8/5/51&a=8/5/54&a=8/5/53&a=9/7/0&a=9/7/1&a=9/7/2&a=9/7/3&a=9/7/60&a=9/7/61&a=10/7/45&a=10/7/41&a=10/7/42&a=10/7/44&a=10/7/65&a=10/7/61&a=10/7/62&a=10/7/64&a=10/7/62&a=9/7/63&a=9/7/64&a=9/7/65&a=9/7/66&a=9/7/67&a=12/7/13&a=9/7/62&a=9/7/94&a=9/7/95&a=9/6/60&a=9/6/61&a=9/6/90&a=9/6/91&a=9/6/10&a=9/6/11&a=9/6/120&a=9/6/121&a=9/6/180&a=9/6/181&a=9/6/182&a=9/6/183&a=9/6/186&a=9/6/187&a=9/6/188&a=9/6/189&a=9/7/182&a=9/7/183&a=9/6/210&a=9/6/211&a=9/4/60&a=9/4/61&a=9/6/30&a=9/6/31&a=9/0/3&a=9/7/30&a=9/7/31&a=9/6/30&a=9/4/62&a=8/5/60&a=9/4/1&a=4/4/124&a=8/5/52&a=8/5/0&a=8/5/1&a=8/5/4&a=8/5/3&a=8/5/2&a=8/5/5&a=8/5/8&a=8/5/17&a=8/5/18&a=8/5/21&a=8/5/20&a=8/5/19&a=8/5/22&a=8/5/25&a=8/5/34&a=8/5/35&a=8/5/38&a=8/5/37&a=8/5/39&a=8/5/42&a=10/7/84&a=10/7/127&a=10/6/185&a=10/6/181&a=10/6/182&a=10/6/187&a=10/6/184&a=10/6/65&a=10/6/61&a=10/6/62&a=10/6/67&a=10/6/64&a=10/7/7&a=10/7/1&a=10/7/2&a=10/6/7&a=10/6/1&a=10/6/2&a=9/6/0&a=9/6/1&a=9/6/100&a=9/6/100&a=9/6/200&a=9/6/200&a=9/6/201&a=9/6/1&a=9/6/120&a=9/6/120&a=9/6/122&a=9/6/122&a=9/6/121&a=9/6/121&a=9/6/11&a=9/6/11&a=9/6/84&a=9/6/111&a=9/6/22&a=9/6/26&a=9/6/61&a=9/6/68&a=9/6/66&a=9/6/69&a=9/6/67&a=9/6/70&a=9/6/10&a=9/6/82&a=9/6/42&a=9/6/41&a=9/6/43&a=9/6/20&a=9/6/150&a=9/6/63&a=9/6/64&a=9/6/62&a=9/6/52&a=9/6/241&a=9/6/242&a=9/6/243&a=9/6/244&a=9/6/245&a=9/6/246&a=9/6/250&a=9/6/251&a=9/6/0&a=4/4/101&a=9/6/5&a=9/6/1&a=9/6/2&a=9/6/3&a=9/6/10&a=9/6/11&a=9/6/13&a=9/6/20&a=9/6/21&a=9/6/23&a=9/6/30&a=9/6/31&a=9/6/33&a=9/6/40&a=9/6/41&a=9/6/43&a=9/6/50&a=9/6/51&a=9/6/53&a=9/6/60&a=9/6/61&a=9/6/63&a=9/6/70&a=9/6/71&a=9/6/73&a=9/6/4&a=9/6/12&a=9/6/14&a=9/6/22&a=9/6/24&a=9/6/32&a=9/6/34&a=9/6/42&a=9/6/44&a=9/6/52&a=9/6/54&a=9/6/62&a=9/6/64&a=9/6/72&a=9/6/74&t=0

[peuter]

Ich habe ca 20 Adressen auf der Startseite. Einen kurzen Request mit weniger Adressen konnte ich nicht finden.

Dann hat das update irgendwie nicht geklappt (ich habe auch mal wieder vergessen die cache version zu ändern), kann also sein, dass bei Dir trotz update der alte Javascript Code aus dem Cache geladen wurden.

Bitte mach nochmal ein SVN update und lade Deine Visu zur Not mit den ?forceReload=true Parameter. Solange es am Anfang keine 2 Requests mit &t=0 am Ende gibt funktioniert das Vorladen der Startseiten-Adressen nicht und somit kann sich auch an der Performance nichts ändern.

PS: Kann da auf den ersten Blick keine doppelten Adressen sehen in Deinem request (hätte mich auch nach dem gestrigen Blick in den Code auch stark gewundert)

[Chris M.]

So, in Revision 2335 ist nun ein Filter eingebaut, dass nur noch die GAs gelesen werden bei denen auch ein read (oder natürlich auch readwrite) gesetzt ist.

=> Bitte mal testen ob es a) was in der konkreten Situation bringt und b) keine Regression erzeugt.

Ansonsten befürchte ich, dass die Langsamkeit bei vielen GAs mit dem aktuellen Backend zu tun hat. Ich hätte mir da den Code nicht ansehen dürfen
Gibt es hier einen freiwilligen der das optimiert? (Ich bin eigentlich mit GrAF schon mehr als beschäftigt... Und sehe in GrAF die Zukunft und nicht im eibread-cgi. Aber ich befürchte das zum einen GrAF noch braucht um es auf Anwender los zu lassen und eibread-cgi dringend eine Überarbeitung braucht...)

[ctr]

Das steht auf meiner To-Do Liste aber ich schwanke derzeit noch zwischen einer vollständigen Reimplementierung und der Benutzung von node.js mit node-eibd. Für ersteres fehlt es mir vermutlich in Summe an Zeit...

[Chris M.]

Und was wir wohl machen müssten, wäre von GET auf POST umzustellen. Denn das Thema der maximalen URL Länge ist sehr verworren (geht von 2k über 4k und 8k bis zu "unbegrenzt")

Aber wenn ich das aktuell machen würde, dürfte es ein Rückschritt sein, denn den eibreag-cgi Code lese ich so, dass der dann ein hartes Limit bei 4k hätte...

Bei aktuellen Tests mit vielen GAs (unt t=0, falls das einen Einfluss hat) hat der eibread-cgi in seltsammes Verhalten: manchmal kommt eine leere Antwort zurück (also nur die beiden Titel-Zeilen, kein JSON) und dann wieder eine normale Antwort.
Alles aber relativ schnell, d.h. das sollte da eigentlich kein Performance-Problem sein...

[Chris M.]

2. Beim Laden fragt die Visu die GAs offenbar mit einem einzigen Read-Request ab. Dadurch dauert es "ewig", bis überhaupt was angezeigt wird, selbst wenn die konkrete Page, die man aufgerufen hat, nur wenig Daten enthält. Wie kann man das heilen (am besten wäre es, die Visu würde gar nicht immer geladen sondern im Browser-Cache verbleiben, auch zwischen Sessions und über Stunden hinweg)?

Aktuell stellt sich die Situation mir wie folgt dar:

• eibread-cgi ist eigentlich ziemlich schnell - auch mit vielen GAs (natürlich nur in die internen Limits passend, mein Test hat kann 800 unique GAs)
  => aktuell glaube ich nicht daran, dass ein vorgeschobener Read mit den GAs der Start-Seite viel bringt
• Der Aufbau des DOM ist bei vielen Widgets ziemlich langsam (im Bereich von 1-2 Sekunden auf meinem i7 im schnellen Chrome) - vermutlich weil so oft Parse HTML aufgerufen wird

Spontan würde mir dazu als Lösung einfallen die Widgets komplett in einen String zu bauen und erst ganz am Schluss in den DOM einzuhängen. Aktuell geht das nicht, da $(widget).data() intensiv genutzt wird um jedem Widget lokale Daten zu ermöglichen.
Hier könnten wir evtl. auf ein globalen Hash wechseln und Widget individuelle id-Attribute nutzen (schon jetzt gibt es für jedes Widget eine eindeutige Id...)

Leider ist das ein größerer Eingriff. Seufz. Und die templateengine benötigt auch mal wieder ein gescheites Refactoring. Nochmal seufz.

[stBorchert]

... Und die templateengine benötigt auch mal wieder ein gescheites Refactoring. Nochmal seufz.

Ach da hätte ich auch noch einen kleinen Vorschlag bzgl. der Template-Engine ... Verwendung von Templates für die Ausgabe der Widgets. So kann man sich die HTML-Ausgabe noch ein wenig selbst anpassen (wenn man das möchte).

Hier mal ein Beispiel aus meinem Plugin für openweathermap:

  jOWM.theme = function (func) {
    var args = Array.prototype.slice.apply(arguments, [1]);

    return (jOWM.theme[func] || jOWM.theme.prototype[func]).apply(this, args);
  };

  /**
   * Default theme function for detailed weather item.
   */
  jOWM.theme.prototype.weatherDetailItem = function (data, options) {
    var weather = data.weather[0];
    var temperature = data.main;
    var d = new Date(data.dt * 1000); // We need ms, not s!
    d.locale = options.lang;

    var output = '<div class="weather-detailed weather-' + weather.id + ' clearfix">';
    output += ' <div class="weather">';
    output += '  <span class="weather-icon" data-weather-text="' + weather.description + '" data-weather-code="' + weather.id + '"></span>';
    output += ' </div>';
    output += ' <div class="temperature">' + jOWM.theme('temperature', temperature.temp, 1) + '</div>';
    output += '</div>';
    return output;
  };

Das wird dann im Code einfach über

jOWM.theme('weatherDetailItem', elem, options)

aufgerufen und lässt sich in eigenen js-Dateien überschreiben.
So kann man die Ausgabe von Plugins überschreiben, ohne im originalen Plugin rumfummeln zu müssen.

Nur so als Idee am Rande

[Chris M.]

• Der Aufbau des DOM ist bei vielen Widgets ziemlich langsam (im Bereich von 1-2 Sekunden auf meinem i7 im schnellen Chrome) - vermutlich weil so oft Parse HTML aufgerufen wird

Spontan würde mir dazu als Lösung einfallen [...]

Um Performance-Disukssionen aus diesem Thread heraus zu halten (hier sollte es nur um das Verhalten bei vielen GAs gehen), habe ich dazu einen neuen Thread gestartet: https://knx-user-forum.de/cometvisu/...rformance.html

Ach da hätte ich auch noch einen kleinen Vorschlag bzgl. der Template-Engine ... Verwendung von Templates für die Ausgabe der Widgets. So kann man sich die HTML-Ausgabe noch ein wenig selbst anpassen (wenn man das möchte).

CometVisu-Plugins darfst Du gestalten wie Du willst (bei Widgets sind wir etwas restriktiver). D.h. eine Überladbarkeit per prototype wäre da durchaus möglich.
Wenn ich das so umsetzen kann, wie es mir gerade vorschwebt, müsste in Zukunft ein Widget oder Plugin einfach einen String mit allen HTML-Elementen zurück geben und die Pro-Instanz-Daten liegen in einer getrennten Datenstruktur. Gerade das sollte sich leicht überladen lassen.

Wenn ich die Seufzer von Chris richtig interpretiere, dann braucht es - neben guten Ideen - vor allem Entwickler welche die Sache voranbringen.

Unbedingt!
Und auch Designer/Künstler/Grafiker (gerne auch alles in einem ).
Und sicher auch andere Professionen die mir spontan nicht einfallen aber trotzdem wichtig sind!

Ich sehe folgende Möglichkeiten, die Situation zu ändern:

Variante 1: [...]
Variante 2: Ihr spenden freiwillig (über Support-Stunden in unserem Shop) und ich setze Entwickler zum Selbstkostenpreis daran. Wer jetzt meint, dann gebe ich halt 20.- EUR: unter 100 EUR pro Spende brauchen wir nicht drüber zu reden. Gute Entwickler sind unter 40 bis 70 EUR pro Stunde (Brutto) nicht zu bekommen.

Hier gibt es inzwischen eine weitere interessante Variante dazu: Crowdfunding!
D.h. wenn es ein Feature o.ä. gibt, dass viele interessiert und jeder bisschen Geld spendet, kann so in Summe trotzdem genug zusammen kommen.

Ganz für Umme gibt's das trotzdem nicht: das muss jemand organisieren:

• Thema identifizieren
• Geld sammeln
• Entwickler beauftragen

Variante 3: Es raffen sich freiwillige Entwickler auf welche die Comet Visu voranbringen. Die Backends und die Frontends müssen überarbeitet werden, um die Ansprüche von morgen auch befriedigen zu können. Das wäre die kostengünstigste Variante. Also los, meldet Euch bei Chris.

Gerne!

Ich hät's eigentlich mal in einem anderen Thread schreiben wollen (hier ist's schon etwas OT), aber für ein erstes Stimmungsbild ist's i.o., denke ich:
Wie seht ihr einen Wechsel des Verwaltungssystems? (Hintergrund: ich bin mit SourceForge in der letzten Zeit nicht mehr sonderlich zufrieden; GitHub wäre da natürlich eine offensichtliche Alternative)
- Gute Idee, die dank Git mehr Entwickler anziehen kann?
- Egal?
- Schlechte Idee, SVN funktioniert ja zuverlässig und SF wird die Probleme schon in den Griff bekommen?

[henfri]

Hallo,

ich gehe mal davon aus, dass das Backend Teil des knxd werden wird, denn Makki wollte ja auch, dass es Teil des Eibd wird. Was am Backend geändert werden muss, kann ich nicht beurteilen.


Gruß,
Hendrik

[swiss]

Hallo Hendrik

Das klingt nach guten Nachrichten und da makki bereits mit dem Fork begonnen hat, kann auch er bestimmen was aufgenommen wird und was nicht. Damit wären natürlich viele Probleme von haus aus gelöst was die kompatiblität zu anderen Platformen angeht.

[Chris M.]

Bitter hier nicht mehr zum Thema der Entwicklungsplattform oder einer "Entwicklungsförderung" schreiben, dafür gibt's neue Threads. Dort geht's weiter...

[Chris M.]

So, leider gibt das Form (zumindest mir) keine genaueren Moderations-Rechte um die drei durcheinander laufenden Themen sauber zu separieren.
Ich hab mein bestes probiert - notfalls bitte einfach in den drei relevanten Threads nachlesen:

https://knx-user-forum.de/cometvisu/...nzahl-gas.html
https://knx-user-forum.de/cometvisu/...plattform.html
https://knx-user-forum.de/cometvisu/...oerderung.html