Scheint bei mir auch gefixt.
Wir haben in der Tat eine kleine Verbesserung bei der Rekodierung nach UTF-8 gemacht. Ich werde das im Changelog nachpflegen.
paresy
Heißt was? Kann man die Skripte jetzt wieder mit Umlauten nutzen?
„Leichte Verbesserungen“ - insbesondere im Webfront kann auch ich feststellen. Es bleibt aber noch eine Reihe an Punkten offen:
Hier meine aktuelle Übersicht:
- die Einträge im IPS Logfile sind noch nicht 100% richtig
- die Einträge im IPSLogger sind noch nicht 100% richtig
- die Suchausgaben in der Konsole sind noch falsch
Gruß
Burkhard
Was gibt es denn auf diesem Gebiet Neues?
Mittlerweile sind seit der Ankündigung von paresy auch schon fast 2 Monate vergangen und langsam nerven diese blöden Sonderzeichen im Webfront und den Logs echt.
In der Beta von gestern ist die Suchausgabe nun korrekt.
Aber die Ausgaben in den Logfiles sind weiterhin falsch.
@paresy: seid ihr da noch dran?
Gruß
Burkhard
Hi,
wir sind an dem Thema noch dran. Mittlerweile haben wir auch fast alle Probleme lösen können.
Was noch offen ist:
-IPS_GetObjectIDByName funktioniert mit Umlauten nicht zuverlässig
-Umlaute sind in den Logfiles nicht konsistent (Kodierung wird einfach vom Text der „reinkommt“ übernommen)
Bei den letzten zwei Punkten bin ich mir noch nicht ganz sicher, wie ich das Elegant und ohne Nebenwirkungen löse.
paresy
Hallo paresy,
meiner Beobachtung nach liegen die falsch dargestellten Umlaute daran, dass ich nach der Umstellung von 3.4 auf 4.0 eine Mischung aus Scripten im (neuen) UTF-8 und im (alten) Windows ANSI Format habe.
Leider habe ich noch keinen Weg in der Konsole gefunden, die alten Skripte in das neue Format zu überführen.
Bei problematischen Scripten helfe ich mir
$scriptID = 47111;
$script = IPS_GetScriptContent($scriptID);
if (mb_detect_encoding($script, 'UTF-8', true)=== false){
IPS_SetScriptContent($scriptID, utf8_encode($script));
echo "---- Script: $scriptID nach UTF-8 kodiert".PHP_EOL;
}
und konvertiere ins UTF-8 Format. Alle Skripte auf einmal zu konvertieren habe ich mich noch nicht getraut:o
Dann bleibt aber noch übrig, dass einige Programme (z.B. der Logger oder das Highcharts Modul der IPS Library) die übergebenen Texte im ANSI Format erwarten …
Hier ist dann wohl noch mal brownson gefordert, oder?
Bin ich damit auf dem richtigen Weg?
Viele Grüße
Burkhard
Ich habe es gestern gewagt upzudaten V3.4 > V4.2(stable vom 25.04.17) 
So sieht es bei mir auch aus, wenn ich einen Text an die Squeezeboxen schicke:
Bisher (3.4) verlief das ganz sorgenfrei so:
slim_text_wzi($wzibox_mac, "Bad $badtemp °C Kü $kuetemp °C Kzi $kzitemp °C Szi $szitemp °C", "$zeit Uhr $atemp °C ~ $wind km/h ($windrichtung) ~ $luftdruck hPa ($luftdrucktendenz) $ns $nsint ~ Wzi: $wzitemp °C", 60); // Textfolge an Squeezebox
function slim_text_wzi($box , $text1 , $text2 , $time) // text1= obere Zeile / text2= untere Zeile
{
$TX_BUF = $box." display " .rawurlencode($text1)." ".rawurlencode($text2)." ".$time.chr(13);
$result = CSCK_SendText(27592, $TX_BUF);
}
Gleiches Problem beim Senden von Text an die Mobotix, da werden die Umlaute, wie „ü“ in gefühlt garnicht erst angezeigt.
Ebenso finde ich im Logfile Einträge, wie diese:
09:16:16 | 13512 | MESSAGE | Serial Port | Öffne Port...
Was muss ich bei „CSCK_SendText“ noch im Script ändern, dass mir die Umlaute wieder korrekt dargestellt werden?
Ansonsten verlief das Update relativ zufriendenstellend, bis auf das Problem „Duration“-Problem (Wegfall) mit „AC_GetLoggedValues“. Das finde ich sehr unschön und brauchts einen Workaround:mad:
Hast du mal unter -Kern Instanzen, Utils Handler die Umlaute korrigieren lassen? Danach sind die meisten Umlaute OK.
Danke für die Antwort!
Hatte darauf aber keine Änderung:(
Womit zeigst du die Logs denn an? Diese sind seit 4.x konsistent UTF-8 kodiert. Dein Anzeigetool muss damit also auch klar kommen.
Und ggf. schickst du an die SqueezeBox etwas und kodierst es doppelt? Such mal nach utf8_encodes… Die müssen normalerweise raus.
paresy
Hallo paresy,
Mit dem stinknormalen Windows-Editor:
12:56:57 | 35003 | MESSAGE | Client Socket | Schließe Socket...
12:56:57 | 35003 | MESSAGE | Client Socket | Öffne Socket...
12:57:16 | 20674 | WARNING | ScriptEngine | Ergebnis für Ereignis 45941
Und ggf. schickst du an die SqueezeBox etwas und kodierst es doppelt? Such mal nach utf8_encodes… Die müssen normalerweise raus.
Ich habe nur ein „rawurlencode“ drin, so wie in dem Codeschnipsel auf der vorhergehenden Seite gezeigt.
Mit dem Text an die Mobotix-Kamera läuft ja auch nicht und da ist garkeine Umkodierung dabei. Ein „ü“ wird beim Kameratext garnicht mehr angezeigt.
Evtl kann die SqueezeBox kein UTF-8. Dann müsstest du mit utf8_decode ran. Mein stinknormaler Editor unter Windows 10 kann UTF-8. Welche Windows Version nutzt du? Magst du mal z.B. Notepad++ ausprobieren?
paresy
Ich habs hier mit Windows 7.
Mit Notepad++ siehts fast gut aus…
10:24:57 | 35003 | MESSAGE | Client Socket | Schließe Socket...
10:24:57 | 35003 | MESSAGE | Client Socket | Öffne Socket...
10:25:00 | 51807 | WARNING | ScriptEngine | Ergebnis für Ereignis 46126
<br />
<b>Warning</b>: Division by zero in <b>H:\IP-Symcon\scripts\Auࠥntemperatur
…macht aber hier und da auch Spirenzien (Siehe ß bei Aussen)
OK…
function slim_text_wzi($box , $text1 , $text2 , $time) // text1= obere Zeile / text2= untere Zeile
{
$TX_BUF = $box." display " .rawurlencode(utf8_decode($text1))." ".rawurlencode(utf8_decode($text2))." ".$time.chr(13);
$result = CSCK_SendText(27592, $TX_BUF); //über COM Port senden
}
Läuft!
Danke!
Funktioniert das bei dem RSS-Kanal vom LMS auch? Da habe ich noch die selbe Leiche im Keller liegen.