Anfängerfrage: Installation cometvisu auf Debian (nicht WireGate)

[Habib]

Hi,

ich fürchte ihr schlagt die Hände über dem Kopf zusammen aber ich bin nun nach 8h lesen&suchen und probieren keinen Meter weitergekommen und ich wähne mich eigentlich schon fast am Ziel.

Ich habe vor für ein Projekt eine KNX Umgebung zu schaffen. Für diesen Zweck habe ich derzeit ein paar Essentielle Komponenten im Versuchsaufbau vorliegen, die soweit auch funktionieren. Jetzt war die Idee die Visualisierung über eine VM (virtuelle Maschine) (debian) auf dem vorhandenen Server laufen zu lassen. Soweit die Idee.

Ich habe denke ich das Backend relativ zügig kompiliert und installiert bekommen. Also ich kann per groupswrite GA's schalten. Ich sehe auch Bus-Traffic etc. ich habe auch die Dateien im cgi-bin Verzeichnis liegen (l, r, w mit deren Links auf /usr/local/bin/eibread-cgi&usr/local/bin/eibwrite-cgi)
Der lighthttp läuft auch und die cometvisu-Dateien in Version 0.8.3 sind auch da.

Jetzt zu meinem Problem. Der linknx-Daemon holt sich ja die zu überwachenden GAs aus der linknx.xml. Ich hab dort testweise eine Aktor-Rückmelde GA definiert (1/1/66) und hätte nun erwartet, dass ich irgendwie einen Status in der cometvisu angezeigt bekomme. Hierzu habe ich ganz grob die visu_config_demo.xml so abgeändert, dass alle Elemente die GA 1/1/66 bekommen. Irgend ein Demo Element muss mir doch dann eine Reaktion zeigen oder?

Ich hab weder in der eibd.log, noch im linknx eine reaktion vom cometvisu ausmachen können. Natürlich sieht der ETS Busmonitor auch nichts... wenn ich ein groupwrite mache dann ist alles sichtbar...
Jetzt befürchte ich, dass irgendwas in meinem CGI-Backend noch so falsch ist, dass ich den Wald vor lauter Bäumen nicht sehe. Kann mir da jemand auf die Sprünge helfen?

Ich hatte gedacht, dass ich mich dann im Selbstversuch lernend durch das Thema arbeiten kann, aber wenn es komplett nicht funktioniert, dann bin ich da wirklich aufgeschmissen.

Danke vorab für eure Hilfe

Gruß
Habib

[Chris M.]

Nun, Du scheinst schon viel umgesetzt zu haben.

Bei Debian bietet sich oft (wenn x86, evtl auch AMD64) an, die WireGate Pakete zu nehmen - das WG ist ja auch nur Debian und die notwendigen Pakete sind bewusst kompatibel gehalten.

Um hier den Ansatz zu finden wo es klemmt, ist es am einfachsten die JavaScript Konsole zu öffnen und mal schaun welche Rückmeldung der Server bei den "l", "r" und "w" URLs gibt.
Insb. das Schreiben (z.B. Klicken auf einen Switch) und das folgende "w" sind da interessant. Das kann durchaus gehen, wenn das "r" noch nicht will.

[Habib]

Hi,

das ist ja klasse das sich meiner jemand annimmt :-)

Meinst du die Ausgabe wenn ich wie in meinem Fall z.B. http://192.168.100.58/cgi-bin/l aufrufe?

Ich bekomme immer nur die gleiche Ausgabe

{ "v":"0.0.1", "s":"SESSION" }

bzw.

{'error': 'No data'}

Ich hab noch nicht wirklich gerafft, wie die URLs nun vom Syntax mit Parameter lauten sollten...

[Chris M.]

Gut, das "l" tut schon mal so wie es soll.

Was passiert nun beim "w", also wenn Du auf einen Switch klickst?

[Habib]

