CometVisu kann nicht bedient werden

[jbrey]

Hier die Ausgaben vom Write:
Sowohl bei Response als auch beim Preview steht da nur "{'success':1}"

Beim darauffolgenden Read siehts weniger rosig aus:
Bei Response kommt: "This request has no response data available."
Beim Preview kommt: "This request has no preview available."

Gruss JB


Hab grad noch nen Test gemacht:
Wenn ich im Browser direkt "http://192.168.200.100/cgi-bin/w?a=0/0/4&v=81&ts=1325164202444" aufrufe (zum Schreiben einer 1) klappt das mit success und der Aktor schaltet auch!
Die Übergabe von 1 u. 0 an den Bus scheint also in beide Richtungen problemlos zu funktionieren.
Vielleicht hilft das bisschen weiter ...

[Chris M.]

Ich kann da im Chrome zwischen den Reitern Headers, Preview, Response, Cookies u. Timing wählen.

Response wäre der richtige. (Oder zum leichteren Lesen der Preview - der lässt sich aber nur doof hier posten. Und die übertragen Daten sind beim Test so gering, dass Response lesbar genug sein sollte; außerdem ist das die unangetastete Wahrheit und nicht weiter verarbeitet...)

[jbrey]

Ich kann da im Chrome zwischen den Reitern Headers, Preview, Response, Cookies u. Timing wählen.

Bei Headers z.B. erhalte ich folgende Daten für den Write:

• Request URL:
  http://192.168.200.100/cgi-bin/w?a=0/0/4&v=80&ts=1325162340826
• Request Method:
  GET
• Status Code:
  200 OK
• Request Headersview source
  • Accept:
    application/json, text/javascript, */*; q=0.01
  • Accept-Charset:
    ISO-8859-1,utf-8;q=0.7,*;q=0.3
  • Accept-Encoding:
    gzip,deflate,sdch
  • Accept-Language:
    de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4
  • Connection:
    keep-alive
  • Host:
    192.168.200.100
  • Referer:
    http://192.168.200.100/visu/
  • User-Agent:
    Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.63 Safari/535.7
  • X-Requested-With:
    XMLHttpRequest
• Query String Parametersview URL encoded
  • a:
    0/0/4
  • v:
    80
  • ts:
    1325162340826
• Response Headersview source
  • Content-Type:
    text/plain
  • Date:
    Thu, 29 Dec 2011 12:38:29 GMT
  • Server:
    lighttpd/1.4.28
  • Transfer-Encoding:
    chunked

• Und folgende Daten für den darauffolgenden Read:

• • Request URL:
    http://192.168.200.100/cgi-bin/r?s=SESSION&a=9/1/0&a=0/0/4&t=0
  • Request Method:
    GET
  • Status Code:
    200 OK
  • Request Headersview source
    • Accept:
      application/json, text/javascript, */*; q=0.01
    • Accept-Charset:
      ISO-8859-1,utf-8;q=0.7,*;q=0.3
    • Accept-Encoding:
      gzip,deflate,sdch
    • Accept-Language:
      de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4
    • Connection:
      keep-alive
    • Host:
      192.168.200.100
    • Referer:
      http://192.168.200.100/visu/
    • User-Agent:
      Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.63 Safari/535.7
    • X-Requested-With:
      XMLHttpRequest
  • Query String Parametersview URL encoded
    • s:
      SESSION
    • a:
      9/1/0
    • a:
      0/0/4
    • t:
      0
  • Response Headersview source
    • Content-Type:
      text/plain
    • Date:
      Thu, 29 Dec 2011 12:38:30 GMT
    • Server:
      lighttpd/1.4.28
    • Transfer-Encoding:
      chunked
  • Ist es das was du meinst?

[Chris M.]

Beim Read-Vorgang wird
http://192.168.200.100/cgi-bin/r?s=S.../0&a=0/0/4&t=0
aufgerufen - und mit Status Code "200 OK" gemeldet

Sehr gut. Was sagt der Inhalt der Nachricht?
Und wie sieht der nächste "r" aus, der ja aufgerufen wird, sobald dieser angekommen ist?

