Universalclient

[tuxedo]

Jepp, so ist es. Hab in der Login-response die url vergessen. Jetzt geht's.

Was den Cross-Origin-Requests angeht:

Meinst du es ist ein problem den von Chrome angemerkten header fest einzubauen oder alternativ nach einem Check auf die URL bzgl. cross origin zu setzen?

[peuter]

Meinst du es ist ein problem den von Chrome angemerkten header fest einzubauen oder alternativ nach einem Check auf die URL bzgl. cross origin zu setzen?

Soweit ich das verstehe muß der Server doch diesen Header senden oder nicht. Da das Dein eigenes Backend ist kannst Du da doch einbauen was Du willst. Oder hab ich das falsch verstanden?

[tuxedo]

Wenn ich das richtig verstanden habe, dann muss das im Request-Header drin stehen, damit der browser das als "okay" für den Cross Origin Request durchgehen lässt. So nach dem Motto: "Ja, das ist Absicht."
Ich ich mach mich da nochmal schlau.

[peuter]

Liest sich für mich anders (unter der Vorraussetzung das das korrekt ist):
For each resource/page that Site B wants to make accessible to Site A, Site B should serve its pages with the response header:

Access-Control-Allow-Origin: http://siteA.com
Quelle:
http://stackoverflow.com/questions/1...in-header-work

[tuxedo]

*rechtduhast* http://enable-cors.org/server.html Finde es zwar *strange* dass der Server dem client die Erlaubnis gibt, aber gut, ich muss ja nicht alles verstehen ;-) Dann baue ich das mal ein und teste es.

[peuter]

Naja der Server liefert die Daten und hat somit auch das Recht den Clients den Zugriff zu erlauben oder eben nicht. Andersrum machts gar keinen Sinn. Hab den ganzen CORS Kram jetzt mal für openhab2 implementiert. SSE scheint das schon zu können, also für die Read-Requests braucht man bei SSE nichts zu machen, für die anderen (login, write, rrd) müssen die entsprechenden Header hinzugefügt werden. Ich habe folgende Header hinzugefügt:

Access-Control-Allow-Origin : *
Access-Control-Allow-Methods : "GET"
Access-Control-Allow-Headers : "X-Requested-With, Content-Type, Accept, Authorization"

Die ersten beiden braucht man sicherlich, bei dem "..Allow-Headers" Ding bin ich mit nicht so sicher ob und wofür man das braucht.

[tuxedo]

Hab auch ein wenig experimentiert. Ich hab

Access-Control-Allow-Origin : *

beim Login benötigt. Beim read hat das alleine nicht gereicht. Da hat er sich dann bzgl. kaputtem chunked encoding beschwert?! Werde das bei Gelegenheit weiter verfolgen. mod-proxy funktioniert ja auch zuverlässig.

[tuxedo]

So, kurzes Feedback:

Die aktuellen CV-Universalclient-Änderungen hab ich gestern Abend noch vollständig eingespielt und mit meinem Xoro Megapad in der Küche ausprobiert:

Scheint zu funktionieren. Nach dem aufwecken des Displays durch den PM und der Woli2-APP ist ohne wirkliche Verzögerung die Seite wieder online und verbunden. Damit ich immer schnell sehe ob die Verbindung noch da ist, sendet mein Backend abwechseln (2sek Takt) den Wert 1 und 0 mit einer speziellen "heartbeat-adresse" zurück an die CV. Dort habe ich ein Icon das sich entsprechend des Wertes umschaltet. Somit sehe ich immer sofort was sache ist, und ob die Verbindung noch lebt.

Wirklich super Sache mit dem nun funktionierenden Reconnect. Danke peuter

Auf dem Smartphone (wo ich das Feature nur bedingt brauche) bin ich mir noch nicht ganz sicher ob es zuverlässig läuft. Anfangs hat es wohl nicht funktioniert (vllt. noch alte JS Files im Browser Cache ?), dann gings aber auf einmal. Werde das im "langzeit-display-standby-test" am Smartphone noch weiter verfolgen.

Bzgl. CORS werde ich auch noch weiter testen. Aber spätestens wenn der Zugriff über Router/Nameservergrenzen hinweg möglich sein soll, könnte die ModProxy Lösung (bzw. die Auslieferung der CV durch das Backend) von Vorteil sein, da hier nur eine Adresse und Port nach außen gereicht werden müssen (Sicherheitsaspekte jeglicher Art mal außen vor gelassen).

[tuxedo]

Zu Stromwandlern für die Platine:

Was ist hiermit?
http://www.tme.eu/de/details/acx-105...andler/talema/
50A müssten reichen, oder?
Bei 2,73EUR netto ist das auch nicht teuer.

Andere Variante in der Übersicht: http://www.tme.eu/de/katalog/stromwandler_112516/

Und man könnte sich die dicken Leiterbahnen sparen wenn man da einfach im inneren nen 10mm^2 Leitung durchfädelt und oben wie unten an den Schraubklemmen anlötet (der Übergang zwischen Schraubklemme und der Leitung muss dann halt entsprechend gut/groß sein, nicht dass hier ein Stück Leiterbahn wieder ein Nadelöhr darstellt).

[peuter]

Beim read hat das alleine nicht gereicht. Da hat er sich dann bzgl. kaputtem chunked encoding beschwert?!

Beim read hab ichs gar nicht gebraucht, keine Ahnung was hier das Problem.

Aber ansonsten freut es mich zu hören, dass die ersten Tests erfolgreich waren. Aber Dein letzter Post war vermutlich nicht für diesen Thread gedacht, oder?

[tuxedo]

Irgendwas ist da schief gegangen :-(

[tuxedo]

So, der Dauertest läuft noch. Bis jetzt hatte ich es 2x dass kein Reconnect nach dem Display-Aufwecken stattgefunden hat. Da das Display in der Küche hängt und Remote-Debuggen auf Android ein kleines Problem ist, werde ich das mal weiter beobachten und versuchen das Muster dahinter raus zu finden. Erst wenn ich's reproduzieren kann macht es Sinn das Teil abzuhängen und im Büro zu debuggen.

Gibt's hier niemanden der CV mit OH benutzt und der mal SSE probieren möchte?

[tuxedo]

Läuft und läuft. Hatte es bis jetzt nur ein weiteres mal wo der Reconnect nicht funktioniert hat. Hab jedoch nicht herausgefunden an was das liegt.

[peuter]

Ich denke es ist an der Zeit für einen Pull Request, um die Testbasis etwas zu erweitern.
https://github.com/CometVisu/CometVisu/pull/227

[tuxedo]

Von mir ein klares: +1