Hallo zusammen,
ich wollte meinm FHEM Server ein Upgrade auf eine SSD spendieren und bin gerade dabei, FHEM neu aufzusetzen. Dabei verwende ich einen
COC von Busware.de (Firmware: V 1.61 CSM868) (https://wolf-u.li/upload/2013/06/4795-Busware-COC-3.jpg), welcher schon einige Jahre treu seinen Dienst tut.
Leider tue ich mich schwer damit, den COC korrekt einzubinden. Konkret habe ich Probleme mit der seriellen Verbindung. "Damals" bei Raspbian, bin ich nach dieser Anleitung vorgegangen: (https://wiki.fhem.de/wiki/FHEM_auf_Raspberry_PI_mit_COC_betreiben).
Da sich aber mittlerweile viel an Debian geändert habe, kann ich anscheind diese Anleitung nicht mehr verwenden. Zum Beispiel ist "/etc/inittab" komplett leer, sodass ich die serielle Schnittelle also nicht "befreien" konnte. Um es dennoch zu machen bin ich über
- raspi-config
- Interface Options
- Serial
- Would you like a login shell to be accessible over serial? NO
- Would you like the serial port hardware to be enabled? YES
- The serial login shell is disabled / The serial interface is enabled
- reboot
vorgegangen. Das Müsste doch den selben Effekt haben?
Zweites Problem: "
Damit der COC beim Start vom FHEM initialisiert wird, muss die /etc/init.d/fhem editiert werden. Dies machen wir mittels sudo nano /etc/init.d/fhem
und fügen unterhalb von "Start)" folgendes in die Datei ein"
Soweit ich weiß, startet fhem doch mittlerweile als service und die "
/etc/init.d/fhem" existiert nicht mehr. Wie und in welcher Form, soll ich das Script zum initialisieren nun auf dem Raspberry Pi einrichten?
Mein COC Device sieht derzeit wie folgt aus:
Internals:
CMDS
Clients :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF /dev/ttyAMA0@38400 1234
DeviceName /dev/ttyAMA0@38400
FHTID 1234
FUUID 5d75017a-f33f-f7ed-02fe-463b02f58b2fe299
NAME COC
NR 14
STATE opened
TYPE CUL
initString X21
Ar
MatchList:
1:CUL_HM ^A....................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2019-09-08 15:26:52 raw No answer
2019-09-08 15:58:12 state opened
2019-09-08 15:39:49 uptime No answer
2019-09-08 15:26:49 version No answer
Attributes:
rfmode HomeMaticIch würde mich sehr freuen, wenn ihr mich an die richtige Richtung leiten könnten, sodass ich meinen COC wieder in Betrieb nehmen kann.
Gruß,
Phil
Hallo,
Ich habe genau das selbige Problem
herausgefunden habe ich nur:
Zitatgibt es kein Script mehr unter /etc/init.d/ sondern unter /etc/systemd/system (@MadMax-Fhem Danke)
aber da etwas eintragen funktioniert nicht >:(
Bin da auch kein Experte, aber weil sich hier bisher sonst niemand gemeldet hatte:
Das "alte" script ist eigentlich auch nur ein shell-Script, leider kann ich nicht sagen, ob das heute noch so funktioniert und alle Schritte wirklich noch erforderlich sind, das bitte vorab checken!
Wenn ja bzw. klar ist, wie das heute geht, kann man die Schritte dann in eine eigene .sh-File packen. Das dann unter einem geeigneten Namen irgendwo (spontan: unter /opt) abspeichern, ausführbar machen.
Testen (mit den passenden Rechten...) mit "sh <pfad+Dateiname>" , und dann am besten einen eigenen Service dafür anlegen, wie in diesem Beitrag für andere Services auch beschrieben: https://forum.fhem.de/index.php/topic,54271.0.html
Wenn das dann klappt, wäre es nett, wenn "jemand" (von euch beiden) einen update für den Wiki-Artikel liefern könnte, der unter Buster funktioniert. Wenn's irgend geht, bitte
- unter Berücksichtigung der Dinge, die bereits in der "allg. Pi-Anleitung" im Wiki zu finden sind (also im Ergebnis: dahin verweisen, nur den spezifischen Rest in diesem Artikel lassen) und
- gleich passend formatieren (also den Quelltext als Basis nehmen).
Danke, Beta-User
Hi,
ich taste mich mal von hinten an eine mögliche Lösung:
querverweis zu fhem.service: https://forum.fhem.de/index.php/topic,101819.msg974360.html#msg974360
Dort kann man sicher so wie Beta-User sagte eine ähnliche Zeile analog zu seinem Link einfügen
ExecStartPre=ScriptZumStarten # Im Link steht das drin /opt/hmusbcfg/hmland -d -p 1234 -r 0
Dahinein müssen die Zeilen aus Punkt 3 aus dem Wiki Artikel zum Schluss https://wiki.fhem.de/wiki/FHEM_auf_Raspberry_PI_mit_COC_betreiben#COC_in_Betrieb_nehmen
Vorbereiten muss den Pi so wie hier beschrieben: https://wiki.fhem.de/wiki/Raspberry_Pi#Verwendung_UART_f.C3.BCr_Zusatzmodule
Ich habe keinen COC, ich kann also nur Theorie liefern. :-\
Also in umgekehrter Reihenfolge testweise so vorgehen.
UART Vorbereiten
Script erzeugen
fhem beenden: sudo systemctl stop fhem.
Dann das Script starten, auf Fehler achten.
Dann fhem starten: sudo systemctl start fhem.
Schauen ob der COC läuft.
Wenn ja dann die fhem.service mit der erwähnten Zeile modifizieren.
Schauen ob ein normaler Systemstart läuft.
Wenn ja: freuen und Wiki ergänzen.
Wenn nein: Schade, dann weiter nach einer Lösung suchen :)
Gruß Otto
Hallo,
ich habe es jetzt glaub ich hinbekommen.
Scheinbar muss man bei Buster den GPIO Port17 auf high setzen sonst reagier das CUL nicht (zumindest meins blinkte nicht)
Folgendes habe ich bei mir gemacht:
unter /etc/systemd/system habe ich eine Datei mit dem Namen gpio17high.service erstellt. Diese hat folgenden Inhalt:
[Unit]
Description=GPIO Port 17 High
Requires=[Was eventuell zuerst gestartet werden muss]
[Service]
Type=oneshot
ExecStart=/usr/local/bin/gpio17high.sh
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
als nächstes habe ich in /usr/local/bin/ eine Datei namens gpio17high.sh angelegt. Diese hat folgenden Inhalt:
#!/bin/bash
if test ! -d /sys/class/gpio/gpio17; then echo 17 > /sys/class/gpio/export; fi
echo out > /sys/class/gpio/gpio17/direction
echo 1 > /sys/class/gpio/gpio17/value
exit=0
dann musste ich das Script noch ausführbar machen:
sudo chmod +x gpio17high.sh
dann habe ich folgende Befehle abgesetzt:
systemctl daemon-reload
systemctl enable gpio17high.service
systemctl start gpio17high.service
und siehe da das CUL blinkt und ist auch im FHEM verfügbar
nach einem reboot wird der Port auch entsprechend gesetzt.
Ich hoffe dashilft dir weiter
Zitat von: syntetic am 02 Januar 2020, 18:52:00
Scheinbar muss man bei Buster den GPIO Port17 auf high setzen sonst reagier das CUL nicht (zumindest meins blinkte nicht)
Aber das ist doch scheinbar schon immer so?! Zumindest bei den Dingern die am GPIO Port stecken ;)
Und erst vor kurzem gab es diesen Lösungsweg. https://forum.fhem.de/index.php/topic,106060.msg1003767.html#msg1003767
Gesundes neues Jahr
Otto
Hallo syntetic ,
ich habe Deinen Post gelesen. Bin auch schon lange auf der Lösungssuche COC unter Buster.
Deine Script habe ich ausgeführt. Beim " dann musste ich das Script noch ausführbar machen:
sudo chmod +x gpio17high.sh
" pi@steuerung:~ $ sudo chmod +x gpio17high.sh
chmod: Zugriff auf 'gpio17high.sh' nicht möglich: Datei oder Verzeichnis nicht gefunden
Muss ich " root " sein um Benutzerrechte auszuführen?
sudo chmod +x /usr/local/bin/gpio17high.sh
Oder wo immer Dein Script liegt :)
Wennn das Script läuft, würde ich es im fhem.service mit ExecStartPre ausführen. Aber viele Wege ...
https://wiki.fhem.de/wiki/Fhem.service_(systemd_unit_file)
Gruß Otto
Hi, habe die Script alle übernommen vom post syntetic.
Systemservice nict enable.root@steuerung:/# nano /etc/systemd/system/gpio17high.service
root@steuerung:/# systemctl daemon-reload
root@steuerung:/# systemctl enable gpio17high.service
Created symlink /etc/systemd/system/multi-user.target.wants/gpio17high.service → /etc/systemd/system/gpio17high.service.
root@steuerung:/# systemctl start gpio17high.service
root@steuerung:/# reboot now
Keine Änderung FHEM. COC opened.
Gruß Festus 244