FHEM Forum

FHEM => Anfängerfragen => Thema gestartet von: RoBra81 am 04 April 2018, 14:33:18

Titel: [gelöst] Cubietruck + FHEM + utf8
Beitrag von: RoBra81 am 04 April 2018, 14:33:18
Hallo,

bei mir läuft FHEM schon lange auf einem Cubietruck (ziemlich altes igor-Image, das aber immer mal wieder apt-get update und upgrade bekommt). Nun habe ich in einem Modul das Problem, dass Umlaute nicht richtig dargestellt werden (z.B. Müllkalender -> M?llkalender). Ein

dpkg-reconfigure locales

habe ich schon mehrfach auf utf-8 gesetzt. Rufe ich in der SHH-Konsole über putty

locale

auf, dann erhalte ich

LANG=de_DE.UTF-8
LANGUAGE=de_DE.UTF-8
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES=POSIX
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=


Gebe ich jedoch in der FHEM-Eingabezeile

{qx('locale')}

ein, so ist das Ergebnis

LANG=
LANGUAGE=
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=


Wie kann ich nun mein FHEM dazu bewegen, ebenfalls utf-8 zu sprechen?

Vielen Dank

Ronny
Titel: Antw:Cubietruck + FHEM + utf8
Beitrag von: RoBra81 am 04 April 2018, 15:48:11
Nachtrag: wenn ich FHEM mit

shutdown

beende und über putty neu starte passen die locales auch aus FHEM:

{qx('locale')}

liefert

LANG=de_DE.UTF-8
LANGUAGE=de_DE.UTF-8
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES=POSIX
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=


:-\
Titel: Antw:Cubietruck + FHEM + utf8
Beitrag von: betateilchen am 04 April 2018, 15:56:25
Kommt immer darauf an, wer mit "ich" gemeint ist. Du solltest bedenken, dass die FHEM Prozesse i.d.R. nicht mit dem gleichen user laufen, den Du in putty benutzt. Die locale können unter Linux benutzerbezogen angelegt werden.

Meines Wissens spricht FHEM von Haus aus utf8 und das schon ziemlich lange.
Bist Du sicher, dass Du nicht einfach ein Browserproblem bei den Darstellungen von Umlauten hast?
Titel: Antw:Cubietruck + FHEM + utf8
Beitrag von: RoBra81 am 04 April 2018, 16:04:27
Zitat von: betateilchen am 04 April 2018, 15:56:25
Bist Du sicher, dass Du nicht einfach ein Browserproblem bei den Darstellungen von Umlauten hast?

Ziemlich: das Problem ist nicht die Darstellung, sondern das das Modul 57_GCALVIEW meinen Müllkalender M?llkalender nennt und ihn nur abruft, wenn die Konfiguration M?llkalender lautet. Da im Attribut jedoch Müllkalender steht, erfolgt keine Aktualisierung. Nach dem oben beschriebenen Neustart aus putty über

/etc/init.d/fhem start

stimmen wie gesagt die locales im FHEM und der Müllkalender wir auch mit Attribut Müllkalender korrekt aktualisiert...

;D ;D ganz schön viele Müllkalender im Text  ;D ;D


EDIT: FHEM läuft in beiden Fällen als user fhem...
Titel: Antw:Cubietruck + FHEM + utf8
Beitrag von: mumpitzstuff am 04 April 2018, 16:48:01
Das Problem ist hier, das FHEM nach einer gewissen Zeit oder bedingt durch irgendwelche internen Abläufe die locale Einstellungen vergisst. Direkt nach einem Neustart kann über die Kommandozeile

{qx('locale')}

aufgerufen werden und FHEM meldet völlig korrekt de_DE.UTF-8.

Wenn er jetzt FHEM anscheinend eine Weile laufen lässt, dann erzeugt das selbe Kommando nicht mehr de_DE.UTF-8, sondern steht plötzlich auf:

LANG=
LANGUAGE=
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=


Kann irgendein Modul innerhalb von FHEM daran schuld sein? Zumindest bei mir bleibt die Ausgabe immer gleich, egal ob ich die Abfrage direkt nach dem Restart von FHEM mache oder Stunden bzw. Tage später.

Versuch mal:

