Clock Plugin in 0.12.0-dev

[blaubaerli]

Hallo Chris,

es gibt erste Erfolge.

Allerdings kann ich auf meinen iOS-Devices die Zeiten derzeit nicht in den Pop-Ups ändern, sondern nur wenn src_popup="" ist.

Bin ich im Text-Editor unterwegs, kann ich mir meine Konfig auch sauber bauen. Öffne ich die danach aber einmal mit dem XML-Editor und speichere die dann ab, wird das XML-File ungültig. Der XML-Editor setzt derzeit offensichtlich einen Zeilenumbruch hinter die GA. Das sieht dann im Editor hinterher bei mir so aus:

31-12-_2020_15-56-39.jpg

Rücke ich das dann wieder gerade, ist alles OK.

Beste Grüße
Jens

[Chris M.]

Gut möglich dass es da noch einen Bug gibt. Keiner der Hauptentwickler nutzt iOS privat, d.h. damt ist die Test-Tiefe nicht sonderlich hoch...

[blaubaerli]

Hi @Chris M.,

ich habe mich heute mal wieder ein wenig ausgetobt und meine ganzen Schaltpunkte in der CV nun mal direkt auf den DPT10.001 gesetzt und die ganze Persistierung der Zeiten auch auf die GAs mit dem DPT10.001 umgesetzt.

Aktuell habe ich nun in der "CV-Version: 0.12.0-dev|1cc7cefd913b526569c511d5afead98876de47da" auf einer Seite 20 von den Clock-Elementen.

Jetzt werden mir aber keine Inhalte mehr gelesen bzw. dargestellt. Drehe ich an den Zeigern, wird am Ende zwar ein Telegram auf den Bus gesendet und die neue Zeigerstellung bleibt stehen. Mache ich einen Seitenreload, stehen die Zeiger wieder auf 00:00.

Im Log des Containers finde ich dann folgendes:

Code: Alles auswählen

[Sat Jan 02 23:01:33.590053 2021] [php7:notice] [pid 25] [client 172.17.0.1:57276] PHP Notice:  Only variables should be passed by reference in /var/www/html/rest/manager/src/FileHandler.php on line 182, referer: https://timberwolf168.local/proxy/visutest/?config=Schaltpunkte
[Sat Jan 02 23:09:11.711577 2021] [cgi:warn] [pid 63] [client 172.17.0.1:60312] AH01220: Timeout waiting for output from CGI script /usr/lib/cgi-bin/r, referer: https://timberwolf168.local/proxy/visutest/?config=Schaltpunkte
[Sat Jan 02 23:09:11.711751 2021] [cgi:error] [pid 63] [client 172.17.0.1:60312] Script timed out before returning headers: r, referer: https://timberwolf168.local/proxy/visutest/?config=Schaltpunkte
[Sat Jan 02 23:10:16.444036 2021] [cgi:warn] [pid 98] [client 172.17.0.1:33356] AH01220: Timeout waiting for output from CGI script /usr/lib/cgi-bin/r, referer: https://timberwolf168.local/proxy/visutest/?config=Schaltpunkte
[Sat Jan 02 23:10:16.444236 2021] [cgi:error] [pid 98] [client 172.17.0.1:33356] Script timed out before returning headers: r, referer: https://timberwolf168.local/proxy/visutest/?config=Schaltpunkte

Hast du evtl. dazu ne schlaue Idee?

Sind das einfach zu viele auf einer Seite? Ich habe das noch nicht reduziert.....

Beste Grüße
Jens

[blaubaerli]

Hallo Chris,

in meinem bisherigen Test hatte ich nur clock-Elemente mit jeweils einem "address"-Eintrag und die hatten alle den mode "readwrite".

Jetzt habe ich beim ersten Element mal den Adress-Eintrag dupliziert, dem ersten Eintrag dann den mode "read" und dem zweiten Eintrag den mode "write" bei identischer Adresse verpasst und jetzt klappt es.

Aber bei allen 20 Elemente, obwohl ich nur das erste Element angepasst habe.

Verstehen kann ich das nicht.. ist aber im Moment mal das Testergebnis.

Beste Grüße
Jens

[blaubaerli]

Hi zusammen,

neues vom Test.

Das die Infos aus dem letzten Post nicht auf Dauer belastbar bleiben würden war fast abzusehen. Das scheint in der Tat ein Clock-Element spezifisches Problem zu sein. Parallel auf der Seite vorhandene Infotrigger-Elemente verhalten sich problemlos. Die Clock-Elemente waren jedoch wieder alle auf 00:00.

Habe jetzt mal mit "&forceReload=true&enableCache=invalid" geladen und plötzlich waren die Werte wieder da.

Also schlicht noch nicht stabil im Verhalten.

Beste Grüße
Jens

[Chris M.]