Beim Write-Vorgang wird
http://192.168.200.100/cgi-bin/w?a=0...=1325160645105
aufgerufen - und mit Status Code "200 OK" gemeldet
(sieht nach Value 0 aus zum Schreiben an Adresse 0/0/4 - wär richtig!)

Beim erneuten Write-Vorgang wird (wieder)
http://192.168.200.100/cgi-bin/w?a=0...=1325160757933
aufgerufen - und mit Status Code "200 OK" gemeldet
(da wird m.E. wieder eine 0 an 0/0/4 geschrieben - genau da hakts)

Richtig. Beide sollten den Wert "0" an die 0/0/4 schreiben.
Und jedes mal sollte der "r" mit einem Wert für die 0/0/4 (nämlich "0"...) zurückkehren und neu gestartet werden.

Da der Status Code jedes mal passt, ist nun die große Frage, wie sieht's in den Nachrichten aus? (Geht auch über die Netzwerk-Sicht den Inhalt anzeigen zu lassen)

[jbrey]

Hab jetzt mal die "Request URLs" rausgesucht.

Beim Read-Vorgang wird
http://192.168.200.100/cgi-bin/r?s=S.../0&a=0/0/4&t=0
aufgerufen - und mit Status Code "200 OK" gemeldet

Beim Write-Vorgang wird
http://192.168.200.100/cgi-bin/w?a=0...=1325160645105
aufgerufen - und mit Status Code "200 OK" gemeldet
(sieht nach Value 0 aus zum Schreiben an Adresse 0/0/4 - wär richtig!)

Beim erneuten Write-Vorgang wird (wieder)
http://192.168.200.100/cgi-bin/w?a=0...=1325160757933
aufgerufen - und mit Status Code "200 OK" gemeldet
(da wird m.E. wieder eine 0 an 0/0/4 geschrieben - genau da hakts)

Gruss JB

[Chris M.]

Da liefert er mir dann bei den "w" immer ein "{'success':1}" - bei beiden Aktionen.
Auch wenn er eine "1" schreiben soll wird das angezeigt, es tut sich aber leider gar nix.

Diese Antwort beim Write ist eine etwas freie Interpretation der Spec unter SourceForge.net: CometVisu/Protocol - Open Automation
Aber die sieht an sich gut aus - und sollte auch ein Paket auf den KNX geschrieben haben.

Write ist aber auch einfach.

Read ist deutlich spannender. Was sagt das die Netzwerk-Seite?

[jbrey]

Ok, das mit der Drück-Animation ist gut zu wissen - hatte mich doch sehr beunruhigt ...
Ich hab jetzt mal die "r" und "w" Einträge im Chrome so anzeigen lassen wie du geschrieben hattest.
Da liefert er mir dann bei den "w" immer ein "{'success':1}" - bei beiden Aktionen.
Auch wenn er eine "1" schreiben soll wird das angezeigt, es tut sich aber leider gar nix.

Hoffe das hilft dir etwas weiter ...

[Chris M.]

Bitte mal im Chrome mit rechts irgendwo auf die Seite klicken und "Element überprüfen" nehmen (oder halt sonst wie den Debug-Modus öffnen...)

Unter dem Reiter "Network" siehst Du alle Verbindungen.

Dor insb. mal schaun was "r" sagt (Status-Code, Inhalt).
Aber auch mal auf ein "w", dass nach Button-Druck kommt.

PS: Die Drück-"Animation" während des Klicks gibt's beim Switch nicht, der ist ja dann dauerhaft gedrückt oder nicht, je nach Status halt.

[jbrey]

Guten Morgen!
Leider funktioniert bei mir die Visu immer noch nicht .. hab jetzt ziemlich alles gelesen was damit in Verbindung stehen könnte, komme aber leider nicht weiter.
Hoffentlich kann mir hier noch jemand den entscheidenden Tip geben?!

