Raspberry Image Version 2.2 mit SmarthomeNG 1.5.1

[Onkelandy]

Kannst dich damit auch auf die Suche nach Dateien machen, die über 50MB sind:

find / -type f -size +50000k -exec ls -lha {} \; 2>&1 | awk '{ print $9 ": " $5 }'

[bmx]

Schau mal mit

sudo du / -t100000000

was sich da so an Verzeichnissen ergibt ...

[Bit-te]

Da gibts nur 71.000 Bytes (2 Dateien: eine aktuelle smarthome.log und eine ältere mit Zeitstempel. In dem Data Verzeichnis ist nichts drin)

Da hatte ich schon geschaut...

Trotzdem Danke

smarthome@raspberrypi:~$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 1851784 1728032 6596 100% /
devtmpfs 437056 0 437056 0% /dev
tmpfs 441388 0 441388 0% /dev/shm
tmpfs 441388 11692 429696 3% /run
tmpfs 5120 4 5116 1% /run/lock
tmpfs 441388 0 441388 0% /sys/fs/cgroup
/dev/mmcblk0p1 64456 21400 43056 34% /boot
smarthome@raspberrypi:~$

[Onkelandy]

smarthome Logs sind im smarthome-Verzeichnis unter var/log
Ansonsten mal unter /var/log gucken, was sich da so angesammelt hat.

[Bit-te]

Hallo,

ich hätte da mal wieder eine Frage.

Meine 4GB Speicherkarte ist seit dem Wochenende voll.
Könnte mir bitte jemand sagen, an welcher Stelle ich gucken muß, wo die voll gelaufen sein könnte? Das können ja fast nur Log oder Cache Dateien sein.
Ich kann diese aber nicht finden. Zumindest nicht die Vielzahl die zum Vollaufen meiner SD-Karte führt.

Ich kenne nur die Stelle für die Smartvisu: Smartvisu/temp

Schreibt Smarthome Logs? Das müssen ja schon mehrere GB sein.

Wäre nett wenn mir jemand nen Tipp geben könnte.

Vielen Dank

Gruß
Wolfgang

[Smurf]

Ich kann auch länger warten Hatte jetzt übrigens grad ziemliche Probleme mit dem Update auf 0.12.1 von 0.10.0, was die Config anging..

KNXD_OPTS="-e 1.1.60 -E 1.1.60:10 -i -B single -b ipt:10.0.0.101 -c"

scheint jetzt zu klappen.

Dazu steht was im README … ich habe das gerade ein wenig erweitert.

Achtung: das "-i" ist nicht immer eine gute Idee. Auf Systemen unter systemd macht der das für dich.
Ich werde dazu aber noch einen Workaround einbauen, denn das Problem kocht mir zu oft hoch. :-/

Das -u /tmp/eib sollte man unter Jessie nicht mehr verwenden, ja?

Korrekt. Der Default ist

/run/knx

. Das in /tmp zu parken war noch nie eine gute Idee.

[Onkelandy]

Ich kann auch länger warten Hatte jetzt übrigens grad ziemliche Probleme mit dem Update auf 0.12.1 von 0.10.0, was die Config anging..

KNXD_OPTS="-e 1.1.60 -E 1.1.60:10 -i -B single -b ipt:10.0.0.101 -c"

scheint jetzt zu klappen. Das -u /tmp/eib sollte man unter Jessie nicht mehr verwenden, ja?

[Smurf]

So prinzipiell. Ich habe noch zwei Bugs, denen ich nachlaufen mag. Kannst du bis zum Wochenende und der 0.12.2 warten?

[Onkelandy]

Heißt, ich könnte noch die Version 0.12.1 in das neue Image einpflegen? Danach würd ich das mit dem Image auch sein lassen, ich denke, soweit funktioniert sonst alles gut genug, und etwaige Updates kann dann eh jeder selbst machen.

[Smurf]

