CometVisu ohne KNXD/EIBD?

[MGK]

Moin,

da alle aktuellen KNXD wohl nicht mehr mit der CV kompatibel sind (siehe hier) , gibt es einen Weg die CV ohne KNXD zu benutzten?

Gruss,
Michael

[larsrosen]

Mit Openhab2 sollte es gehen.
Die einfachere Variante wäre allerding die geforkte KNXD 0.1.0 zu nehmen die läuft bei mir wie ein Uhrwerk.

[Chris M.]

Mit dem knxd hab ich auch nur Probleme gehabt, eine ältere Version hatte auf einem Bastel-Test-System funktioniert. Da ich aber produktiv und bei der CometVisu-Entwicklung die eibd-Version des WireGates nutze, hatte ich mich nur halbherzig darum gekümmert. Und da es seitens knxd kein Interesse gab das Thema wirklich zu lösen habe ich es erst mal darauf beruhen lassen.

Grundsätzlich gibt es in produktiver Nutzung aktuell als Backend den eibd (und knxd in funktionierenden Versionen...) so wie OpenHAB.
Weitere sind leicht denkbar, teilweise angedacht, aber stand jetzt eben nicht produktiv nutzbar.

[MGK]

also 3 Wege:
- OpenHAB2 nutzen - will ich eigentlich nicht.
- das kaputte eibread-cgi im aktuellen KNXd fixen - das wäre wohl der beste Weg, ich habe aber mal die source angeschaut und verstehe das nicht wirklich - ich hoffe die KNXD Leute gucken sich das an.
- das kaputte eibread-cgi durch was eigenes ersetzen. Bisschen JSON auf einen CGI Call zurückliefen sollte ich hinbekommen...

dazu mal ne Frage an:
Chris M.

Die CometVisu macht nen Request mit den Parametern

?t=60&s=SESSION&a=1/2/3&a=3/4/5

und erwartet einen response im Format

{"d": {"1/2/3":"00","3/4/5":"27"},"i":51313}

Request:
t ist der TimeOut, s eine Session ID die nirgends genutzt wird? a ist logischerweise eine Liste der anfragten GAs,

Response:
"d" steht sicherlich für Data und ich schätze die CV erwartet da echtes JSON, also Reihenfolge der Attribute und zusätzliche Informationen sind egal.
aber was ist das "i" und welchen Inhalt erwartet die CV da? "i" und "d" sind sicher auch in der Reihenfolge egal?

Gruss,
Michael

[larsrosen]

- das kaputte eibread-cgi im aktuellen KNXd fixen - das wäre wohl der beste Weg, ich habe aber mal die source angeschaut und verstehe das nicht wirklich - ich hoffe die KNXD Leute gucken sich das an.

Was ich damals noch Probieren wollte, aber keine Lust mehr hatte,
Ein altes Eibread-cgi.c in den neuen Quellcode kopieren. Ich glaube dann müsste evtl. Nur der pfad angepasst werden, da es in ein anderen ordner verschoben wurde.

[MGK]

Chris M.
kommt die CometVisu mit zusätzlichen Feldern klar? Ich habe im Response noch ein "err" object eingebaut was eine Liste "unlesbarer" GAs reported - ich denke das könnte viele Fehlersuche vereinfachen - das kann man dann ja in den Dev Tools im Browser sehen.

kompletter Aufruf dauert bei mir mit 142 GA 0.9 Sekunden. 8 GA sind bei mit gar nicht lesbar, aber in der CV aktiv, das fand ich auch interessant. dafür das es "nur" Python ist und das knxtool 150x aufruft finde ich das ganz ok - ist aber nix für langsame Kisten.

edit: hab es gerade mal ausprobiert, die CV ignoriert (wie erwartet) das zusätzliche "err" Feld - CV läuft mit neustem KNXD!

[larsrosen]

Lösch mal die 8 GA die nicht lesbar sind raus und versuche den kNXD nochmal.

Das war zwischenzeitlich auch mal ein Bug, sollte noch ein Thread von mir hier geben.

https://knx-user-forum.de/forum/supp...-anzeige/page2

[MGK]

Moin,

