Hallo,
ich hatte FHEM längere Zeit unter Jessie laufen und habe vor einiger Zeit ein update auf Stretch gemacht. Wie ich nun festgestellt habe, ist eine update des OS nicht sehr sinnvoll. Es sind immer noch viele Dinge von Jessie auf dem System geblieben. Zudem funktionieren einige Dinge nicht mehr.
Daher habe ich mich entschieden, das System kompl. neu aufzusetzen.
Ich habe neben FHEM noch Kodi auf dem Rechner. FHEM ist noch iim Auslieferungszustand. Bevor ich mein FHEM-update installiere, möchte ich zunächst meinen Homematic USB-Konfigurationsadapter einrichten. Ich bin (so glaube ich) genau so vorgegangen, wie bei meiner ursprünglichen Installation (gem. FHEMWIKI).
cd /opt/
apt-get install build-essential libusb-1.0-0-dev make gcc git-core
git clone git://git.zerfleddert.de/hmcfgusb
cd hmcfgusb
make
Weiterhin bin ich vorgegangen, wie von Betateilchen in FHEMWIKI vorgeschlagen.
sudo cp hmcfgusb.rules /etc/udev/rules.d/
Die Startdatei unter init.d habe ich geändert, so dass mit FHEM auch der USB-Adapterdienst startet. Doch der Dienst startet nicht. Weder manuell noch automatisch. Ich finde meinen Fehler nicht.
Erkennt jemand wo ich einen Fehler gemacht habe?
Gruß
Apollon
Gibt es irgendwelche Ausgaben, wenn Du hmland -D -v -p 1234 eingibst?
Wie rufst du hmland im init-Script auf?
Hallo,
ich habe gerade keinen Zugriff auf das System. Werde ich erst heute Nachmittag ausprobieren können.
Ja, ich habe es auch mit hmland -D -v -p 1234 probiert. Es kommt dann eine Authentifizierungsabfrage (pi oder root). Die Rückmeldungen habe ich nicht mehr im Kopf. Ich liefere sie heute Nachmittag.
In fhem unter init.d habe ich aus der Standarddatei die Kommentierung entfernt. So ist es auch in meinem alten System, bei dem es funktioniert.
Gruß
Apollon
unter jessie hat bei mir irgendwann systemd das starten der dienste übernommen. im forum gibt es beispiele dazu.
@frank
Das Problem ist wohl nicht der Autostart, sondern der Start des Dienstes von hmland im allgemeinen.
systemctl/ systemd ist doch nur eine andere Variante des Autostarts. Da FHEM immer noch über init.d gestartet wird, kann doch auch hmland darüber gestartet werden.
Korrigiere mich, wenn ich falsch liege.
Zitat von: Apollon am 13 Dezember 2017, 11:52:54
@frank
Das Problem ist wohl nicht der Autostart, sondern der Start des Dienstes von hmland im allgemeinen.
systemctl/ systemd ist doch nur eine andere Variante des Autostarts. Da FHEM immer noch über init.d gestartet wird, kann doch auch hmland darüber gestartet werden.
Korrigiere mich, wenn ich falsch liege.
Keine Korrektur notwendig.
Habe mein System mit Stretch neu aufgesetzt und wie im Wiki einfach den Eintrag in der Startdatei von fhem vorgenommen.
Allerdings lief hmland nat. beim manuellen starten...
Bin grad unterwegs und nur Mobil daher kurz und keine genaueren Angaben...
Gruß, Joachim
ich hatte nur den automatischen start im kopf.
gibt es im syslog denn keine hinweise zum manuellen startversuch.
@frank
Welches log meinst du mit syslog?
Ich habe gerade /opt/hmcfgusb/hmland -p 1234 -D eingegen. Folgende Meldung habe ich erhalten:
Can't bind socket: Address already in use
ich würde vermuten, dass der peer 1234 belegt ist und einen anderen versuchen.
Der Port 1234 kann nur vom USB-Adapter belegt sein.
Ich kopiere gerade das letzte funktionierende Image, da ich mit meinen Versuchen gescheitet bin und das System nun durcheinander ist.
Ich verstehe das nicht, als ich den Adapter neu hatte, habe ich keine nennenswerten Probleme ihn einzubinden gehabt.
Ich habe heute noch mehrer Varianten probiert. Die letzte Variante war ein nacktes Stretch.
Zunächst Perl installiert.
Dann:cd /opt
apt-get install build-essential libusb-1.0-0-dev make gcc git-core
git clone git://git.zerfleddert.de/hmcfgusb
Ergebnis: Klone nach 'hmcfgusb' ...
remote: Counting objects: 696, done.
remote: Compressing objects: 100% (673/673), done.
remote: Total 696 (delta 440), reused 0 (delta 0)
Empfange Objekte: 100% (696/696), 150.20 KiB | 0 bytes/s, Fertig.
Löse Unterschiede auf: 100% (440/440), Fertig.
Das Ergebnis von make: gcc -MMD -O2 -Wall -I/opt/local/include -g -c -o hmland.o hmland.c
gcc -MMD -O2 -Wall -I/opt/local/include -g -c -o hmcfgusb.o hmcfgusb.c
gcc -MMD -O2 -Wall -I/opt/local/include -g -c -o util.o util.c
gcc -L/opt/local/lib hmland.o hmcfgusb.o util.o -lusb-1.0 -lrt -o hmland
gcc -MMD -O2 -Wall -I/opt/local/include -g -c -o hmsniff.o hmsniff.c
gcc -MMD -O2 -Wall -I/opt/local/include -g -c -o hmuartlgw.o hmuartlgw.c
gcc -L/opt/local/lib hmsniff.o hmcfgusb.o hmuartlgw.o -lusb-1.0 -lrt -o hmsniff
gcc -MMD -O2 -Wall -I/opt/local/include -g -c -o flash-hmcfgusb.o flash-hmcfgusb.c
gcc -MMD -O2 -Wall -I/opt/local/include -g -c -o firmware.o firmware.c
gcc -L/opt/local/lib flash-hmcfgusb.o hmcfgusb.o firmware.o util.o -lusb-1.0 -lrt -o flash-hmcfgusb
gcc -MMD -O2 -Wall -I/opt/local/include -g -c -o flash-hmmoduart.o flash-hmmoduart.c
gcc -L/opt/local/lib flash-hmmoduart.o hmuartlgw.o firmware.o util.o -lusb-1.0 -lrt -o flash-hmmoduart
gcc -MMD -O2 -Wall -I/opt/local/include -g -c -o flash-ota.o flash-ota.c
gcc -MMD -O2 -Wall -I/opt/local/include -g -c -o culfw.o culfw.c
gcc -MMD -O2 -Wall -I/opt/local/include -g -c -o hm.o hm.c
gcc -MMD -O2 -Wall -I/opt/local/include -g -c -o aes.o aes.c
gcc -L/opt/local/lib flash-ota.o hmcfgusb.o culfw.o hmuartlgw.o firmware.o util.o hm.o aes.o -lusb-1.0 -lrt -o flash-ota
Nach folgenden Befehl passiert nichts:/opt/hmcfgusb/hmland -p 1234 -D
Ein service hmland start führt zu folgenden Ergebnis: Failed to start hmland.service: Unit hmland.service not found.
Ich bin nun endgültig ratlos. Warum läuft der Dienst nicht? Warum fehlt hmland.service?