apt-get --reinstall install locales

Vielleicht ist bei dir irgendwas durcheinander. Oder hast du mal was an den entsprechenden locale Dateien manuell geändert?

Wenn du irgendwas mit perl machst, kommt dann sowas in der Art?

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
    LANGUAGE = (unset),
    LC_ALL = (unset),
    LANG = "de_DE.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory


Denn so ein fallback auf locale ("C") würde genau dein POSIX Zeugs erklären glaube ich. Vielleicht versucht auch eins deiner Module ein locale zu setzen, scheitert aber daran, da das nicht installiert ist und fällt dann auf das POSIX Zeug zurück. Vielleicht hilfts ja auch alle möglichen locales erzeugen zu lassen. Auf einem Raspberry kann man alle möglichen erzeugen lassen und dann nur eine bestimmte davon setzen.
Titel: Antw:Cubietruck + FHEM + utf8
Beitrag von: RoBra81 am 04 April 2018, 19:34:19
Das Problem kommt nicht nach längerer Laufzeit, sondern nach einem reboot des Servers: nach einem automatischen Start von fhem stimmen die locales nicht, erst nach shutdown und /etc/init.d/fhem start stimmen die locales und GCALVIEW funktioniert...

Gesendet von meinem SM-G935F mit Tapatalk

Titel: Antw:Cubietruck + FHEM + utf8
Beitrag von: mumpitzstuff am 04 April 2018, 19:52:42
Ah okay. Also führt der automatische Start zu der zerschossenen codepage. Wodurch wird fhem gestartet? Kannst du da mal einen Blick rein werfen? Vielleich ist am startup Skript was faul. Wie hast du fhem installiert? Kannst du ein komplettes Backup machen und mal neu installieren?
Titel: Antw:Cubietruck + FHEM + utf8
Beitrag von: helmut am 04 April 2018, 20:20:36
Zitat von: RoBra81 am 04 April 2018, 19:34:19
Das Problem kommt nicht nach längerer Laufzeit, sondern nach einem reboot des Servers

Hallo Ronny,

klappt denn der Wechsel vom Benutzer "root" zu "fhem"? Was zeigt ein {qx('id')} auf der fhem-Kommandozeile
nach einem reboot und nach einem Restart des Dienstes?

Gibt es eventuell im daemon-Log passende Fehlermeldungen im Umfeld von "Started LSB: FHEM server."?
Gibt es eventuell in /var/log/syslog passende Fehlermeldungen im Umfeld von "Starting fhem..." und
"Started LSB: FHEM server."?

Gruss Helmut
Titel: Antw:Cubietruck + FHEM + utf8
Beitrag von: mumpitzstuff am 04 April 2018, 20:24:55
Du kannst auch mal versuchen fhem später zu starten. Siehe hier:

https://wiki.fhem.de/wiki/Linux_Initskript (https://wiki.fhem.de/wiki/Linux_Initskript)
Titel: Antw:Cubietruck + FHEM + utf8
Beitrag von: RoBra81 am 04 April 2018, 20:47:38
Zitat von: helmut am 04 April 2018, 20:20:36
Hallo Ronny,

klappt denn der Wechsel vom Benutzer "root" zu "fhem"? Was zeigt ein {qx('id')} auf der fhem-Kommandozeile
nach einem reboot und nach einem Restart des Dienstes?

Vorher wie nacher

uid=999(fhem) gid=20(dialout) groups=20(dialout)

Zitat von: helmut am 04 April 2018, 20:20:36
Gibt es eventuell in /var/log/syslog passende Fehlermeldungen im Umfeld von "Starting fhem..." und
"Started LSB: FHEM server."?

Nein, keine Meldungen zu FHEM
Titel: Antw:Cubietruck + FHEM + utf8
Beitrag von: mumpitzstuff am 04 April 2018, 21:48:40
Ich vermute das FHEM vor den locales geladen wird. Dadurch stehen die dann nicht zur Verfügung. Wenn du es dann später manuell startest, dann sind sie da und du hast keine Probleme mehr.

Lösung wäre den Start zu verzögern. Entweder irgendwie die Reihenfolge ändern (Link siehe oben) oder im Startup Skript könnte man auch was verzögern.

