PCHK 3.0 auf Raspberry

[Uwe]

Moin Moin,
ich fange einfach noch mal ein neues Thema an ...
Mir fehlt da noch ein wenig Verständnis - prinzipiell habe ich von Linux mal nur so viel Ahnung wie ich in den letzten Jahren 'learning by doing' für die Installation gebraucht habe.

Mittlerweile laufen auch bei mir die Installationsskripte der PCHK klaglos, aber ...
Spätenstens nach einem Stromausfall (also GAU-reboot) verbindet sich dann die PCHK(3.0) nicht mehr mit dem LCN. Der Dienst läuft (laut Statusmeldung), aber es kommen keine Daten mehr vom Bus.
Man 'fummelt' dann ein wenig, kopiert mal die xml in andere Verzeichnisse etc., reboot, restart ... - und irgendwann geht es (aber warum?).
Ich habe dann in die verschiedenen xml einfach mal unterschiedliche Host-ID eingetragen, um im Bus-Monitor auf dem WIN-PC erkennen zu können, welche nun genutzt wurde. Da kam dann auch eine andere ID, nur leider keine von den von mir vergebenen. Wie kann das sein?
Nachdem ich ähnliche Ergebnisse nun auch schon von anderen Kollegen gehört habe, muss ich doch hier noch mal nach einer Erklärung fragen.

Für mich fraglich ist auch: welche Verzeichnisse auf dem Raspberry werden für welche Dateien genutzt - einfach mal ausgehend vom aktuellen BS (bie mir i.d.R. ein Raspbian-lite, also Debian).
Da verteilt sich doch so einiges an lcn... in den Dateistrukturen, was bei einer Deinstallation auch nicht unbedingt alles entfernt wird.

Wie oben schon gesagt - ich bringe es zum laufen, aber ich würde auch gerne wissen wollen wie/warum.

Bei anderen Diensten und Programmen habe ich mit dem typischen 'apt-get install xxx' überhaupt keine Probleme. Warum wird diese Art der Installation nicht auch für die PCHK genutzt?

Ich freue mich auf etwas Erklärung
Danke und Grüße, Uwe

[Software-MP]

Hallo,

wir sind an dem Thema dran.

Im Moment scheint etwas mit dem init-Skript, welches den Service beim Reboot des Pis startet, nicht zu stimmen. Wenn man nach einem Reboot allerdings den Service einmal von Hand neustartet (sudo service lcnpchk restart) funktioniert bei uns alles wieder. Es wäre super wenn Sie das bei Gelegenheit mal testen könnten und hier oder der Hotline Bescheid geben könnten.

Wenn der PCHK keine config-xml findet oder diese nicht laden kann (weil evtl. die Struktur derart verändert wurde, dass sie nicht mehr erkannt wird), wird eine neue mit der Standardkonfiguration angelegt. Das könnte ihr Problem mit den Host-IDs erklären.

Zu ihrer anderen Frage:
Wenn man sich die Installationsskripte anschaut, wird klar, dass lediglich 4 Ordner verwendet werden.
Diese sind:

/var/lib/lcnpchk -> hier liegt die xml-Datei mit den Konfigurationen und auch nur von hier wird diese geladen (es sei denn das init-Skript wurde von Ihnen verändert)

/var/log/lcnpchk -> wie der Name schon sagt, liegen hier die log-Files des PCHK. Diese beiden Ordner werden bei einer Deinstallation auch nicht gelöscht, da bei einer Neuinstallation die alten Daten/Konfigurationen wieder genutzt werden können. Aus diesem Grund muss auch das config-Skript nicht nocheinmal ausgeführt werden.

/usr/bin -> hier liegt die ausführbare Datei lcnpchk, sprich das Äquivalent zur exe unter Windows.

/usr/share/lcnpchk -> hier befinden sich die Sprachpakete für den PCHK

Neben diesen Ordnern wird außerdem eine udev-Rule angelegt, welche dem PCHK sagt, dass die PKU immer an USB0 angeschlossen ist.

