Autostart von EIBD auf Raspi2

[speedschmidt]

high,

mein fehler:
4. mit dpkg-buildpackage -b die Pakete installiert
habe ich eben nicht gemacht

ingo

[speedschmidt]

high,

mein fehler:
4. mit dpkg-buildpackage -b die Pakete installiert
habe ich eben nicht gemacht

ingo

ich hatte das mal weiter vorne gemacht, vor git pull, und dachte das hätte ich nach git pull gemacht.

aber jetzt auch nach neuinstallation geht kein groupswrite mehr

Code Auswählen Erweitern


pi@raspberrypi ~ $ sudo knxtool groupswrite ip: 0/2/9 0
Open failed: Invalid argument
pi@raspberrypi ~ $


ich mache mir jetzt erstmal ein kaltes Bier auf - prost.

Ingo

[speedschmidt]

high

nein (k)altes Bier hilft auch nicht ABER:

Code Auswählen Erweitern


sudo apt-get update
sudo apt-get upgrade


Code Auswählen Erweitern


knxtool groupswrite ip: 0/2/9 0


funzt zwar nicht, dafür läuft fhem aber wieder (das lief nämlich auch nicht mehr)und lässt sich bedienen und das

OHNE EIBD (sagt pstree)

Verstehe ich zwar überhaupt nicht, ich dachte immer die Grundlage für fhem wäre auch irgendwie groupswrite, aber BITTE KLÄRT MICH AUF.