sudo nano /etc/init.d/fhem

Dann danach suchen und dort wie bei mir 20s oder so eintragen:

echo "Starting fhem..."
sleep 20s
Titel: Antw:Cubietruck + FHEM + utf8
Beitrag von: RoBra81 am 05 April 2018, 10:41:26
Selbst eine Verzögerung von 20 Sekunden hatte keinen Erfolg - erst nach manuellem Neustart stimmen die locales...
Titel: Antw:Cubietruck + FHEM + utf8
Beitrag von: mumpitzstuff am 05 April 2018, 15:36:33
Das mit der Reihenfolge hast du auch versucht?

cd /etc/rc3.d
ls -l
sudo mv K01fhem K99fhem

K01 kann bei dir anders sein...
Titel: Antw:Cubietruck + FHEM + utf8
Beitrag von: RoBra81 am 05 April 2018, 15:54:05
Mein Server startet im RunLevel 2 und da (in /etc/rc2.d/) war das fhem-Script (wegen # Required-Start: $all) schon ganz am Ende (S20fhem) (K ist das zum killen). Habe es trotzdem mal auf S99 geändert - ohne Erfolg...
Titel: Antw:Cubietruck + FHEM + utf8
Beitrag von: mumpitzstuff am 05 April 2018, 16:39:42
Stimmt. S natürlich.

Hmm dann habe ich keine Ahnung mehr. Tut mir leid.
Titel: Antw:Cubietruck + FHEM + utf8
Beitrag von: helmut am 06 April 2018, 19:57:00
Zitat von: RoBra81 am 05 April 2018, 15:54:05
Mein Server startet im RunLevel 2 und da (in /etc/rc2.d/) [...]

Hallo Ronny,

das finde ich ungewoehnlich. Runlevel 2 startet Multi-User ohne Netz. Aber wie auch immer, wenn
Du "Required-Start: $all" im fhem-Skript stehen hast, sollte das auch in allen anderen Runleveln
zum Schluss gestartet werden wenn der update-rc.d druebergelaufen ist.

Die Arbeitshypothese von mumpitzstuff hat dennoch einen einen gewissen Charme. Versuch doch
mal Folgendes in der /etc/rc.local. Ich hoffe, das laeuft auf Deinem System so ohne Weiteres.


for n in 0 60; do
  for u in root fhem; do
    (sleep $n; logger $u $n sec: $(su -l - $u -c locale)) &
  done
done


Vielleicht bringen Dir die logger-Ausgaben in /var/log/syslog (suche nach "logger:") neue Erkenntnisse.
Die sleep-Zeiten kannst Du ja noch variieren.

Gruss Helmut
Titel: Antw:Cubietruck + FHEM + utf8
Beitrag von: RoBra81 am 07 April 2018, 18:25:58
Das einzige, was ich mit logger finde ist das:


Apr  7 18:18:47 homeserver kernel: [    3.128465] logger: created 256K log 'log_main'
Apr  7 18:18:47 homeserver kernel: [    3.136806] logger: created 256K log 'log_events'
Apr  7 18:18:47 homeserver kernel: [    3.145224] logger: created 256K log 'log_radio'
Apr  7 18:18:47 homeserver kernel: [    3.153632] logger: created 256K log 'log_system'


Gesendet von meinem SM-G935F mit Tapatalk


Titel: Antw:Cubietruck + FHEM + utf8
Beitrag von: RoBra81 am 07 April 2018, 18:36:04
Es hat auch scheinbar nix mit der Verzögerung zu tun, da auch ein shutdown restart nicht hilft, sondern nur shutdown mit anschließendem manuellem Start über putty...

Gesendet von meinem SM-G935F mit Tapatalk

Titel: Antw:Cubietruck + FHEM + utf8
Beitrag von: helmut am 08 April 2018, 13:52:26
Hallo Ronny,

beim "shutdown restart" bleibt das Environment des Prozesses (und damit auch die Spracheinstellungen) gleich.
Das gilt auch, wenn ein einfacher sleep vor den Aufruf von fhem beim Systemstart eingesetzt wird. Mit dem "su -l"
beim Start von fhem wird das Environment erneuert. In Kombination mit dem sleep passiert das deutlich nach dem
Systemstart.

Schade, dass der Test in der rc.local nicht funktioniert hat. Wenn Du magst, kannst Du versuchen das "-e" am Ende
des shebang zu entfernen und die Datei von Hand aufzurufen. Dann siehst Du, warum die Schleife nicht ausgefuehrt
wird.

Du kannst auch gleich versuchen, das "su" anstelle von "perl fhem.pl fhem.cfg" in das fhem-Startskript einzubauen:

(sleep 120; su -l root -c "set -e; cd /opt/fhem; port=7072; perl fhem.pl fhem.cfg") &

Gruss Helmut
Titel: Antw:Cubietruck + FHEM + utf8
Beitrag von: RoBra81 am 08 April 2018, 14:01:58
Zitat von: helmut am 08 April 2018, 13:52:26
Wenn Du magst, kannst Du versuchen das "-e" am Ende
des shebang zu entfernen und die Datei von Hand aufzurufen. Dann siehst Du, warum die Schleife nicht ausgefuehrt
wird.

Meine rc.local sieht jetzt so aus:

#!/bin/sh
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

echo 2 > /proc/irq/$(cat /proc/interrupts | grep eth0 | cut -f 1 -d ":" | tr -d " ")/smp_affinity
KILLPROC=$(ps uax | pgrep fbi | tail -1); if [ -n "$KILLPROC" ]; then kill $KILLPROC; fi

for n in 0 60; do
  for u in root fhem; do
     (sleep $n; logger $u $n sec: $(su -l - $u -c locale)) &
   done
done

exit 0


und ich erhalte diese Fehlermeldung:

/etc/rc.local: 18: /etc/rc.local: Syntax error: "do" unexpected (expecting "done")


Ronny
Titel: Antw:Cubietruck + FHEM + utf8
Beitrag von: helmut am 08 April 2018, 16:34:27
Hallo Ronny,

welche Shell verwendet Dein System fuer /bin/sh? Die ermittelst Du mit "echo $0". In meinem Raspbian ist das
ein Link auf /bin/bash. Und die kann mit verschachtelten for/do-Konstrukten umgehen. Kannst Du Deine Shell
mit zusaetzlichen Klammern austricksen?
for n in 0 60; do
   (for u in root fhem; do
      (sleep $n; logger $u $n sec: $(su -l - $u -c locale)) &
   done)
done


An Zeilentrennern kann es nicht liegen, denn das funktioniert in der bash auch:
for n in 0 60; do for u in root fhem; do (sleep $n; logger $u $n sec: $(su -l - $u -c locale)) & done done

Gruss Helmut
Titel: Antw:Cubietruck + FHEM + utf8
Beitrag von: RoBra81 am 12 April 2018, 09:23:53
So, nun habe ich es so in der rc.local:

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

echo 2 > /proc/irq/$(cat /proc/interrupts | grep eth0 | cut -f 1 -d ":" | tr -d " ")/smp_affinity
KILLPROC=$(ps uax | pgrep fbi | tail -1); if [ -n "$KILLPROC" ]; then kill $KILLPROC; fi

for n in 0 60; do
   (for u in root fhem; do
      (sleep $n; logger $u $n sec: $(su -l - $u -c locale)) &
   done)
done

exit 0


und das Ergebnis beim Reboot (nachdem ich dem user fhem die bash freigegeben habe) im syslog:

Apr 12 08:53:52 homeserver root: root 0 sec: LANG=de_DE.UTF-8 LANGUAGE=de_DE.UTF-8 LC_CTYPE="de_DE.UTF-8" LC_NUMERIC="de_DE.UTF-8" LC_TIME="de_DE.UTF-8" LC_COLLATE="de_DE.UTF-8" LC_MONETARY="de_DE.UTF-8" LC_MESSAGES=POSIX LC_PAPER="de_DE.UTF-8" LC_NAME="de_DE.UTF-8" LC_ADDRESS="de_DE.UTF-8" LC_TELEPHONE="de_DE.UTF-8" LC_MEASUREMENT="de_DE.UTF-8" LC_IDENTIFICATION="de_DE.UTF-8" LC_ALL=
Apr 12 08:53:52 homeserver root: fhem 0 sec: LANG=de_DE.UTF-8 LANGUAGE=de_DE.UTF-8 LC_CTYPE="de_DE.UTF-8" LC_NUMERIC="de_DE.UTF-8" LC_TIME="de_DE.UTF-8" LC_COLLATE="de_DE.UTF-8" LC_MONETARY="de_DE.UTF-8" LC_MESSAGES=POSIX LC_PAPER="de_DE.UTF-8" LC_NAME="de_DE.UTF-8" LC_ADDRESS="de_DE.UTF-8" LC_TELEPHONE="de_DE.UTF-8" LC_MEASUREMENT="de_DE.UTF-8" LC_IDENTIFICATION="de_DE.UTF-8" LC_ALL=
Apr 12 08:54:52 homeserver root: root 60 sec: LANG=de_DE.UTF-8 LANGUAGE=de_DE.UTF-8 LC_CTYPE="de_DE.UTF-8" LC_NUMERIC="de_DE.UTF-8" LC_TIME="de_DE.UTF-8" LC_COLLATE="de_DE.UTF-8" LC_MONETARY="de_DE.UTF-8" LC_MESSAGES=POSIX LC_PAPER="de_DE.UTF-8" LC_NAME="de_DE.UTF-8" LC_ADDRESS="de_DE.UTF-8" LC_TELEPHONE="de_DE.UTF-8" LC_MEASUREMENT="de_DE.UTF-8" LC_IDENTIFICATION="de_DE.UTF-8" LC_ALL=
Apr 12 08:54:52 homeserver root: fhem 60 sec: LANG=de_DE.UTF-8 LANGUAGE=de_DE.UTF-8 LC_CTYPE="de_DE.UTF-8" LC_NUMERIC="de_DE.UTF-8" LC_TIME="de_DE.UTF-8" LC_COLLATE="de_DE.UTF-8" LC_MONETARY="de_DE.UTF-8" LC_MESSAGES=POSIX LC_PAPER="de_DE.UTF-8" LC_NAME="de_DE.UTF-8" LC_ADDRESS="de_DE.UTF-8" LC_TELEPHONE="de_DE.UTF-8" LC_MEASUREMENT="de_DE.UTF-8" LC_IDENTIFICATION="de_DE.UTF-8" LC_ALL=


Wenn nicht das richtig interpretiere hat der user fhem die locales korrekt gesetzt?!

Daher habe ich nochmal weiter probiert und nun wird's komisch:

Ich habe mal mein fhem-Startscript in /etc/init.d/ angepasst und die Zeile

logger localesFhem at $1: $(su -l - fhem -c locale)

vor dem Start von fhem ergänzt. Nun steht nach einem Neustart des Servers folgende Zeile im Syslog:

Apr 12 09:13:08 homeserver root: localesFhem at start: LANG=de_DE.UTF-8 LANGUAGE=de_DE.UTF-8 LC_CTYPE="de_DE.UTF-8" LC_NUMERIC="de_DE.UTF-8" LC_TIME="de_DE.UTF-8" LC_COLLATE="de_DE.UTF-8" LC_MONETARY="de_DE.UTF-8" LC_MESSAGES=POSIX LC_PAPER="de_DE.UTF-8" LC_NAME="de_DE.UTF-8" LC_ADDRESS="de_DE.UTF-8" LC_TELEPHONE="de_DE.UTF-8" LC_MEASUREMENT="de_DE.UTF-8" LC_IDENTIFICATION="de_DE.UTF-8" LC_ALL=


Die locales sind also scheinbar auch hier schon gesetzt, im FHEM sind sie es jedoch nicht?!
Titel: Antw:Cubietruck + FHEM + utf8
Beitrag von: helmut am 12 April 2018, 12:42:29
Hallo Ronny,

das ist in der Tat richtig komisch. Als letzten Versuch haette ich noch anzubieten, den Benutzer "fhem" in
"logger localesFhem at $1: $(su -l - fhem -c locale)" im "fhem-Startscript durch "root" zu ersetzen. Ich
halte es zwar nicht fuer wahrscheinlich, dass root zu diesem Zeitpunkt ein anderes Environment hat
(welches fhem mit setuid erbt), aber der Teufel ist ja bekanntlich ein Eichhoernchen  ;)