Die CometVisu hat klar trennbare Schichten:
- Es gibt das "Backend", das ist der Web-Server und die CGI-Programme ("r" und "w", auch als eibread-cgi und eibwrite-cgi bekannt)
- Es gibt den "Client", das ist eine kleine JavaScript Bibliothek im Browser, die die Kommunikation zum Backend übernimmt
- Es gibt die Visu an sich, das ist das was Du siehst (und in der gibt's dann noch optionale Bestandteile wie die Plugins)

Das beschriebene Thema scheint irgendwo im Bereich Backend (oder ggf. noch Client) zu liegen. Daher kann das Clock-Plugin damit nichts zu tun haben.
Auch ist eine Änderung von "readwrite" nach "read"+"write" auf die gleiche GA egal, da das zwischen Visu und Client keinen Unterschied im Datenfluss macht.

Zu den Meldungen selbst: hast Du da eine Test-Config, die keine "normalen" GAs enthält, die immer wieder von dem KNX beschrieben werden?
Denn wenn es keine neuen Nachrichten vom Bus für die Visu gibt, dann gibt es im Backend und im Client Time-Outs die dann die Verbindung wieder neu aufbauen. Ich müsste mal testen welche Nachrichten da kommen, das könnten aber genau diese sein. Dann wäre das absolut unkritisch.

[blaubaerli]

Hallo Chris,

die Config die ich aktuell hier teste, ist eine minimalistische, die ausschließlich Schaltpunkte beinhaltet. Also diverse Zeiten (10.001) und diverse LUX-Werte (9.004). Die werden auf dem Bus nicht wirklich aktiv von irgendwem ausser der CV beschrieben.

Das Konzept sieht aktuell so aus, dass ich für jede dieser dort hinterlegten GA's ein entsprechendes führendes Objekt im Wolf habe, bei dem das Lese-Flag auch bewusst gesetzt ist.

Zudem ist eine Instanz von Roberts Persistenzlogik am Start die mir die Werte persistiert.

Zu guter letzt habe ich mir auch noch ein Plugin für den Wiregate-Container geschrieben. Das gute Stück horcht auf die GA's und speichert bei einem eingehenden Write-Telegramm den entsprechenden Wert zusätzlich im "plugin_info"-Hash. Lese-Telegramme ignoriert das Plugin.

Über eine Trigger-GA kann ich dann aber aus dem Wiregate-Container alle dort persistierten Inhalte auf den Bus senden lassen. Das ist also quasi mein Rettungsanker falls da mal verloren geht oder ich die Persistenzlogik editieren muss und mir dann dort die Werte verloren gehen.

Über "https://timberwolf168.local/proxy/visut ... haltpunkte" hatte ich die zuvor im Post beschriebenen Schmerzen, die aber nicht immer sauber reproduzierbar waren. Die Werte der 10.001-GAs waren eben ab und an nicht da. Die der 9.004-Werte wurde jedoch ausnahmslos sauber und korrekt dargestellt.

Mit "https://timberwolf168.local/proxy/visut ... he=invalid" habe ich das System bisher noch nicht zur unvollständigen Auslieferung der Seite bringen können. Da sind immer alle Werte sofort sauber sichtbar.

Beste Grüße

Jens

[Chris M.]

Sporadische Themen sind immer doof.

Die hier angesprochenen Themen hängen aber nicht wirklich zusammen (außer dem groben Zeitpunkt) und sind teilweise auch nicht wirklich schlimm (Time-Out).
Ich würde daher im ersten Schritt ein Cache-Thema vermuten. Wenn es trotzdem wieder auftauchen sollte, müssen wir dann nochmal weiter sehen.

[blaubaerli]

Hi @Chris5020,

ich habe noch ne fhem-Installation bei mir laufen, mit der ich ein paar gammelige Intertechno-Devices mit dem KNX gekoppelt habe.

Bisher haben ich von der fhem-Kiste mit dem eibd des wiregate Kontakt zum Bus aufgenommen.

Nachdem die Tage des Wiregate ja nun gezählt sein sollen.... musste ich mir gedanken machen, wie ich von der fhem-Kiste nun einen Tunnel des Wolfes direkt angesprochen bekomme.

Dazu habe ich auf dem fhem-Rechner den knxd 0.14.35:fc9ba78 gebaut und damit mal probiert.....

Hat zwar was gedauert, aber nun habe ich die Parameterliste mit der die Verbindung dann zum Wolf bei mir sauber aufgebaut wird...

/usr/bin/knxd -e 1.1.230 -E 1.1.231:5 ipt:timberwolf168.fritz.box:3700 -u -c

Der braucht -E zwingend.

Ihr hattet ja in der Visu probiert und das lief da ja noch nicht. Eventuell hilft es euch ja..

Beste Grüße
Jens