Aktueller Stand ist:
- Kann eibd ganz normal via Shell starten oder auch via KNX-Konfiguration in der WG-Oberfläche
- Die Visu lässt sich normal aufrufen im Browser (Chrome)
- Der integrierte Editor funktioniert ohne Probleme, Änderungen werden gespeichert
- Wenn ich in im Widget-Demo z.B. den Button "Trigger an" anklicke erscheint der Button auch optisch "gedrückt", bei Elementen vom Typ Switch od. Toggle wird optisch nichts "gedrückt"
- Wenn ich im Editor ein Element vom Typ Switch mit der entsprechenden GA hinterlege und dann den Normal Mode aufrufe wird da kein Wert angzeigt/eingelesen und es erscheint im Button selbst nur ein "-"
- Beim Klick auf den Switch-Button wird dann scheinbar eine "0" auf den Bus gesendet (das betreffende Licht geht aus).
- Auch hier wird wieder scheinbar keine Rückmeldung empfangen/angezeigt
- Beim erneuten Klicken wird dann auch keine "1" mehr gesendet (liegt m.E. dran dass er nicht weiss dass die "0" schon gesendet wurde und er jetzt switchen muss?!)

Anpassungen wir z.B. die Berechtigungen von /tmp/eib hab ich schon gemacht .. leider ohne Erfolg.

Ich bin wirklich mit meinem Latein am Ende - hoffe ihr noch nicht ;-)

Dankeschön für jede Art von Tipp!!!

Gruss JB

[makki]

Die Versionen sollten IMHO passen (die eibd-client-sources nicht, aber solange sie nicht davon gebaut wurden: egal)

-> Nochmal zur Klarstellung: das einzige was im offiziellen eibd 0.0.5 dafür derzeit "fehlt" sind die beiden CGI-Clients eibread-cgi/eibwrite-cgi. Sowie ggfs. Rechte auch den Socket /tmp/eib (was ich immernoch für nervige Makulatur halte, weil wenn wenigstens einer der drei IP-Server gestartet ist, können eh Hanni&Nanni im LAN..)

Makki

[do13]

ii libeibclient0 0.0.5 eibd client library

Kannst du hier mal bitte 0.0.4+nmu18 versuchen. Bin mir jetzt nicht so sicher ob die Clientprogramme mit dem 0.0.5 funktionieren.

[jbrey]

Ok, danke. Den Zugriff per ETS werde ich bei Gelegenheit mal testen.
Hab jetzt bisschen in dem anderen Artikel gestöbert ...
jetzt hätte ich fast die Versionen in Verdacht.
Kann mir jemand sagen ob das soweit ok ist bitte?!
ii eibd-client-sources 0.0.5 Sources of the eibd client programs
hi eibd-clients 0.0.4+nmu18 eibd clients
ii eibd-config-wg 0.2-11 eibd init and config files for WireGate
ii eibd-server 0.0.5 eibd server
ii libeibclient-dev 0.0.5 eibd client library
ii libeibclient0 0.0.5 eibd client library

Danke!

[Chris M.]

Wenn Du dem eind ein "-T" bei den Parametern mitgibst, dann hast Du das Tunneling freigeschaltet und Du kannst mit der ETS per IP-Tunnel zugreifen

Außerdem wichtig: hast Du einen passenden eibd der auch neu genug ist?

Un im Thread https://knx-user-forum.de/cometvisu/...-hardware.html steht auch viel was bei der Fehlersuche helfen kann.

[jbrey]

Hab jetzt mal mit der Console (da wo der EIBD läuft) einen groupwrite auf diese GA gemacht (mit der ETS kann ich nichts separat schreiben, da ja die USB-Schnittstelle im Moment am Visu-Gerät hängt).
Auf der Oberfläche ändert sich deshalb aber nichts (Es bleibt das "-").

Mit ist jetzt aber gerade beim Testen aufgefallen dass ich durch Klicken des Buttons scheinbar eine 0 auf die GA geschrieben bekomme (also sprich das betreffende Licht ausgeht). Wenn ich aber nochmal draufklicke wird keine 1 geschrieben, es bleibt aus ...

[Chris M.]

Das "-" heißt nur, dass der Eibd-Cache einfach nicht weiß, welcher Wert dort hin solle, da er noch nicht da war.

Sende mal mit der ETS, eine groupwrite o.ä. einen Wert die entsprechende GA und das "-" sollte hoffentlich durch den entsprechenden Wert ersetzt werden...