Wenn auch dabei nichts herauskommt, gehen mir langsam die Ideen aus.

Gruss Helmut
Titel: Antw:Cubietruck + FHEM + utf8
Beitrag von: helmut am 12 April 2018, 14:27:33
Hallo Ronny,

das war eben ueberhaupt nicht zu Ende gedacht. Eigentlich ist doch zumindest fuer den Benutzer "fhem" zum
Zeitpunkt der Ausfuehrung des Startskriptes schon alles in Ordnung. Mein Vorschlag war ja
(sleep 120; su -l root -c "set -e; cd /opt/fhem; port=7072; perl fhem.pl fhem.cfg") &
aber wenn dem so ist, kannst Du sogar das sleep weglassen
su -l fhem -c "set -e; cd /opt/fhem; port=7072; perl fhem.pl fhem.cfg"

Unter rein akademischen Gesichtspunkten kannst Du auch ein
logger localesFhem at $1: $(locale)
in das Startskript einbauen um zu verifizieren, dass die locales fuer root zu diesem Zeitpunkt falsch sind.

Gruss Helmut
Titel: Antw:Cubietruck + FHEM + utf8
Beitrag von: RoBra81 am 13 April 2018, 11:24:33
Zitat von: helmut am 12 April 2018, 14:27:33
aber wenn dem so ist, kannst Du sogar das sleep weglassen
su -l fhem -c "set -e; cd /opt/fhem; port=7072; perl fhem.pl fhem.cfg"

