RASP3B, Jessie, KNXD (0.12.3) und CometVisu 0.9.2

[Smurf]

Hmm. Fehlen die auch wenn du sie komplett neu startest?

[itarch]

Die CometVisu neu starten bedeutet Apache2 neu starten. Es bringt nichts.

Hatte heute mal mit knxtool abfragen gestartet:

pi@RASP3BI: ~ $ sudo knxtool groupcacheread ip:localhost 5/1/24
Write from 1.0.10: 00
pi@RASP3BI: ~ $ sudo knxtool groupcacheread ip:localhost 5/1/22
Response from 1.0.10: 01

Der Status der GA 5/1/24 ist 0/AUS. Das zeigt die Visu auch an. Das liegt aber auch daran, dass dieser Kanal mehrmals abends ein/ausgeschaltet wird.

5/1/22 ist ein Kanal der in der Regel immer an ist, was ja auch die Abfrage bestätigt. Die CV hat diesen Status verloren. Wenn ich ein groupread auf diese GA absetze dann taucht er wieder in der CV auf.

Ich muss ergänzen, dass im Haus ca 14 Gira TS installiert sind und kontinuierlich Temperatur-Werte im Bus melden. Hinzu kommt die Wetterstation mit der Temperatur, Wind und LUX Meldungen, sowie die kontinuierliche Message "ich lebe" damit die Jalousieaktoren nicht die Stores hochfahren.
Hier kommen also jede Menge Telegramme und erwecken bei mir den Verdacht, nach und nach den Cache zu versauen. Was aber auch nicht sein kann da die Beispiele oben zeigen, dass der Cache stimmt.

Hmm

[Smurf]

Der Groupcache hatte einen 16bit-Zähler für die neuesten Nachrichten. Der läuft über, d.h. die Visu bekommt Adressen nicht mehr mit, wenn seit der letzten Nachricht an diese mehr als 2^16 Pakete über den Bus gerauscht sind.

Ich habe den Zähler im stable-Zweig auf 32bit aufgebohrt. Die Visu muss das eibread-cgi aus v0.12 verwenden, wenn sie beim Refresh alles mitbekommen will.

[Smurf]

NB:

sudo knxtool groupcacheread ip:localhost 5/1/22

Ich bitte von der inflationären Verwendung von "sudo" abzusehen.

[ctr]

Hast Du das mal mit dem eibread-cgi / eibwrite-cgi gegen eine CometVisu getestet, dass das noch läuft?

Ich bin immernoch auf dem eibd, so wie er mit dem WireGate mit kommt. D.h. neuere Versionen habe ich nie zu Gesicht bekommen...

Ich habe es mal getestet und es verhält sich dann genau wie man es sich denkt:
- nach einem knxd Neustart (und damit leerem groupcache) zeigt die CV viele "-"
- sobald Werte eintrudeln befüllt es sich dann nach und nach
Das ist technisch sicher sauberer als beim ersten Start alle besagten 65535 GA's durchzugehen, da ein knxd restart aber von der CV entkoppelt ist, führt es zu Effekten die sich für einen Visu-betrachtenden-Enduser nicht unbedingt erschließen.
Wäre es nicht besser anstatt 0 oder 65535 GAs abzufragen, genau die GAs zu fragen, die die CV auch braucht? Das wird doch sowieso als Parameter an eibread-cgi übergeben oder?

[Smurf]

Es ist der Job der Visu, die Werte die sie braucht aktiv auszulesen. eibread-cgi holt die Daten vom Bus, wenn der Cache nichts hergibt. Ich bin ja schon mehr als nett, wenn ich im knxd *alles* zwischenspeichere statt nur wie früher die letzten 255 Nachrichten.

Das eibread-CGI hat zwei Modi, (a) gib mir sämtliche Änderungen seit XXX, (b) gib mir den Cache für Adresse A,B,C,… (und evtl.: lese die Daten dafür vom Bus wenn nötig). Wenn die Visu beim Start XXX=0 setzt und darauf hofft, dass der eibread-cgi den Bus mit 65535 Lesebefehlen zuballert und ihr alle Antworten schickt, die es so gibt, dann hat das beim eibd noch funktioniert … der hatte dafür eine Sonderbehandlung eingebaut … aber jetzt nicht mehr. Derlei Unfug ist in exakt gar keiner KNX-Installation sinnvoll.

Zum Ausgleich liefert XXX=0 jetzt alles was so im Cache ist (und auf normalen Rechnern limitiert niemand den Cache, das dafür maximal nötige MByte RAM ist langweilig), aber dafür braucht es ein ausreichend neues eibread-cgi.

[itarch]

Offensichtlich ist das Verhalten der CometVisu 0.10.0 anders.

Bis zur Problemschilderung (in #15) hatte ich mehrere Tage knxd und Apache nicht neu gestartet. In der Kombination KNXD 0.12.8 und CV 0.9.2 gingen nach und nach die Statie ("-") verloren. Das war heute nicht anders.

Parallel zur CV 0.9.2 habe ich auch die 0.10.0 im Einsatz. Problem hier: wenn ich mit Chrome auf die 0.10.0 zugreife bleibt der Browser auf "Loading ..." (siehe Link) hängen.

Attention: ich habe heute auf die CV 0.10.0 vom Edge Browser (Windows 10) zugegriffen und sehe alle Statie

Zusammenfassung:

a) RPI3, JESSIE, Apache 2.4, KNXD 0.12.8, CV 0.9.2
==> alle Browser (Windows & Smartphone) bauen die Seite auf, allerdings gehen nach und nach die Statie verloren.