Ingo (der - gefühlt - den ersten RPI2 ohne EIBD am Laufen hat - oder gibt's noch wen?)

Danke nochmal an die tatkräftige Unterstützung von smurfi, auch wenn ich glaube das wir noch nicht am ende sind, aber den anfang hätten wir. ich bleib dabei.

[smurfix]

Kannst du mir mal verraten, wieso du immer noch einem "eibd" suchst? Der heißt jetzt knxd!

NB: Auch der knxd läuft nach dem Start des Rechners nicht, funktioniert aber trotzdem. Diese Automagie nennt sich "socket activation".

Was heißt "groupswrite funktioniert nicht"? Welche Befehlszeile liefert welches Resultat? Muss ich das auch nächstes Jahr noch jedes Mal fragen, oder lernst du irgendwann, solche Infos gleich dazuzuschreiben?   

[speedschmidt]

high smurfi

Was heißt "groupswrite funktioniert nicht"? Welche Befehlszeile liefert welches Resultat? Muss ich das auch nächstes Jahr noch jedes Mal fragen, oder lernst du irgendwann, solche Infos gleich dazuzuschreiben?   

nein musst du nicht, habe ich schon (vor langer, langer Zeit ) kappiert und weiter oben geschrieben (eingegebener Befehl und die Ausgabe die daraus folgte):

Code Auswählen Erweitern


pi@raspberrypi ~ $ sudo knxtool groupswrite ip: 0/2/9 0
Open failed: Invalid argument
pi@raspberrypi ~ $


vielleicht vergesse ich es das eine oder andere mal - ich gelobe diesbezüglich Besserung.

Kannst du mir mal verraten, wieso du immer noch einem "eibd" suchst? Der heißt jetzt knxd!

NB: Auch der knxd läuft nach dem Start des Rechners nicht, funktioniert aber trotzdem. Diese Automagie nennt sich "socket activation".

Nein ich suche/benötige nicht eibd, aber ich war mir nicht mehr bewusst, ob ich bei der Original-SD-Karte (auf der ich aktuell arbeite) eibd schon installiert oder nach einer Installation wieder deinstalliert hatte und hatte deswegen zu Beginn meiner Tätigkeiten auf der Original-SD-Karte (auf der ich schon zwei Wochen nicht mehr unterwegs bin) den eibd schon gesucht um diesen dann bedarfsweise zu deinstallieren. Es hat sich aber herausgestellt, dass dort der eibd noch nicht oder nicht mehr installiert war.

ergänzende Begriffserklärung:
Original-SD-Karte = SD-Karte mit der ich die fhem- und eibd - Installationen auf dem RPi2 begonnen hatte und fhem schon zu einem kleinen Teil konfiguriert ist, weil ja eibd dort mal lief (nur manueller Start und damit die Basis für diesen Threat).
Test-SD-Karte = eine "nackte" Betriebssystemumgebung die sich von der Original-SD-Karte nur dadurch unterscheidet, dass kein fhem installiert ist. Hier wollte ich knxd eigentlich nur soweit bringen, dass es nach einem Systemstart nicht manuell gestartet werden muss und man groupswrite ausführen kann, da ich der Meinung war (bin aktuell schlauer), dass dies die Basis für fhem ist.

Ingo

[smurfix]

Code Auswählen Erweitern

pi@raspberrypi ~ $ sudo knxtool groupswrite ip: 0/2/9 0
Open failed: Invalid argument

Lass das "sudo" weg, das braucht kein Mensch.

Mach mal "strace -s300 -o/tmp/gw.log knxtool groupswrite ..." und schick mir diese Datei.

[speedschmidt]

voula, einmal Datei gw.log zur Fehlersuche

ingo

[smurfix]

voula

Das heißt "voilà". 

Ertappt:

Code Auswählen Erweitern

execve("/usr/local/bin/knxtool" ...
knxtool ist in /usr/bin. Du hast in /usr/local noch Reste deiner Altinstallation rumliegen.

[speedschmidt]

Das heißt "voilà". 

Ertappt:

Code Auswählen Erweitern

execve("/usr/local/bin/knxtool" ...
knxtool ist in /usr/bin. Du hast in /usr/local noch Reste deiner Altinstallation rumliegen.

wow wieder was gelernt (das man hier auch auf französische Rechtschreibung Wert legt). kann ich die Reste einfach löschen, oder gibt es einen richtigen weg um die Reste zu deinstallieren, den ich noch nicht kenne?

Wie ist denn grundsätzlich der richtige Weg, um eine über github gepflegte software zu aktualisieren? welche befehle muss ich eingeben, damit ich SAUBER aktualisiere. es ist ja nicht so, dass das hier so noch nicht geschafft habe(immerhin arbeite ich seit der Version 0.9.XX-X hier daran), aber wohl offensichtlich nicht RESTlos sauber. Ich kann mich auch noch gut an meine dort gemachten Fehler erinnern (alte Paketdateien nicht gelöscht etc.). War das grundsätzlich richtig angeleitet (von smurfi) und schlecht ausgeführt von mir?

Ingo

[smurfix]

Grundsätzlich sagt dir

Code Auswählen Erweitern

dpkg -S /usr/local/bin/knxtool
mit welchem debian-Paket diese Datei installiert wurde. Wenn du mir das mitteilst, nehme ich das auf und die Deinstallation geschieht automatisch, wenn du knxd-tools installierst.

Grundsätzlich² untersteht /usr/local aber der Ägide des lokalen Benutzers, d.h. die Daten da drin sind im Normalfall eben nicht mit dpkg installiert, sondern "irgendwie anders".
Dagegen hilft nicht viel, außer eben von Hand aufzuräumen. Alternativ kann man /usr/local/bin nach /usr/bin in den Pfad zu nehmen statt davor; das steht irgendwo in den Shell-Startupskripts ("man bash" sagt dir mehr über das Ding, als du dir jemals merken kannst).

[speedschmidt]

high,

ich hätte dir gern mehr geschickt, aber mehr ist nicht 

Code Auswählen Erweitern


pi@raspberrypi ~ $ sudo dpkg -S /usr/local/bin/knxtool
dpkg-query: Kein Pfad gefunden, der auf Muster /usr/local/bin/knxtool passt
pi@raspberrypi ~ $


Grundsätzlich sagt dir

Code Auswählen Erweitern

dpkg -S /usr/local/bin/knxtool
mit welchem debian-Paket diese Datei installiert wurde. Wenn du mir das mitteilst, nehme ich das auf und die Deinstallation geschieht automatisch, wenn du knxd-tools installierst.

Grundsätzlich² untersteht /usr/local aber der Ägide des lokalen Benutzers, d.h. die Daten da drin sind im Normalfall eben nicht mit dpkg installiert, sondern "irgendwie anders".
Dagegen hilft nicht viel, außer eben von Hand aufzuräumen. Alternativ kann man /usr/local/bin nach /usr/bin in den Pfad zu nehmen statt davor; das steht irgendwo in den Shell-Startupskripts ("man bash" sagt dir mehr über das Ding, als du dir jemals merken kannst).

ja hat das vielleicht make, make install von bcusdk da reininstalliert? nein knxtool wird nicht von bcusdk installiert, nicht von make oder dpkg oder sonstwie. hier mal der Inhalt des Ordners:

Code Auswählen Erweitern


pi@raspberrypi /usr/local/bin $ dir
bcuaddrtab             grouplisten        mmaskver         mwriteplain
bcuread                groupread          mpeitype         progmodeoff
busmonitor1            groupreadresponse  mprogmodeoff     progmodeon
busmonitor2            groupresponse      mprogmodeon      progmodestatus
eibd                   groupsocketlisten  mprogmodestatus  progmodetoggle
eibnetdescribe         groupsocketread    mprogmodetoggle  pthsem-config
eibnetsearch           groupsocketswrite  mpropdesc        readindividual
findknxusb             groupsocketwrite   mpropread        vbusmonitor1
groupcacheclear        groupsresponse     mpropscan        vbusmonitor1poll
groupcachedisable      groupswrite        mpropscanpoll    vbusmonitor2
groupcacheenable       groupwrite         mpropwrite       writeaddress
groupcachelastupdates  indiecity          mread            xpropread
groupcacheread         knxtool            mrestart         xpropwrite
groupcachereadsync     madcread           msetkey
groupcacheremove       maskver            mwrite
pi@raspberrypi /usr/local/bin $

Moment mal mit:

Code Auswählen Erweitern


dpkg -S /usr/local/bin/groupswrite

kriegen wir doch raus wer groupswrite da installiert hat:

Code Auswählen Erweitern


pi@raspberrypi /usr/local/bin $ sudo dpkg -S /usr/local/bin/groupswrite
dpkg-query: Kein Pfad gefunden, der auf Muster /usr/local/bin/groupswrite passt
pi@raspberrypi /usr/local/bin $

nein doch nicht

weitere Ideen?

Ingo

[smurfix]

ja hat das vielleicht make, make install von bcusdk da reininstalliert?

Da kann ich dir leider auch nicht weiterhelfen. War auf jeden Fall irgendwas, das auch den eibd da hininstalliert hat.

Einfach weg damit und gut is':

Code Auswählen Erweitern

$ cd /usr/local/bin
$ sudo rm [b-gk-oq-x]* pr*


[speedschmidt]

high smurfi,

Befehl ausgeführt:

Code Auswählen Erweitern


pi@raspberrypi ~ $ cd /usr/local/bin
pi@raspberrypi /usr/local/bin $ sudo rm [b-gk-oq-x]* pr*
pi@raspberrypi /usr/local/bin $ dir
indiecity  pthsem-config


Ausgabe mit groupswrite:

Code Auswählen Erweitern


pi@raspberrypi ~ $ knxtool grouswrite ip: 0/2/9 1
No such applet: grouswrite: No such file or directory


Sorry ich hätte gern bessere Nachrichten

Ingo

[smurfix]

Sorry ich hätte gern bessere Nachrichten

Dann schau mal genau hin.

Ich schenke dir ein "p".

[speedschmidt]

High 

Dann schau mal genau hin.

Ich schenke dir ein "p".

Danke , danke, danke hat auch sehr geholfen: 

Code Auswählen Erweitern


pi@raspberrypi ~ $ knxtool groupswrite ip: 0/2/9 1
Open failed: Connection refused
pi@raspberrypi ~ $ knxtool groupswrite ip:localhost 0/2/9 1
Send request
pi@raspberrypi ~ $ knxtool groupswrite ip:localhost 0/2/9 0
Send request
pi@raspberrypi ~ $ knxtool groupswrite ip:localhost 0/2/9 1
Send request
pi@raspberrypi ~ $

Licht geht an und aus und wieder an. Wobei ich dich weiter oben, so verstanden hatte, dass man localhost(127.0.0.1) weglassen kann. Habe ich das falsch verstanden?

Ingo