Das habe ich jetzt mal probiert und siehe da, nach dem Start hat FHEM die korrekten locales  ;D

Zitat von: helmut am 12 April 2018, 14:27:33
Unter rein akademischen Gesichtspunkten kannst Du auch ein
logger localesFhem at $1: $(locale)
in das Startskript einbauen um zu verifizieren, dass die locales fuer root zu diesem Zeitpunkt falsch sind.

Auch das habe ich aus Interesse mal gemacht und habe feststellen müssen, dass root nicht nur zu diesem Zeitpunkt an der Stelle die falschen locales hat, sondern auch noch nach x Tagen Laufzeit, was man beim Stop des Servers sieht:

Apr 13 11:14:55 homeserver root: localesFhem at stop: LANG=de_DE.UTF-8 LANGUAGE=de_DE.UTF-8 LC_CTYPE="de_DE.UTF-8" LC_NUMERIC="de_DE.UTF-8" LC_TIME="de_DE.UTF-8" LC_COLLATE="de_DE.UTF-8" LC_MONETARY="de_DE.UTF-8" LC_MESSAGES=POSIX LC_PAPER="de_DE.UTF-8" LC_NAME="de_DE.UTF-8" LC_ADDRESS="de_DE.UTF-8" LC_TELEPHONE="de_DE.UTF-8" LC_MEASUREMENT="de_DE.UTF-8" LC_IDENTIFICATION="de_DE.UTF-8" LC_ALL=
Apr 13 11:14:55 homeserver root: localesFhem ohne su at stop: LANG= LANGUAGE= LC_CTYPE="POSIX" LC_NUMERIC="POSIX" LC_TIME="POSIX" LC_COLLATE="POSIX" LC_MONETARY="POSIX" LC_MESSAGES="POSIX" LC_PAPER="POSIX" LC_NAME="POSIX" LC_ADDRESS="POSIX" LC_TELEPHONE="POSIX" LC_MEASUREMENT="POSIX" LC_IDENTIFICATION="POSIX" LC_ALL=
Apr 13 11:17:29 homeserver root: localesFhem at start: LANG=de_DE.UTF-8 LANGUAGE=de_DE.UTF-8 LC_CTYPE="de_DE.UTF-8" LC_NUMERIC="de_DE.UTF-8" LC_TIME="de_DE.UTF-8" LC_COLLATE="de_DE.UTF-8" LC_MONETARY="de_DE.UTF-8" LC_MESSAGES=POSIX LC_PAPER="de_DE.UTF-8" LC_NAME="de_DE.UTF-8" LC_ADDRESS="de_DE.UTF-8" LC_TELEPHONE="de_DE.UTF-8" LC_MEASUREMENT="de_DE.UTF-8" LC_IDENTIFICATION="de_DE.UTF-8" LC_ALL=
Apr 13 11:17:29 homeserver root: localesFhem ohne su at start: LANG= LANGUAGE= LC_CTYPE="POSIX" LC_NUMERIC="POSIX" LC_TIME="POSIX" LC_COLLATE="POSIX" LC_MONETARY="POSIX" LC_MESSAGES="POSIX" LC_PAPER="POSIX" LC_NAME="POSIX" LC_ADDRESS="POSIX" LC_TELEPHONE="POSIX" LC_MEASUREMENT="POSIX" LC_IDENTIFICATION="POSIX" LC_ALL=