b) Parallel zu der obigen Konfig (a) läuft auch die CV 0.10.0 auf dem System
==> aktuell baut nur der IE und der Edge die Seite auf. Dafür sind aber die Statie da !!!

[Chris M.]

Ich bin ja schon mehr als nett, wenn ich im knxd *alles* zwischenspeichere statt nur wie früher die letzten 255 Nachrichten.

Die 16 Bit müssten aber 65536 oder zumindest 32768 sein und nicht nur 255.

Es ist der Job der Visu, die Werte die sie braucht aktiv auszulesen.
[...]
Das eibread-CGI hat zwei Modi, (a) gib mir sämtliche Änderungen seit XXX, (b) gib mir den Cache für Adresse A,B,C,… (und evtl.: lese die Daten dafür vom Bus wenn nötig). Wenn die Visu beim Start XXX=0 setzt und darauf hofft, dass der eibread-cgi den Bus mit 65535 Lesebefehlen zuballert und ihr alle Antworten schickt, die es so gibt, dann hat das beim eibd noch funktioniert … der hatte dafür eine Sonderbehandlung eingebaut … aber jetzt nicht mehr. Derlei Unfug ist in exakt gar keiner KNX-Installation sinnvoll.

Zum Ausgleich liefert XXX=0 jetzt alles was so im Cache ist (und auf normalen Rechnern limitiert niemand den Cache, das dafür maximal nötige MByte RAM ist langweilig), aber dafür braucht es ein ausreichend neues eibread-cgi.

Mit dem t=0 sagt die CometVisu: gib mir von den angefragten(!) GAs alles was im Cache ist, so wie den aktuellen Index vom Cache UND frage die fehlenden GAs per Lese-Telegram ab. (Bei einem t=<Nummer> würden außerdem die GAs, deren Alter im Cache älter als <Nummer> ist, auch abgefragt werden).
=> Die CometVisu liest hiermit aktiv genau die Werte aus, die sie braucht.

Mir ist auch neu, dass der eibd dies anders gemacht hätte. Schließlich haben auch in der Vergangenheit 65536 Lesetelegramme überhaupt keinen Sinn gemacht.

Wenn der knxd sich hier nun anders verhält, dann befürchte ich, dass er damit die Schnittstelle nicht mehr korrekt bedient.

Als Referenz dafür: https://github.com/CometVisu/CometVi...oll#Lesen_read

Parallel zur CV 0.9.2 habe ich auch die 0.10.0 im Einsatz. Problem hier: wenn ich mit Chrome auf die 0.10.0 zugreife bleibt der Browser auf "Loading ..." (siehe Link) hängen.

Hier hat peuter ja schon einen Fix gefunden und den Pull-Request gestellt.

[Smurf]

Die 16 Bit müssten aber 65536 oder zumindest 32768 sein und nicht nur 255.

Jein. Der Speicher war 256 Nachrichten lang. Wenn der Unterschied zwischen dem alten Index und der aktuellen Position >255 war, wurde halt alles gesendet.

Mit dem t=0 sagt die CometVisu: gib mir von den angefragten(!) GAs alles was im Cache ist, so wie den aktuellen Index vom Cache UND frage die fehlenden GAs per Lese-Telegram ab.

Korrekt, das macht er aktuell nicht, mein Fehler. Teste bitte die Version v0.12.12.

[itarch]

Mit der Version 0.12.12 stimmt was nicht:

pi@RASP3BI:~ $ /usr/bin/knxd -V
knxd 0.12.12

Ich sende
pi@RASP3BI:~ $ knxtool groupwrite ip:localhost 4/2/4 1

und sehe im Gruppenmonitor in der "Info" Spalte

$01 | 0%

statt

$01 | Ein

Darüberhinaus und möglicherweise damit zusammenhängend werden in der CV (0.10.0) weder Werte angezeigt noch Steuerung (Licht/Jalousien) ausgeführt.

[Smurf]

Seltsam, zumal sich am relevanten Code wenig bis nix geändert hat. Ich werde heute abend testen.

[Tru]

Ich sende
pi@RASP3BI:~ $ knxtool groupwrite ip:localhost 4/2/4 1

Und wie sieht es damit aus: knxtool groupswrite ip:localhost 4/2/4 1

[itarch]

Tru
Version 0.12.12 knxtool groupswrite ip:localhost 4/2/4 1 => geht
Version 0.12.13 knxtool groupswrite ip:localhost 4/2/4 1 => geht

mit groupwrite kommen 0% auf dem BUS an (statt Ein)

Darüber hinaus stecke ich hier in Kombination (0.12.12 oder 0.12.13) mit CometVisu 0.10.0-* fest. Es werden keine Statie angezeigt.

[Smurf]

"groupwrite" ist für >=8-bit-Werte vorgesehen. Einzelne Bits packt man in kurze Pakete, deshalb groupswrite (s=short). Bei 255=100% ist eine 1 darstellungstechnisch immer noch 0% (falls es sich um eine Prozentangabe handelt, was aus dem Datenpaket an sich aber nciht ersichtlich ist).

Manche Endgeräte verstehen auch groupwrite-ohne-s, wenn man was schaltet, aber dann musst du 100% (255) verwenden.

[itarch]

thanx