Kannst du mir bzw. uns bitte mitteilen, was der knxd anmeckert, wenn er "nicht startet"? Deine "aktuelle" Befehlszeile sieht vernünftig aus. Wenn er wirklich wegen dem "-u /tmp/eib" nicht startet, dann schau nach ob noch ein knxd oder eibd läuft (und bring ihn um), und ansonsten lösche diese Datei einfach.

Zum Verständnis, warum deine anderen Befehlszeilen nicht funktionieren:

-t -u/tmp/eib

ist Unsinn, hinter das -t muss eine Zahl.

-b -D

ist auch sinnfrei, hinter dem -b kommt der Treiber, also bei dir tpuarts:XXX.

--no-tunnel-client-queuing

verstehe ich nicht – im knxd läuft doch gar keinen Tunnel-Client (das wäre

-b ipt:XXX

) – der knxd weigert sich, Optionen zu akzeptieren, die er nicht verarbeiten kann. Die werden im Übrigen der Reihe nach abgearbeitet, d.h. eine Option, die einen Treiber modifiziert, muss man vor diesem angeben.

PS: Im aktuellen master-Zweig will der knxd noch eine Option "-E 1.1.240:14" o.Ä. haben, um seinen Klienten dynamisch Adressen zuweisen zu können.

Onkelandy
ich habe ziemlich viel mit den Parameter-Kombinationen rumprobiert. Reihenfolgend geändert.
Auch dein Hinweis mit -u/tmp/eib.... habe ich probiert. Dann startet der Service nicht.

START_KNXD=YES #-Testkonfig-KNXD_OPTS="-e 1.1.254 -DTRS -t 0xffc -i -c tpuarts:/dev/ttyKNX1"
#KNXD_OPTS="-e 1.1.254 -DTRS -t -u/tmp/eib --no-tunnel-client-queuing 0xffc -c -f 9 -b tpuarts:/dev/ttyKNX1"
#KNXD_OPTS="-e 1.1.254 -u/tmp/eib -c --no-tunnel-client-queuing -b -D -T -R -S"
KNXD_OPTS="-e 1.1.254 -DTRS -t 0xffc -c -f 9 -b tpuarts:/dev/ttyKNX1"
#KNXD_OPTS="-DTRS -t 0xffc -f 9 -b ft12:/dev/ttyKNX1"

Ich versuche mal den EIBD zu installieren. Denke das ist am Erfolgsversprechenden.

Vielen Dank

Die aktuelle Version (0.12.1) habe ich mit ETS5 und der Programmierung diverser "komplizierter" Busgeräte getestet und keine Regression gegenüber eibd mehr gefunden.

[Max2612]

Hallo,

Super, danke!!

Nach

[LIST][*]export LC_ALL=de_DE.utf8[*]export LANGUAGE=de_DE.utf8[/LIST]

ergibt jetzt

 
 python3 -c "import sys;print(sys.stdout.encoding)"

ein

UTF-8

Gruß, Max

[Onkelandy]

Was passiert, wenn du mal das hier machst:

• export LC_ALL=de_DE.utf8
• export LANGUAGE=de_DE.utf8

Seh grad im Image-Wiki, dass diese 2 Commands noch nicht im aktuellen Image sind.

[Max2612]

Hallo!

Also, wie gesagt, Image 1.3 neu installiert.

python3 -c "import sys;print(sys.stdout.encoding)"

ergibt

ANSI_X3.4-1968

Gruß, Max

[Max2612]

Hmmmm, ich hab bei mir auf mehreren Raspis quasi das 1.3 Image am Laufen. Immer up to date halt, aber sonst nicht wirklich was geändert. Bei beiden Raspis kommt beim obigen Befehl ein UTF-8 retour, egal unter welchem Account. Welche Imageversion hast du denn?

Ich hab heute das Image neu installiert.(1.3)
Ich werde das morgen, wenn ich zuhause bin, nochmal testen.

Gruß, Max

[pfischi]

Ich frage mal beim Nutzer nach.

Danke für den Test.