Da ich für diese Lösung die bash für den User fhem aktivieren musste, ist das sicherlich nicht die optimale Lösung, aber zumindest funktioniert es jetzt erstmal...

Vielen Dank

Ronny
Titel: Antw:Cubietruck + FHEM + utf8
Beitrag von: helmut am 13 April 2018, 12:37:23
Zitat von: RoBra81 am 13 April 2018, 11:24:33
Auch das habe ich aus Interesse mal gemacht und habe feststellen müssen, dass root nicht nur zu diesem Zeitpunkt an der Stelle die falschen locales hat, sondern auch noch nach x Tagen Laufzeit, was man beim Stop des Servers sieht:
Hallo Ronny,

das muss an der Debian-Implementierung fuer den Cubietruck liegen. Das ist fuer mich unter anderem ein
Grund auf leistungsfaehigere und ebenfalls stromsparende Alternativen zum RP zu verzichten.

Zitat von: RoBra81 am 13 April 2018, 11:24:33
Da ich für diese Lösung die bash für den User fhem aktivieren musste, ist das sicherlich nicht die optimale Lösung,
Die bash ist doch nichts Schlechtes und aus gutem Grund Voreinstellung bei vielen Linux-Systemen.

Zitat von: RoBra81 am 13 April 2018, 11:24:33
aber zumindest funktioniert es jetzt erstmal...
Das ist doch die Hauptsache. Schreibst Du bitte noch ein "[Gelöst]" vor den Betreff Deines ersten Beitrages? Danke.