Leider nicht viel :-(

Hab mal nen Screenshot angehängt wie sich das bei mir darstellt.

Der dazu passende link.xml Teil:

<objects>
        <object type="1.001" id="test_on_off" gad="1/1/66">Objet test</object>
        <object type="1.001" id="test_on_off2" gad="1/1/58">Object test</object>
        <object type="10.001" id="cur_time" gad="0/1/1">Current Time</object>
        <object type="11.001" id="cur_date" gad="0/1/2" flags="cwtuf">Current Date</object>
    </objects>

Hier noch der Teil aus der visu_config.xml:

<trigger value="1" mapping="On_Off">
      <label>Trigger</label>
      <address transform="DPT:1.001" mode="readwrite" variant="test_on_off">1/1/66</address>
    </trigger>
    <break/>
    <switch mapping="On_Off" styling="Red_Green" on_value="1" off_value="0" align="left" bind_click_to_widget="true">
      <label>test_on_off</label>
      <address transform="DPT:1.001" mode="readwrite">1/1/66</address>
    </switch>

Oder steh ich komplett auf dem Schlauch?

[Chris M.]

Ich versteh da gerade nicht ganz, was Du machst.
Erst mal: linknx hat mit der CometVisu nichts zu tun. Deren einzige Verbindung ist der KNX-Bus an sich...

Also mach mal schrittweise:

1. ETS anwerfen und Busmonitor aktivieren
2. Auf dem Server per groupswrite auf der Konsole irgend etwas an 1/1/66 senden
   => die ETS sollte das anzeigen
3. Nun in der CV auf den Trigger klicken (was einen Aufruf der "w" URL mit passenden Parameter ausführen sollte)
   => zeigt die ETS dieses Paket an?
   => was kommt im Browser auf der Debug-Konsole für eine Rückmeldung vom Server? HTTP-Code? Inhalt der Rückmeldung?

[swiss]

Gut möglich dass deine Config nicht korrekt ist. Hast du mal die komplete config als Anhang?

Du hast z.B. beim Trigger als Variant "test_on_off" eingetragen. Das kann aber eigentlich nicht sein... Und solche sachen können dazu führen, dass die ganze Config schlicht kaputt geht. vor allem wenn man sie von Hand bearbeitet...

[Habib]

Hi Chris,

ich glaub ich muss erstmal verifizieren ob die Debug Konsole auch wirklich die richtige ist. Aktuell guck ich nach der Ausgabe wie im angehängten ersten Screenshot. Also als Reaktion passiert da gar nicht...

Der Busmonitor unter ETS registriert den groupswrite Befehl ordnungsgemäß, so wie es sein sollte:

habib@cometvisu:~$ groupswrite ip:127.0.0.1 1/1/66 0
Send request

Die Busmonitorausgabe siehst du im 2. Screenshot.

[swiss]

Jetzt bin ich total verwirrt.

Du schreibst erst, dass keine Telegramme an den BUS gesendet werden und nun funktioniert es doch? Dann hätte sich das Problem ja gelöst? Oder verstehe ich die Fragestellung falsch?

Was natürlich sein kann... dass nur ein Teil der Widgets funktionieren denn gewisse Fehlkonfigurationen führen schlicht dazu, dass dieses Widget oder gar alle nachfolgende Widgets in der Config nicht mehr funktioniert. Desshalb meine Frage nach der originalen kompletten Config als Anhang.

[Habib]

Hi swiss,

die config hab ich mal angehängt. Im Moment hab ich auch noch elementare Verständnisprobleme von der Funktionalität. Mir sind die Zusammenhänge leider noch nicht ganz klar... evtl. auch nicht mehr ganz klar, nachdem ich da 6h rumgebastelt hab...

[Habib]

Jetzt bin ich total verwirrt.

Du schreibst erst, dass keine Telegramme an den BUS gesendet werden und nun funktioniert es doch? Dann hätte sich das Problem ja gelöst? Oder verstehe ich die Fragestellung falsch?

Ne, das ist es ja. Ich hab alles 1:1 gem. der Doku installiert und es hat auch alles geflutscht... eben bis zu dem Punkt wo ich eigentlich irgendwas in der Web GUI erwartet hab. Ab da hat es mich verlassen. Das groupswrite und Busmonitoring klappt einwandfrei, nur irgendwo ist da die Verbindung zwischen Web und dem Bus nicht da.
Deshalb dachte ich ja auch die ganze Zeit dass es nicht viel sein kann... aber mittlerweile bin ich so wirr, dass ich da wohl auch Fehler eingebaut hab wo vorher keine waren...

[swiss]

Hallo Habib

Hmmm... Das einzige was mir bei der Durchsicht auffällt ist der Variant in Zeile 75. Wo kommt das her? Das kann unter umständen (nicht getestet) dazu führen dass alles ab Zeile 75 was mit dem senden auf den BUS zutun hat nicht mehr korrekt funktioniert.

Entferne mal variant aus Zeile 75 und teste noch mal alle Widgets auf ihre Funktion

[Chris M.]

ich glaub ich muss erstmal verifizieren ob die Debug Konsole auch wirklich die richtige ist.

Jain. Die Konsole ist an sich richtig - nur der Reiter ist ungeschickt. Die Netzwerk-Analyse wäre hier das passende.

Unten ist ein Bild, wie das bei einer funktionierenden CV im Firefox aussieht.

Der Busmonitor unter ETS registriert den groupswrite Befehl ordnungsgemäß, so wie es sein sollte:

Das hatte ich auch so erwartet. Dann können wir das schon mal als funktionierend annehmen.

Ne, das ist es ja. Ich hab alles 1:1 gem. der Doku installiert und es hat auch alles geflutscht... eben bis zu dem Punkt wo ich eigentlich irgendwas in der Web GUI erwartet hab. Ab da hat es mich verlassen.

Ah, das ganze hatte schon mal funktioniert - nur mit einer neuen Config nicht mehr?
Dann brauchen wir nur noch dort suchen...

(Um das sicherzustellen gibt's einen einfachen Test: öffne einfach die Demo-Config: http://der/pfad/?config=demo und klicke ganz oben einfach mal auf die beiden Trigger - der Switch sollte dann folgen)

[swiss]

Ich sage ja... Der Variant in Zeile 75 wird höchst warscheinlich das Problem sein

EDIT: Ausser es gäbe noch mehr dass ich beim ersten überfliegen nicht gesehen habe

[Habib]

Hi Chris,

juhu, ich hab grad endlich mal ne Ausgabe in der Debug Konsole :-)
Anhang ist bei.

Leider hat die Cometvisu bisher eben noch nicht funktioniert. Nur das Backend hat immer schon gefunzt... der Screenshot von dem richtigen Debug Fenster hab ich nicht gefunden? hoffe das es trotzdem jetzt richtig ist?


@swis
das mit dem variant hat leider keine Änderung gebracht...