erste beta - fronthem, smartVISU (closed, Bitte die Anschlussthreads benutzen)

[herrmannj]

Hallo Jörg,

ich habe das gleiche Problem. Meinst du mit Version das hier :{"cmd":"proto","ver":"0.1"}} ?
Wenn ja, kommt das beim Aufruf vom Ipad aus nicht. Siehe Screenshots (.17 ist der PC, .25 ist das Ipad)

Gruß Norbert

Hi Norbert,

vmtl liegt es am Ipad - ich will da keine Hoffnungen wecken die ich hinterher nicht erfüllen kann. Mit Version ist das hier gemeint  http://websocketstest.com/

Die Ausgabe hinter "WebSocket protocol version"

vg
jörg

[redlav]

Hallo Jörg,

dank für die Info. Bei mir steht draft-76. Was sollte da den stehen, damit es funktioniert.
Auf dem PC kommt rfc-6455 dabei raus.

Gruß Norbert

[kumue]

Hi @all,

ich versuche jetzt seid gestern Abend ein encoding Problem zu lösen, langsam gehen mir die Ideen aus:

Problem: Umlaute werden in smartVISU falsch dargestellt.
Nachstellen:
fhem: dummy erstellen, dann set den dummy 'Ö'
sv:  basic.value
dann über "Direct" mit dem dummy verbinden.

Darstellung in sv als "Ö"

Das ist die korrekte (byte) Repräsentation  in UTF-8.

Der Weg fronthem -> sv geht über perl -> JSON (UTF8) -> ws (UTF8) -> JSON (UTF8) -> jquery mobile in sv.

Ich habe jetzt testweise überall mal convert (UTF8 ...) reingesetzt, bringt natürlich alles nix.
Den browser hab ich "hart" auf UTF8 gestellt (nix), nginx "gezwungen" UTF8 coding zu für die page zu verwenden (nix), meta im head in allen Spielarten ... (guess what: nix) ... jetzt gehen mitr irgendwie die Ideen aus.

Hat jemand weitere Ideen oder gar die Lösung ?

vg
jörg

Hallo,

gibt es dafür eine Lösung / Workaround ?

Ein Reading aus 55_GDS, welches ich über Converter Direct einlese, wird so dargestellt -> STURMBÖEN

Gruß Kai

[cruser1800]

Hallo,

gibt es dafür eine Lösung / Workaround ?

Ein Reading aus 55_GDS, welches ich über Converter Direct einlese, wird so dargestellt -> STURMBÖEN

Gruß Kai

Fragt mal bei bgewehr nach ich habe seine page übernommen! Hier werden die Umlaute korrekt dargestellt!

VG Lutz

[herrmannj]

Fragt mal bei bgewehr nach ich habe seine page übernommen! Hier werden die Umlaute korrekt dargestellt!

VG Lutz

ja aber nicht alle (afaik). Ds ist noch offen, ich hatte mal den driver im Verdacht, da ist HCS ja gerade bei.

vg
jörg

[HCS]

ja aber nicht alle (afaik). Ds ist noch offen, ich hatte mal den driver im Verdacht, da ist HCS ja gerade bei.

Ich habe es mal in die driver-todo-Liste aufgenommen und schaue, ob ich es mit einem dummy in fhem nachvollziehen kann.

[herrmannj]

ja das geht easy - einfach dummy mit "ÄÖÜäöü" und dann value , converter direct. Ich hab schon mal einen Abend damit verbracht, man sieht aber ganz schwer wo genau das passiert weil nicht klar ist ob die debug Wege (console, Dumper etc) dann jeweils UTF-8 sehen und ausgeben ... Ich dachte jetzt evtl an decode_JSON (wobei das eigentlich nach norm UTF-8 ist, bzw das uri-escape ... ).

Musst aber nicht machen, bin ja eigentlich ich gefordert. Wenn Du Lust hast trotzdem sehr gern .

vg
jörg

[HCS]

Kann es gerade nachvollziehen.
In SV steht nicht "Ölkännchen" sondern eine üble Abwandlung.
Ich schaue es mir mal an. Wenn ich belegen kann, dass der driver nix für kann, bist Du dann dran 

[herrmannj]

Hallo Jörg,

dank für die Info. Bei mir steht draft-76. Was sollte da den stehen, damit es funktioniert.
Auf dem PC kommt rfc-6455 dabei raus.

Gruß Norbert

Da https://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-76 stehen die drafts, per definition eben ein Entwurf, kein Standard....

Die werden unterstützt:

Code Auswählen Erweitern

    draft-ietf-hybi-17 (latest)
    draft-ietf-hybi-10
    draft-ietf-hybi-00 (with HAProxy support)
    draft-hixie-75

Mit dem Ipad1 bleibt also nur verschiedene Browser durchzuprobieren, ab Ipad2 läuft es out-of-the-box ...

Für Android entschärfe ich das mit der app entschärfen. Für Apple auch eine zu schreiben wäre theoretisch möglich, ich befürchte mir fehlt da die Zeit ...

vg
jörg

[redlav]

Hallo Jörg,

vielen Dank für deinen unermüdlichen Einsatz! Jetzt weiß ich wenigstens, das es nicht an mir liegt

Gruß Norbert

[herrmannj]

Kann es gerade nachvollziehen.
In SV steht nicht "Ölkännchen" sondern eine üble Abwandlung.
Ich schaue es mir mal an. Wenn ich belegen kann, dass der driver nix für kann, bist Du dann dran 

ja gern, so oder so. Ich ändere das gern sobald ich verstehe wo ..

vg
jörg

[HCS]

Ich habe den Verdacht, dass Du in FHEM einmal zuviel UTF-8 encodest.
Wenn ich mein Ölkännchen und die STURMBÖEN, die von FHEM kommen, zweimal UTF-8 decode, dann wird da wieder ein Ölkännchen und STURMBÖEN draus.
Das würde bedeuten, dass Du einmal weniger encoden solltest und ich einmal decoden muss.
Man sieht es auch schon optisch, das sind zu viele bytes für ein "Ö"
Mit testweise zweimal UTF-8 decoden im driver kommen die Umlaute dann auch korrekt im widget an.

[herrmannj]

base64 kodiert in einem eval - das merkt keiner und die Lösung wäre OK 

Ich mach mich mal auf die Suche. Normal müsste doch auch dem JSON UTF-8 rauspurzeln. Wenn Du zwei mal decodierst hat fronthem ja sogar zwei codierungen zu viel, oder ?

Danke
Jörg

[HCS]

Ja, da hast Du wohl recht. Mach mal zwei weniger und schau, ob es mit dem ungeänderten driver funktioniert.
Sicher ist aber: es liegt nicht an fehlenden encodings sondern an einer "übercodierung" 

Nachtrag: da war ich wohl schon halb im Bett. Da der DOM UTF-8 braucht, muss der "bereits UTF-8-String" fälschlicherweise noch zwei mal zusätzlich encoded sein.

[herrmannj]

ich habs befürchtet ... noch schlimmer ist das ich eigentlich (wissentlich) nix encode ...  Na, Danke für die Richtung, dann beginne ich mal die Suche ... 

vg