CometVisu - (interner) Beta-Test

[makki]

Jungs, ich brauch mal eure Glaskugel, ich sitz hier seit zwei Stunden wie der Ochs vorm Berg und/oder steh komplett aufm Schlauch:

ist kein WG (sondern OpenWRT), kein lighty (uhttpd), selbe CometVisu, selbe cgi's aber eben mit uclibc und so.
Das eibread-cgi liefert (Anhang 1), was dem Visuclient natürlich nicht gefällt (0x00 statt ":" nach dem d und trailing nochmal - sagen Firebug und Wireshark - Anhang 2)
Richtig wäre Anhang 3

Gut, das ist ein echt total komplexer printf, also nicht wildes, andere ":" kommen ja auch

Lokal auf der Konsole passt das cgi

Und jetzt wirds lustig: teste ich mit curl gegen den Server:

markstaller@v1520-mm:~/Temp$ curl "http://172.17.2.77/cgi-bin/r?t=0&f=FILTER&a=1/1/11&a=5/2/79&a=1/5/61&a=1/1/11"
[B][COLOR="Red"]{"d" {"[/COLOR][/B]1/1/11":"01","5/2/79":"0E3A"},"i":3040}

markstaller@v1520-mm:~/Temp$ curl  [COLOR="Red"][B]-v[/B][/COLOR] "http://172.17.2.77/cgi-bin/r?t=0&f=FILTER&a=1/1/11&a=5/2/79&a=1/5/61&a=1/1/11"
* About to connect() to 172.17.2.77 port 80 (#0)
*   Trying 172.17.2.77... connected
* Connected to 172.17.2.77 (172.17.2.77) port 80 (#0)
> GET /cgi-bin/r?t=0&f=FILTER&a=1/1/11&a=5/2/79&a=1/5/61&a=1/1/11 HTTP/1.1
> User-Agent: curl/7.21.0 (i686-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.18
> Host: 172.17.2.77
> Accept: */*
> 
< HTTP/1.1 200 OK
< Connection: close
< Transfer-Encoding: chunked
< Content-Type: text/plain
< [B][COLOR="Red"]{"d": {[/COLOR][/B]"1/1/11":"01","5/2/79":"0E3A"},"i":3122}
< 
* Closing connection #0
[B][COLOR="Red"]{"d" {[/COLOR][/B]"1/1/11":"01","5/2/79":"0E3A"},"i":3122}

Also irgendwo isser ja da der ":", hab ich Tomaten auf den Augen ?? Sonst würde ich auf einen ganz strangen Bug in besagtem uhttpd tippen (gefühl: in der uclibc gibts nicht solche fundamentalen Bugs bei printf und auf der console, inkl. hexdump passt alles) nur lt. curl -v ist da irgendwie ja doch alles da..
Der ":" +- 5 Zeichen wurde im C-source mehrfach durch einen : ersetzt

Edit: Ups, ich dödel hab das anhängen vergessen

Makki

[makki]

Es gibt da aber AFAIR wohl noch eine Bit-Variante bei div. älteren RTR, vielleicht kann sich jemand dazu äussern, der es auch real benutzt weil RTR-Statusobjekte und Zwansführung sind bei mir nur graue Theorie..

Makki

[manu241]

Hallo Chris,

ja es ist der '20.102'. Habe es hier ihm Forum beim Misterhouse gefunden.

Link

Außerdem habe ich (siehe Anhang) es in einer Bedienungsanleitung von Berker gefunden

Gruß Manuel

[Chris M.]

Ach ja, und ein RTR-Widget für die "analogen" brauchts IMHO noch für die elementare Grundausstattung. Soll,Ist, Komfort usw. Der Sinn dieser hat sich mir zwar ebenfalls nie ganz erschlossen (Sollwert und eine Änderung dieses tuts genauso), ist aber halt so..

Nachdem ich in meinem jugendlichen Leichtsinn schrieb:

Wegen dem RTR-Widget schau ich mal was geht...

Irgendwie finde ich keinem der "KONNEX Betriebsartenumschaltung" zugehörigen DPT. Welcher ist das? (20.102?)

[makki]

Der Nachbar hat kein Wlan:

wegen der kleinen.. (Kind)

Das ist der Ausgleich

Scherz beiseite, die Orginalantennen liegen dahinter am Boden, das sind halt nur Männermodelle mit etwas mehr Gain, weil mir zuhause schon wieder die Switchports ausgehen, wenns pro Stockwerk einen AP braucht..

Makki

[luigi4711]

Sieht ja nett aus.... aber was ist mit den äusseren Antennen los

[makki]

Den BM hatte ich schonmal auf das relativ aktuelle angepasst,, aber irgendwie hat der trotzdem nie in ein packerl gefunden (Fiel mir aber erst vor ein paar Tagen auf, bei mir ist er ja drauf - wird nachgeholt!)
Ist ja für bestimmte Anwendungsfälle eine sehr praktische Sache..

Das mit dem speichern bekomm ich schon hin (eine Visu ohne Editor: ), ist ja nur bequemlichkeit und genug vorh. Resourcen, die das irrelevant machen, überhaupt darüber nachzudenken ob man grad Lust auf C, PHP, python oder lua hat..
Ich hab übrigens absolut nichts gegen PHP, bei Neuentwicklungen in Perl wäre die Gegenwehr grösser, hier bietet sich gerade am ehesten lua an (openwrt, kein Full-fledged x86-Debian), ist aber jetzt echt tertiär

Makki

P.S.: Fritzbox war nah dran, kostet nur im EK ca. 1/4
Die CometVisu läuft schon wie ein glöckerl.. aber es sollte ja nur ein IP-Busmaster werden

[Chris M.]

Läuft auch seit eben mit bekannter Umgebung, eibd&cgi PHP ist noch a bisserl a Problem mit 4MB Flash (von Perl reden wir mal nicht..)
Intern läuft das Gerät zwar nur als potentieller "1-Wire IP-Busmaster", aber es schadet ja nicht wenn die CometVisu auch schonmal drauf laufen würde

PHP wird eigentlich nur zum Speichern der Seiten benötigt. Wenn der Editor nicht zwingend benötigt wird, sollte das als Plattform reichen - eine Fritz!Box ist ja auch sehr limitiert.
Anwendungsfall wäre z.B. eine CometVisu basierte Statusseite. Oder der Busmonitor von mir, der allerdings noch auf den CometVisu-Client portiert werden müsste...

Wenn der Editor auch sein soll, dann müssten wir noch etwas Hirnschmalz reinstecken, wie man das Speichern am besten löst (sollte aber nicht unmöglich sein)

[makki]

Na gut, hätte ja sein können (Das ich da nur was übersehen habe)
KNX,Rest: schon klar..

Läuft auch seit eben mit bekannter Umgebung, eibd&cgi PHP ist noch a bisserl a Problem mit 4MB Flash (von Perl reden wir mal nicht..)
Intern läuft das Gerät zwar nur als potentieller "1-Wire IP-Busmaster", aber es schadet ja nicht wenn die CometVisu auch schonmal drauf laufen würde

Makki

[Chris M.]

Wie bereits geschrieben brauchst Du wenn, dann die Web-Sockets.

Aber das halte ich vom Design her für eine schlechte Lösung:

• KNX Tunneling => ein normales IP Gateway reicht nicht für mehrere Visus
• Das JavaScript muss das KNX Protokoll genau so gut wie der eibd können
• Bei einem Start des Systems fehlen die letzten Zustände - so überhaupt lesbar, würde erst mal eine riesige Paket-Flut entstehen
• Nur Browser die das implementieren können verwendet werden

Und ganz wichtig:

• das ist eine KNX proprietäre Lösung! (Keine Anbindung an die internen Werte der Logik Engine, kein xPL, kein ...)

Andererseits:
Das CometVisu-Protokoll ist so einfach, da kann man sich im Zweifel ganz leicht und schnell einen spezialisierten Deamon schreiben, der das benötigte HTTP-Subset spricht und versteht und der nur die eibd-Anbindung macht. Durch die Code-Minimalität ohne jegliche Bedenken bzgl. Sicherheit.
Und so klein, dass der selbst auf einem µC laufen würde...

[netzkind]

Aber kann man denn einen nackerten Socket ohne HTTP mit jquery/Ajax machen? (also ohne HTML5 und Browser, die 2015 dann rauskommen natürlich..)

Weil ich mir da jetzt auch nicht sicher war hab ich meine Meinung mit der hier in der Abteilung abgelichen, und der aktuelle Zustand ist: nein, gibt es nicht.
Selbst Websockets sind nicht: WebSockets in Firefox 4 wegen Lücke im Protokolldesign deaktiviert [Update] | heise Security

Und normale Sockets gibt es in Javascript nicht ohne über Gateways zu gehen (bspw. über ein eingebettetes Flash wie “Real” Javascript Sockets! - Mayflower Blog oder https://code.google.com/p/jsocket/ )

Grüße,
Julian

[makki]

Mal so eine Frage, ich hab ja bei JS ned so wirklich den durchstieg, was die in handelsüblichen Browsern real verfügbaren Optionen angeht:

Angenommen, man spart sich den Webserver für read/write (die Files, html,xml,js,css usw kommen natürlich nach wie vor von dort!) und geht direkt auf KNXnet/IP Tunneling (langsam, einige drawbacks) oder die eibd-API per TCP (groupcachelastupdates - genauso schnell/resourcenfreundlich wie aktuell)

Aber kann man denn einen nackerten Socket ohne HTTP mit jquery/Ajax machen? (also ohne HTML5 und Browser, die 2015 dann rauskommen natürlich..)
Weil falls ja, hab ich heute mit einem 30.- EUR CometVisu-Server gespielt

Makki

[makki]

Beim Slider gab's einen bug..

VIIIEL besser !

Wo die Kekse herkommen: keine Ahnung, ich wäre mir keiner Schuld bewusst, scheint auch nur im FF und wenn man sie löscht, werden sie auf die schnelle scheinbar auch nicht wieder erstellt..
Evtl. ein FF/Firebug-interna (?)

Makki

[Chris M.]

- das "zappeln" der Slider besser in den Griff bekommen

Beim Slider gab's einen bug der die Updates beim Sliden verhindert hatte und es gab einen Bug im Encoding des DPT:5.010 der für fieses Zappeln sorgen konnte.
=> Beides ist jetzt behoben, bitte mal schaun, ob der Punkt so nun noch offen ist.

Zur Zeit versuche ich endlich meine Touchs in den Serien-Betrieb zu überführen (inkl. automatischer An- und Abschaltung) so wie die Basis-Visu hier laufen zu lassen (der WAF hat schon die Höhe des damaligen Invests in Frage gestellt )
=> Durch das "Eat your own food" ist man durchaus gezwungen Fehler zu beheben, über die man sonst leicht hinweg gesehen hatte...

@Julian: Im Chromium mag der Editor nicht so ganz, bzw. die Buttons und Select-Boxen funktionieren (meistens) nicht. Kannst Du da mal schaun?

@Expire vs. Namen: Noch bin ich hier am Nachdenken was die beste Lösung ist. Denn ihr könnt Euch sicher sein, ich will keine gute Lösung, ich will die technisch beste und sauberste...
Das der Entwickler mit Einschränkungen leben können muss, die ein Anwender nicht sehen darf (z.B. den Cache ausschalten) bin ich d'accord.
Ein Cachen ohne nachzufragen, ob sich was geändert hat, finde ich dagegen technisch höchst unbefriedigend da gefährlich - auch wenn dadurch Traffic erzeugt wird (der wird aber nur zur Setup-Time und nicht zur Run-Time erzeugt!), der natürlich meistens per 304 beantwortet werden sollte.
Cookies sollten uns dagegen nicht stören - denn ich wüsste nichts, was bei der CometVisu ein Cookie erfordert (wer setzt eigentlich momentan das "sid" und das "testing" Cookie - das sollten wir rausnehmen!)

[makki]

Veto.

Ihr versucht grade ein Feature des Browsers abzuschalten das auf unserer Seite ist. Ich versteh das echt nicht - wieso das die Lösung sein soll.

Einverstanden, wir alle wollen - ggfs. auf Teufel komm raus - 110% Performance; mindestens irgendwas muss ja auch richtig besser sein und mein Ziel ist immernoch, das es mindestens doppelt so schnell wie CommanderconFusion ist (was übrigens derzeit locker so ist)
Aber deswegen sprechen wir ja auch darüber und deswegen fragte ich, bevor das Fakt wird..

Kompromissvorschlag:
- Expires für die *.xml (optimal wäre, der Client prüft das auch alle XX Minuten - denkt man an 5 Visus im Haus). Kostet dann einen 304 beim laden oder alle XX Minuten; problematisch ist das ja nur bei dyn. php/pl/whatever, statische Files beantwortet der lighty in 30ms mit 304
Weil wann sich die config ändert, naja, das weiss man eben nicht..
- ?rev=SVNREV/Versionnummer für alles andere (js, css, ..)
Wer entwickelt und daran dreht, dem ist IMHO wirklich zuzumuten, sich das no/clear-cache Plugin im Browser zu installieren.. (sollten wir aber dokumentieren, weil die Lernkurve hier auch recht steil ist und das ist einer der pitfalls..)

Makki