Landis Gyr e350 LBS Baustein

[Robby]

Habe auch den Volkszähler Lesekopf,siehe auch diesen Post https://knx-user-forum.de/forum/proj...025#post997025

Nach einem Update muss ich immer die ganze Prozedur neu machen...scheinbar überschreibt er die intakte Datei wieder mit der defekten.

Gerade also nochmal gemacht wie immer. Bei mir heißt der Lesekopf nur lesekopf0. Ein bloßes Austaschen der Datei bewirkt bei mir keine Anzeige. Die Befehle muss ich schon über putty eingeben.


8.png

[starwarsfan]

Hallo und guten Abend

Nach einem Update muss ich immer die ganze Prozedur neu machen...scheinbar überschreibt er die intakte Datei wieder mit der defekten.

Nach einem Update wovon genau?

Gerade also nochmal gemacht wie immer. Bei mir heißt der Lesekopf nur lesekopf0. Ein bloßes Austaschen der Datei bewirkt bei mir keine Anzeige.

Joa, das ist mir schon klar. Wird die Maschine ohne angesteckten Reader gebootet, ist das Kernel-Modul i.d.R. noch nicht geladen. Steckt man nun den Reader an, wird das Modul geladen und man kann das entsprechende Device im Normalfall "sehen" (/dev/ttyUSB0) und ansprechen. Deshalb muss man laut der Doku das "alte" Modul mit rmmod erst entfernen und mit insmod das neue Modul laden, sofern der Reader eben schon angesteckt war/ist.

Die Befehle muss ich schon über putty eingeben.

Wie oben schon gesagt: Wann genau musst Du das immer wieder machen? Nach einem Edomi-Update? Da Edomi diese Sachen definitiv nicht anfasst würde das bedeuten, dass der Change einen Reboot nicht übersteht. Ist das auch der Fall, wenn Du Edomi ohne Update neu startest?

[Robby]

Gerade mal ausprobiert. Wenn ich den Server neu starte dann überleben das die Einstellungen das nicht. Ist mir natürlich nur bei den Updates aufgefallen.

[jonofe]

Sowas kann man mit einer udev rule lösen. Man kann damit z.B. beim Anstecken eines USB Devices automatisiert ein Skript ausführen. Das funktioniert auch beim Reboot, wenn das Gerät schon dranhängt.

Schau mal ==> HIER

[hartmut]

Zu spät ...
Würde da nicht ein Eintrag in /etc/rules helfen? Siehe
http://wiki.ubuntuusers.de/udev#udev...-und-speichern

suchen mit: udevadm info --query=all --attribute-walk --name=/dev/ttyUSB0

Dann einen Eintrag machen /etc/udev/rules.d/99-sma-loggerd.rules
KERNEL=="ttyUSB?", SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A602UGMD", SYMLINK+="sma_logger"

Dann ist der Adapter immer unter /dev/sma_logger zu finden.

So geht es mit meinem Debian Server (Raspberry).

[starwarsfan]

Schön und gut. Ihr habt aber schon mitbekommen, dass es hier um ein ganz anderes Problem geht als dem Gerät bei jedem Boot den gleichen Namen zu geben?

[jonofe]

Schön und gut. Ihr habt aber schon mitbekommen, dass es hier um ein ganz anderes Problem geht als dem Gerät bei jedem Boot den gleichen Namen zu geben?

Du hast aber schon mitbekommen, dass ich schrieb "automatisiert Skript ausführen". Einfach mal auf den Link klicken und die ersten beiden Suchergebnisse durchlesen.

 
 ATTRS{idVendor}=="152d", ATTRS{idProduct}=="2329", RUN+="/pathto/script.sh"

[starwarsfan]

Hi André,

ja das mit Script via udev-Rule ausführen ist mir schon klar. Mich wundert viel mehr, dass nach einem Reboot das falsche Kernel-Modul geladen wird, obwohl /lib/modules/2.6.32-431.el6.x86_64/kernel/drivers/usb/serial/cp210x.ko das aktuelle Modul ist!? Woher kommt dann das alte Modul? Steckt das noch irgendwo anders? Ich war eigentlich der Annahme, wenn man ein Modul auf der Platte austauscht, dass ich dann nichts mehr zusätzlich machen muss.