Gruss Helmut

Titel: Antw:Cubietruck + FHEM + utf8
Beitrag von: RoBra81 am 13 April 2018, 14:22:54
Zitat von: helmut am 13 April 2018, 12:37:23
Die bash ist doch nichts Schlechtes und aus gutem Grund Voreinstellung bei vielen Linux-Systemen.
Die bash ist nichts schlechtes und wird auch bei mir eingesetzt, aber ich meine, in diversen Foreneinträgen/Anleitungen gelesen zu haben, dass der user fhem sich gar nicht anmelden können sollte (false statt bash in passwd). Aber egal, Hauptsache, es funktioniert.

Zitat von: helmut am 13 April 2018, 12:37:23
Das ist doch die Hauptsache. Schreibst Du bitte noch ein "[Gelöst]" vor den Betreff Deines ersten Beitrages? Danke.

Mache ich sofort, nochmal danke.

Ronny
Titel: Antw:[gelöst] Cubietruck + FHEM + utf8
Beitrag von: helmut am 13 April 2018, 19:48:25
Zitat von: RoBra81 am 13 April 2018, 14:22:54
Die bash ist nichts schlechtes und wird auch bei mir eingesetzt, aber ich meine, in diversen Foreneinträgen/Anleitungen gelesen zu haben, dass der user fhem sich gar nicht anmelden können sollte (false statt bash in passwd). Aber egal, Hauptsache, es funktioniert.
Ronny

Hallo Ronny,

da gibt es durchaus kontroverse Meinungen
https://forum.fhem.de/index.php/topic,36120.msg313007.html#msg313007 (https://forum.fhem.de/index.php/topic,36120.msg313007.html#msg313007)
und es scheint Module zu geben, die sogar eine bash voraussetzen wie zum Beispiel 57_GCALVIEW
https://forum.fhem.de/index.php/topic,77502.msg694178.html#msg694178

Also mach Dir deswegen keine Gedanken.

Gruss Helmut