Den PCHK in die Debian Pakete zu integrieren (um sie mit apt-get zu installieren) würde einerseits einen deutlichen Mehraufwand bedeuten und darüber hinaus müssten wir den Quellcode öffentlich verfügbar machen. Da wir Entwickler allerdings auch bezahlt werden wollen, wäre das keine gute Idee

Viele Grüße aus der Entwicklungsabteilung

[Uwe]

Wenn man nach einem Reboot allerdings den Service einmal von Hand neustartet (sudo service lcnpchk restart) funktioniert bei uns alles wieder.

Alles klar, das erklärt, warum es bei mir recht gut funktioniert. Diesen Aufruf löse ich mit etwas Verzögerung über ein Start-Skript der von mir genutzten Symcon-Software aus. Es geht   Grüße, Uwe

[Software-MP]

Hallo,

es gibt jetzt eine neue Version der PCHK die fehlerfrei laufen sollte (kein manueller restart mehr nötig). Wir haben es auf jeden Fall mehrfach mit dem aktuellen Pi3 und Raspian Jessie sowie Jessie Light getestet.

Achtung bei Jessie Light muss vorher über sudo apt-get install wiringpi, die lib nachinstalliert werden.

Die Schritte stehen alle in der im Paket enthaltenen README.

Grüße aus der Entwicklung

[Uwe]

Moin Moin,
einen dicken Dank an die Entwicklung
Ich bin gespannt, wann sich der erste Bug findet. Eine Software ohne Fehler gibt es doch eigentlich nicht :thumbsup: 8o

Auch bei mir funktioniert das bislang klaglos.
Ich habe da übrigens von PI1 bis zu den aktuellen 3ern einige verschiedene Versionen von Hardware am werkeln. Bei mir meldet sich die PCHK auf allen Geräten, die ich bislang probiert habe, mit V3.22.
Ich hätte aber doch mal eine Frage an die Linux-Spezialisten (das bin ich nun wirklich nicht).
Beim 'copy'-upgrade auf den älteren Systemen bekomme ich einen restart der PCHK nach wie vor nur mit dem "alten" Kommando [sudo /etc/init.d/pchk restart] ausgelöst.
In welcher Datei müsste ich dort Änderungen vornehmen, damit auch [sudo service lcnpchk restart] gehen würde?

Grüße, Uwe - der eigentlich nur zu faul zum 'uninstall' ist ^^

[mkc]

Hallo,
der Start von Diensten unter Linux und der dazugehörigen Kommandos hängt von der verwendeteten Distribution und deren init System ab.
Das ältestete unter ihnen ist sysvinit (Syntax: /etc/init.d/[DAEMON] start|stop|restart) und wurde von fast allen Debian basierten Distributionen verwendet bis Debian Jessie. Parallel dazu verwendete Ubuntu i.d.R. upstart (z.B: service [DAEMON] start|stop|restart), ist aber seit geraumer Zeit (Wily Werewolf) auf systemd umgestiegen (Syntax: systemctl start|stop|restart [DAEMON]), bei Debian ist das der Standard seit Jessie.

Eine einmal installierte Distribution ändert i.d.R. das installierte init System nicht mehr. Theoretisch geht das und einige Installer bieten sowas an aber zu empfehlen ist es nicht unbedingt, da die Installation dadurch instabil werden könnte. Wer also mit mehreren Version verschiedener (älterer) Distributionen arbeitet muß die entsprechenden Kommandos dazu kennen. Das hat für einige Unübersichtlichkeit gesorgt aber systemd zeichnet sich hier als der neue Defakto-Standard ab denn nahezu alle großen Distris sind auf dieses init System umgestiegen oder werden es noch tun.
Auch Raspbian verwendet seit V2 systemd, um also nicht unnötig viele Kommandokombinationen auswendig zu lernen sollte man sich am besten gleich auf systemd einstellen und das verwenden wenn möglich.

[Uwe]

Moin Moin,
danke für die super Erklärung - so verstehe selbst ich die Zusammenhänge
Damit kann ich leben ... 8o

Und dann liegt mir noch am Herzen allen Beteiligten an der heutigen Serviceaktion noch mal öffentlich zu danken. Das hatte für mich einfach einen riesigen Spaßfaktor mit dem Ergebnis "... es geht" :thumbsup:

Grüße, Uwe