Aber ok, ich werd's ausprobieren...

[jonofe]

Das liegt vermutlich am initrd filesystem, welches beim Booten als ramdisk filesystem verwendet wird und in dem Kernelmodule enthalten sind, die beim Booten vor Einhängen des root Filesystems benötigt werden. Darin ist vermutlich auch das von euch verwendete Kernel Module enthalten.

Ich gehe somit davon aus, dass in /lib/modules-... nach wie vor das richtige neue Modul liegt. Aber es wird nicht verwendet, da es bereits beim Booten geladen wird, bevor das Root Filesystem überhaupt gemountet ist.

Man müsste also nach dem Kopieren des neuen Kernel Moduls die initrd-Datei neu bauen, die im Verzeichnmis /boot liegt.

Dazu einfach mal

depmod -a
cp /boot/initrd-$(uname -r).img /boot/initrd-$(uname -r).img.bak
mkinitrd -f -v /boot/initrd-$(uname -r).img $(uname -r)

eingeben. Danach gibt es dann ein neues initrd File im Verzeichnis /boot/, welches dann hoffentlich das neue Kernelmodul enthält. Nach einem weiteren Booten sollte es dann eigentlich funktionieren.

Auf meinem EDOMI-Staging-System (Vanilla EDOMI), hat der o.g. Befehl ein neues initrd File erzeugt und danach auch problem los gebootet.

Damit wäre dann das Thema udev unnötig.

EDIT: Habe gerade mal die Ausgabe des mkinitrd gescannt. Bei mir taucht das Modul cp210x.ko nicht auf.

[panzaeron]

Hmm, meine beiden IR-Schreib-Leseköpfe von Udo arbeiten noch mit einem FT232 von ftdi, da gab es wohl eine Änderung. Wenn eure Treiber funktionieren, funktioniert dann auch der angepasste LBS von mir?

[starwarsfan]

Hallo miteinander

Das liegt vermutlich am initrd filesystem, welches beim Booten als ramdisk filesystem verwendet wird und in dem Kernelmodule enthalten sind, die beim Booten vor Einhängen des root Filesystems benötigt werden.

OK klar, das erscheint logisch. Werde das mit dem Rebuild der InitRD heute Abend testen, danke für den Tipp!

Hmm, meine beiden IR-Schreib-Leseköpfe von Udo arbeiten noch mit einem FT232 von ftdi, da gab es wohl eine Änderung. Wenn eure Treiber funktionieren, funktioniert dann auch der angepasste LBS von mir?

Ich verwende im Moment meinen eigenen LBS, welcher die Abfrage mit einem Shell-Script erledigt, welches auf einer anderen Maschine unter CentOS7 ausgeführt wird. Aber wenn das mit dem Rebuild der InitRD geklappt hat, kann ich gern mal mit Deinem Baustein testen.

[starwarsfan]

N'abend @all,

leider ist es mir nicht gelungen, eine neue InitRD mit dem funktionierenden cp210x.ko zu erstellen. Habe das sowohl nach den oben genannten Befehlen versucht als auch /boot/initramfs-2.6.32-431.el6.x86_64.img auszupacken, das Modul einzutragen, modules.alias und modules.dep anzupassen und die InitRD wieder zu erstellen. Der Fehler bleibt nach wie vor unverändert.

[jonofe]

das ist echt seltsam. Das ersetzte kernel module bleibt aber erhalten, oder? oder wird es überschrieben?

[starwarsfan]

Das Modul cp210x.ko ist in der InitRD von Haus aus gar nicht drin. Ich habs aus diesem Grund mal explizit dazugepackt und wie gesagt modules.alias und modules.dep angepasst. Irgendwie habe ich die Vermutung, dass da ein ganz anderes Modul angezogen wird, wenn der Reader erkannt wird. Was meinst Du, ist das möglich? Und ja, das ersetzte Modul bleibt erhalten.

[jonofe]

was sagt denn "lsmod" wenn der Server hochgefahren ist? ist dann das Modul geladen?