ohne die "error" GA geht es tatsächlich auch mit dem originalen eibread-cgi. Der Response enthält trotzdem reichlich überflüssige, nicht angefragt GAs. Und das wegen 8 nicht lesbaren GA das script nicht mehr läuft (bzw. bei hoch gesetztem Timeout nach 12 Sekunden eine Antwort kommt) ist doch ein Bug.
Ich werde den Issue mal aktualisieren.

[larsrosen]

Wie gesagt, da sind noch andere im Code drinne, die aber alle nur mit USB SS auftauchen. Ich hatte irgendwann vor Verzweiflung auf IP umgestellt.

Ich weiss aber gar nett mehr was noch war wieso ich dann letztendlich wieder auf die 0.1.0 zurückgegangen war....

[MGK]

die CV läuft hier sauber mit meinem eibread-cgi Ersatz. Ist zwar langsamer und braucht mehr CPU, aber mein Hausserver langweilt sich eh den ganzen Tag.

Ich hoffe da die Leute vom KNXD Team sich das eibread-cgi.c anschauen und fixen, glaube aber nicht dran.

[Tru]

Ich hoffe da die Leute vom KNXD Team sich das eibread-cgi.c anschauen und fixen, glaube aber nicht dran.

Das glaube ich auch nicht. Schliesslich hat dieses Client-Tool mit KNXD nur insofern zu tun, dass makki dieses mal gezielt für CometVisu geschrieben und als Addon spendiert hat. Seither wird es wohl nicht mehr gross gepflegt. Vielleicht solltest du ihn mal nett direkt anfragen.

[MGK]

ich habe bei GitHub einen issue dafür aufgemacht und es versucht so gut wie möglich zu beschreiben. Ich kann aber ehrlich auch verstehen wenn für so eine CometVisu-Sonderlocke nicht viel Zeit investiert wird. Wenn da was passiert werde ich das natürlich unterstützen. Es kam auch schon ein kurzer Response.

Ich habe auch selbst mal in den eibread-cgi.c sourcecode reingeschaut, aber lesbar finde ich den nicht. C ist bei mir auch echt lange her...

Gruss,
Michael

[larsrosen]

Also,

wenn der Code so ne CV Locke ist, wieso wurde er dann von Smurf geändert?

Soweit ich das mitbekommen habe hat makki darüber auch nicht sonderlich erfreulich reagiert, da ich ihm damit auch aufn Keks gegangen bin.

Für die CV Community wäre es schön wenn man einfach da mal drüber schaut und den Fehler fixt.....

[MGK]

Smurf hatte auf meinen Issue auch kurz reagiert. Ich verstehe den Code aber echt zu wenig um da selber Änderungen zu machen und einen Pull request zu machen.
Und ich VERMUTE das eibread-cgi und eibwrite-cgi spezifisch CometVisu sind, aber sicher bin ich nicht.

aber "man liest und wartet auf Response" vs. mein "wenn das nicht im Cache ist gibt es halt keine Antwort, wir senden nur eine leseanfrage ohne zu Warten um den cache für den nächsten Request zu füllen" ist natürlich auch eine Philosophie Frage.

[makki]

Naja, wie soll ichs sagen:
- Ja, das ganze Protokoll, das ganze Verhalten (groupcache) wurde für Visus erdacht und mit der CV eben umgesetzt. Das kann man alles nachlesen auf der ML und auch multipel hier im Forum (muss man aber ein paar Jahre zurück, ich hab irgendwo noch alle SVN-commits)

Wenn das so nicht mehr geht (bei mir läuft eibd 0.0.4.18 - weil der funktioniert), muss man sich halt überlegen, warum zum Henker das mit aktuellem knxd dann nicht mehr geht, in 100-200 ms 1000 valide oder eben auch invalide GA's abzurufen
Wem 10J später was besseres für den mittlerweile 28J alten und seither im Kern nahezu unveränderten EIB/KNX einfällt, darf das gerne vorschlagen..

P.S.: ich hab zwar teilw. den Code verbrochen (der seit gut 8J und seit 7J(!!) aufm Geode, was 1/4 Raspi ist - einwandfrei funktioniert, werde mich da aber nicht reinhängen, da ich da wenig Optimierungs-potential sehe, außer eine sehr gute, funktionierende Lösung kaputt zu machen.
Edit: heisst: der knxd hat so zu funktionieren wie der eibd vor 8J schon, wenn dem nicht so ist muss er eben gefixed werden..

Makki