Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern

Begonnen von DeeSPe, 22 November 2017, 01:03:15

Vorheriges Thema - Nächstes Thema

MadMax-FHEM

Erst mal bevor etwas durcheinander geht:

wo läuft fhem?

wo willst du den Service starten etc.?

Selber PI oder auf einem anderen PI als dort wo fhem läuft?


Wenn selber PI: sudo OHNE Passwort für den User fhem für "Service-Befehl" einrichten

Wenn fhem auf einem anderen PI (Rechner) läuft als dort wo du den Service steuern willst: ssh-Login OHNE Passwort für User fhem einrichten
(hat nix mit dem Anlegen eines Users fhem auf dem Remote-System zu tun!!!)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

simonTS

Danke Dir!
Der Spruch, wer lesen kann ... gilt wohl auch für schreibende ;-) Mein Problem ist für mich natürlich klar.

Testweise habe ich den Dienst vom entfernten DoorPI abfragen wollen, weil er mir als erstes eingefallen ist. dabei läuft FHEM mit Benutzer fhem auf RPI A und DoorPi unter pi auf RPI B:

fhem@RPI A
--define SD_doorpi serviced doorpi pi@RPI A
----attr SD_doorpi serviceInitd 1
--sudoers: fhem ALL=(ALL) NOPASSWD:/usr/sbin/service

doorpi@RPI B
--sudo service doorpi status ist ohne PW möglich, da in sudoers eingetragen

RPI A kann sich ohne PW mit ssh pi@RPI B einloggen.

Das Log zeigt wie das Reading "error": Unit doorpi.service could not be found.

Die Version ist 1.2.0.
FHEM auf wheezy@RPI-->
KNX: MDT STV-0320.01|SCN-IP000.01|AMI-1216.01|JAL-0810.01|AKD-0401.01|AKH-0800.01|BE-GTT4W.01|SCN-P360D1.01|SCN-G360K3.01|ABB-MRS/W Magnet-Reedkontakt|Zisterne:SRF06|LED:XCSOURCE WIFI Controller|

MadMax-FHEM

#77
Noch mal, in dem Fall lesen!

User fhem auf PI A braucht kein sudo für irgendwas!
Sondern PASSWORTLOSEN Login per ssh auf PI B als User pi, der dann dort (PI B) per sudo den Service steuert/abfrägt...

Dazu musst du ein Zertifikat erzeugen und dann auf den PI B übertragen...
Anleitungen dazu gibt es genug, z.B. http://heinz-otto.blogspot.com/2017/01/per-ssh-remote-befehle-direkt-ausfuhren.html

Sofern (was ich jetzt auswendig nicht weiß) das Fhem-Modul systemd einen Dienst remote steuern kann...


Wenn du dich direkt per ssh auf dem PI B (DoorPi) einloggst, als User pi und den Service-Befehl eingibst, geht es dann?

Welche Betriebssysteme laufen jeweils!?

Wie wird der DoorPi-Dienst auf PI B gestartet?

initd oder systemd!?

Und zum Testen/Ausprobieren macht es natürlich Sinn gleich mal den kompliziertesten Fall zu nehmen... ;)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

MadMax-FHEM

ZitatRPI A kann sich ohne PW mit ssh pi@RPI B einloggen.

Welcher User!?

User pi auf RasPi A bei RasPi B ODER User fhem auf RasPi A als User pi auf RasPi B!?

Das ist die erste entscheidende Frage!
Und das muss gehen, da ja das fhem-Modul die Befehle als User fhem auf RasPi A absetzen soll.
Dazu muss sich User fhem (NICHT pi) passwortlos auf RasPi B (als User pi) einloggen können.

Ist das möglich muss eben der Service-Aufruf als User pi mit sudo auf RasPi B funktionieren...

Also immer langsan!
Lesen, denken, ausführen!

Sonst sind am Ende beide Systeme "Schrott"...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

simonTS

#79
Hey Danke Euch!

Also, mit der Version 1.2.3 aus dem ersten Eintrag hier im Thema.
Zertifikat von RPI A bei RPI B hinterlegt -> passwortloser zugang fkt.

Eingeloggt auf RPI A als fhem kann ich ohne Passwort mit "ssh pi@RPI B" einloggen, hier direkt mit der Abfrage:

fhem@fhem:/opt/fhem $ ssh pi@192.168.1.6 sudo service doorpi status
DoorPi is running.


In fhem habe ich dem servicd das attribut für initd auf 1 gesetzt, da ja initd und nicht systemctl.

Und gerade nochmal im Log geschaut, dort überschlägt sich dann eine Abfrage nach der anderen wie:

2018.11.18 10:17:10 4: Connection accepted from telnetPort_127.0.0.1_58866
2018.11.18 10:17:10 5: Cmd: >{BlockingStart('3997')}<
2018.11.18 10:17:10 5: Cmd: >{serviced_ExecFinished('SD_doorpi||0')}<
2018.11.18 10:17:10 4: SD_doorpi: executed shell command: ssh pi@192.168.1.6 'sudo service doorpi status'
2018.11.18 10:17:10 4: BlockingCall (serviced_ExecCmd): created child (5743), uses telnetPort to connect back
2018.11.18 10:17:10 5: Starting notify loop for SD_doorpi, 1 event(s), first is status
2018.11.18 10:17:10 5: End notify loop for SD_doorpi
2018.11.18 10:17:11 4: Connection accepted from telnetPort_127.0.0.1_58870
2018.11.18 10:17:11 5: Cmd: >{BlockingStart('3998')}<
2018.11.18 10:17:11 5: Cmd: >{serviced_ExecFinished('SD_doorpi||0')}<
2018.11.18 10:17:11 4: SD_doorpi: executed shell command: ssh pi@192.168.1.6 'sudo service doorpi status'
2018.11.18 10:17:11 4: BlockingCall (serviced_ExecCmd): created child (5746), uses telnetPort to connect back
2018.11.18 10:17:11 5: Starting notify loop for SD_doorpi, 1 event(s), first is status



[EDIT]
Je länger ich darüber nachdenke ...
* Dazu muss sich User fhem (NICHT pi) passwortlos auf RasPi B (als User pi) einloggen können.
* wie meinst du das? ist das dann ein ssh fhem@RPI B oder ssh pi@RPI B ? Daher auch mal meine Frage, ob ich dann auf dem remote system auch den nutzer fhem anlegen muss, damit ein login ssh fhem@RPI B klappt. Der Nutzer fhem auf dem remote system ist nicht angelegt, der Nutzer fhem kann sich passwortlos als pi auf dem remote system anmelden.
FHEM auf wheezy@RPI-->
KNX: MDT STV-0320.01|SCN-IP000.01|AMI-1216.01|JAL-0810.01|AKD-0401.01|AKH-0800.01|BE-GTT4W.01|SCN-P360D1.01|SCN-G360K3.01|ABB-MRS/W Magnet-Reedkontakt|Zisterne:SRF06|LED:XCSOURCE WIFI Controller|

simonTS

N'Abend,

ich weiß nicht, ob es sich gehört auf seine eigene Frage zu fragen ... Ich hoffe, daß ist ok.

Ich gebe es auf, möchte dennoch von meinem Versuch berichten. Also, was habe ich getan:

RPI_A: RPI3/Debian stretch@192.168.1.8: fhem, user=fhem
RPI_B: RPI3/Debian stretch@192.168.1.6: doorpi, user=pi

ssh key von RPI_A auf RPI_B kopiert:
fhem@fhem:~ $ cat .ssh/id_rsa.pub | ssh pi@192.168.1.6 'cat >> .ssh/authorized_keys'
--> passwortloser Zugang von RPI_A zu RPI_B via Zertifikat funktioniert.

visudo RPI_B:
fhem ALL=(ALL) NOPASSWD:/usr/sbin/service

fhem:
define T_SD_doorpi serviced doorpi pi@192.168.1.6
attr T_SD_doorpi serviceInitd 1
attr T_SD_doorpi serviceLogin serviceLogin pi@192.168.1.6
attr T_SD_doorpi serviceSudo 0 und 1 ausprobiert


was passiert bei einer manuellen Abfrage:

fhem@fhem:/opt/fhem $ ssh pi@192.168.1.6 'sudo service doorpi status'
DoorPi is running.

und ohne sudo:
fhem@fhem:/opt/fhem $ ssh pi@192.168.1.6 'service doorpi status'
bash: service: command not found


was bekomme ich als output im log:

2018.11.27 19:40:02 5: End notify loop for SD_doorpi
2018.11.27 19:40:02 4: Connection accepted from telnetPort_127.0.0.1_35842
2018.11.27 19:40:02 5: Cmd: >{BlockingRegisterTelnet($cl,8997)}<
2018.11.27 19:40:02 5: SD_doorpi: serviced_ExecCmd com: ssh pi@192.168.1.6 'sudo service doorpi status', line: 3
2018.11.27 19:40:02 5: Cmd: >{BlockingStart('8997')}<
2018.11.27 19:40:02 5: Cmd: >{serviced_ExecFinished('SD_doorpi|0|')}<
2018.11.27 19:40:02 5: SD_doorpi: serviced_Set executing shell command: ssh pi@192.168.1.6 'sudo service doorpi status'
2018.11.27 19:40:02 4: BlockingCall (serviced_ExecCmd): created child (12049), uses telnetPort to connect back
2018.11.27 19:40:02 5: Starting notify loop for SD_doorpi, 1 event(s), first is status
2018.11.27 19:40:02 5: createNotifyHash
2018.11.27 19:40:02 5: End notify loop for SD_doorpi
2018.11.27 19:40:02 4: Connection accepted from telnetPort_127.0.0.1_35846
2018.11.27 19:40:02 5: Cmd: >{BlockingRegisterTelnet($cl,8998)}<
2018.11.27 19:40:03 5: SD_doorpi: serviced_ExecCmd com: ssh pi@192.168.1.6 'sudo service doorpi status', line: 3
2018.11.27 19:40:03 5: Cmd: >{BlockingStart('8998')}<
2018.11.27 19:40:03 5: Cmd: >{serviced_ExecFinished('SD_doorpi|0|')}<
2018.11.27 19:40:03 5: SD_doorpi: serviced_Set executing shell command: ssh pi@192.168.1.6 'sudo service doorpi status'
2018.11.27 19:40:03 4: BlockingCall (serviced_ExecCmd): created child (12053), uses telnetPort to connect back
2018.11.27 19:40:03 5: Starting notify loop for SD_doorpi, 1 event(s), first is status
2018.11.27 19:40:03 4: DbLog DbLog_haus -> ################################################################
2018.11.27 19:40:03 4: DbLog DbLog_haus -> ###              start of new Logcycle                       ###
2018.11.27 19:40:03 4: DbLog DbLog_haus -> ################################################################
2018.11.27 19:40:03 4: DbLog DbLog_haus -> number of events received: 1 for device: SD_doorpi
2018.11.27 19:40:03 4: DbLog DbLog_haus -> check Device: SD_doorpi , Event: state: status
2018.11.27 19:40:03 5: End notify loop for SD_doorpi

...
FHEM auf wheezy@RPI-->
KNX: MDT STV-0320.01|SCN-IP000.01|AMI-1216.01|JAL-0810.01|AKD-0401.01|AKH-0800.01|BE-GTT4W.01|SCN-P360D1.01|SCN-G360K3.01|ABB-MRS/W Magnet-Reedkontakt|Zisterne:SRF06|LED:XCSOURCE WIFI Controller|

MadMax-FHEM

#81
Hallo simonTS,

ja und?

Geht oder geht nicht?

Aber es sind immer noch Verständnislücken sichtbar:

1. du loggst dich auf PI_B als User pi ein NICHT als User fhem! D.h. der Eintrag in der sudoers auf PI_B ist unnötig. (Klar das ssh-Kommando führt User fhem auf PI_A aus)

2. klar brauchst du sudo für Zugriff auf Service-Routinen! (egal als welcher User auf welchem "Rechner" auch immer / außer: eingeloggt als root)

3. was passiert, wenn du dich als User pi direkt auf PI_B einloggst (genau das macht nämlich dein: ssh pi@PI_B) und dann "sudo service doorpi status" o.ä. eingibst?

4. zum Übertragen von Zertifikaten für passwortlosen Zugang gibt es eine elegantere Variante: ssh-copy-id https://www.ssh.com/ssh/copy-id


Also du musst immer wissen welcher User du auf welcher Seite bist und welche Befehle du dann in wessen Kontext ausführst!
Ist nicht einfach aber da muss man einmal durch ansonsten wird es nicht klappen!

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

DeeSPe

@simonTS:

Habe jetzt nicht alle zurückliegenden Beiträge von Dir gelesen.
Kann es sein dass der passwortlose Zugang nicht für den Benutzer eingerichtet ist unter dem FHEM läuft? Dieser benötigt nämlich die passwortlose Anmeldung zum RPI_B.
Falls FHEM unter dem user fhem läuft, dann den Ordner ~/.ssh nach /opt/fhem/.ssh kopieren, dann sollte auch der Zugang zu RPI_B aus FHEM heraus klappen.

Gruß
Dan
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

simonTS

#83
Hey!

Danke euch für das abendliche Interesse!! Da bin ich ja schon zu spät zurück am Rechner ;-)

@DeeSPe
FHEM läuft unter fhem auf RPI_A. Das Zertifikat habe ich als fhem erstellt. Muss ich auf dem remote, also RPI_B, auch fhem als user anlegen? der doorpi läuft auf dem remote RPI_B als pi?
Deswegen funktioniert ja auch von fhem@RPI_A$ ssh pi@RPI_B 'sudo service doorpi status'. Oder muss von fhem@RPI_A$ ssh fhem@RPI_B 'sudo service doorpi status' gehen?

@MadMax-FHEM
1. Das stimmt, ist mir jetzt auch aufgefallen. Das ist mir beim testen passiert, habe ich wohl vergessen zurückzustellen... -> wieder auf user 'pi ' gestellt, aber keine änderung
2. nur für den 'service ... status' doch nicht? aber habs ja in der sudoers eingetragen.
3. habe ich oben im Bsp. dort kommt ein 'Doorpi running.'
4. ;-) Danke!

Ja ja, der DAU sitzt gewöhnlich vor dem Monitor, ich weiß ;-) Wahrscheinlich sehe ich gerade vor lauter Bäumen den Wald nicht mehr ... Da die Klingel jetzt eh umzieht mache ich demnächst mal die VM platt und versuchs nochmal neu...

[EDIT]
Wenn ich den status via get Abfrage, scheint sich das Ding einfach in Schleife zudrehen... Es hängt nicht, gibt aber nicht auf abzufragen. Ich kann die prozesse killen oder das Modul löschen und neu anlegen, aber nichts mehr damit anfangen. Ich habe mir keinen Code angeschaut, aber ... Die Version aus dem 1. Thread ist doch korrekt?
FHEM auf wheezy@RPI-->
KNX: MDT STV-0320.01|SCN-IP000.01|AMI-1216.01|JAL-0810.01|AKD-0401.01|AKH-0800.01|BE-GTT4W.01|SCN-P360D1.01|SCN-G360K3.01|ABB-MRS/W Magnet-Reedkontakt|Zisterne:SRF06|LED:XCSOURCE WIFI Controller|

MadMax-FHEM

#84
Nein ein User fhem auf PI_B ist unnötig bzw. macht das ganze noch komplizierter...

Wie geschrieben: in Ruhe überlegen welcher User auf welchem System WAS ausführt/ausführen soll...

Noch ausführlicher geht nicht mehr als in den letzten Antworten erläutert...

Wichtig ist in Ruhe drüber nachdenken...
Evtl. mal "aufzeichnen"...

Und erst wenn das klar ist: aktiv werden und Dinge einrichten.

EDIT: es fehlt auch noch die Info (oder ich hab es überlesen) was "sudo service doorpi status" (bzw. start/stop) auf PI_B mit User pi "sagt"...

EDIT2: den Link zu Otto's Blog hast du dir angeschaut? Da ist alles noch mal erläutert... Und wie ich finde sehr gut...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

MadMax-FHEM

#85
Ich versuch's doch noch mal (aber einfacher geht es wirklich nicht mehr)...
...siehe Anhang.

User fhem loggt sich "als User pi" auf PI_B ein.
Das ist: ssh pi@PI_B
Damit dazu kein Passwort eingegeben werden muss: Zertifikate von User fhem im Verzeichnis .ssh des Users pi  auf PI_B liegen (ssh-copy-id: .ssh Zertifikate des Users fhem auf PI_A nach .ssh des Users pi auf PI_B)
Somit wird dem User fhem "vertraut" auch ohne Passwort...

Alles weitere (also das an ssh User@RemoteHost Angehängte) wird dann "im Kontext" des Users "User auf RemoteHost" ausgeführt.
Hier also: User pi auf PI_B...

Konkret: das Kommando "sudo service doorpi status" wird dann "als User pi" auf PI_B ausgeführt.
sudo deshalb weil für den Aufruf "service Name status|start|stop|restart" eben nur der User root Berechtigung hat.
Damit da dann kein Passwort gebraucht wird muss für den User pi auf PI_B in der sudoers mindestens für dieses Kommando ein "NO_PASSWD" Eintrag vorhanden sein.

Das war's...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

simonTS

#86
user fhem auf RPI_B ist unnötig -> Danke! War für mich der schwierigste Teil und auch Dott sei Dank der sinnfreiste ...

Nach erfolgreicher Medi(t)ation habe ich das eigentlich unter der Prämisse oben mit den richtigen Nutzern eingerichtet. An der Stelle geht es mir genauso, ich weiß nicht, ob ich mich mitteilen kann. fhem@PC1 loggt sich auf pi@PC2 ein und frägt einen Dienst ab, soweit eine einfache - und im Beispiel funktionierende - Geschichte.

Auch Otto's Blog nochmal nach Abweichung durchforstet ... Entspricht prinzipiell meiner Vorgehensewiese

UND der Login funktioniert...:

fhem@fhem:/opt/fhem $ ssh pi@192.168.1.6 'sudo service doorpi status'
DoorPi is running.

und ohne sudo:
fhem@fhem:/opt/fhem $ ssh pi@192.168.1.6 'service doorpi status'
bash: service: command not found


Nix für Ungut. Ich finde es einfach nicht und es scheint ein einfacher Fehler (des DAU!!!) zu sein. Ich gehe nochmal in mich und berichte nach Aufbau aus greenfield nochmal ....

[EDIT]
@JOACHIM, genauso hab ich es ja! Und das läuft trotzdem in Schleife ... Vllt. habe ich was anderes verhauen. Ich setze nochmal neu auf.
FHEM auf wheezy@RPI-->
KNX: MDT STV-0320.01|SCN-IP000.01|AMI-1216.01|JAL-0810.01|AKD-0401.01|AKH-0800.01|BE-GTT4W.01|SCN-P360D1.01|SCN-G360K3.01|ABB-MRS/W Magnet-Reedkontakt|Zisterne:SRF06|LED:XCSOURCE WIFI Controller|

MadMax-FHEM

Noch mal (also ich sehe an deiner geposteten Ausgabe keinen Fehler): geht es nicht?

Und wenn WAS genau geht nicht?

Hast du das Serviced-Device richtig konfiguriert?

Poste doch mal ein list (auch wenn schon geschehen, dann brauche ich nicht lang suchen)...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

simonTS

#88
Nein, leider geht es nur via CLI, nicht in fhem.

wenn ich das device wie unten anlege und ein 'get SD_doorpi status' aus der fhem WEB oberfläche absetze bekomme ich im reading 'state status 2018-11-27 21:32:34' lediglich die sekunden hochgezählt.


Internals:
   CFGFN     
   DEF        doorpi pi@192.168.1.6
   NAME       SD_doorpi
   NOTIFYDEV  global
   NR         4194
   NTFY_ORDER 50-SD_doorpi
   SERVICENAME doorpi
   STATE      Initialized
   TYPE       serviced
   VERSION    1.2.3
   READINGS:
     2018-11-27 21:29:56   state           Initialized
   helper:
Attributes:
   alias      Service doorpi
   cmdIcon    restart:rc_REPEAT stop:rc_STOP status:rc_INFO start:rc_PLAY
   devStateIcon Initialized|status:light_question error|failed:light_exclamation running:audio_play:stop stopped:audio_stop:start stopping:audio_stop .*starting:audio_repeat
   icon       hue_room_garage
   room       Services
   serviceInitd 1
   serviceLogin pi@192.168.1.6
   serviceSudo 1
   webCmd     start:restart:stop:status


-> Also, es zeigt den status nicht an und frägt in schleife ab. Das geht nicht.
-> Es müsste doch ein Reading mit state running oder so rauskommen?

Und ab dann nur noch

Work already/still in progress... Please wait for the current process to finish.
FHEM auf wheezy@RPI-->
KNX: MDT STV-0320.01|SCN-IP000.01|AMI-1216.01|JAL-0810.01|AKD-0401.01|AKH-0800.01|BE-GTT4W.01|SCN-P360D1.01|SCN-G360K3.01|ABB-MRS/W Magnet-Reedkontakt|Zisterne:SRF06|LED:XCSOURCE WIFI Controller|

MadMax-FHEM

#89
Hmm, also ich hab das grad mal nachgespielt...
...funktioniert einwandfrei.

Ich habe einfach mal den BlueTooth Service auf einem remoten System per serviced Modul gesteuert bzw. abgefragt.

Irgendwas scheint bei dir eigenartig zu sein...

Ich konnte jetzt auch nichts an der Modul-Definition finden...

Du kannst das auch mal manuell nachspielen (hast du das schon?):

ssh pi@192.168.1.6 'sudo service doorpi status'

als User fhem in der Console ausführen...

Läuft fhem tatsächlich unter dem User fhem?

Wie wird fhem bei dir gestartet?
initd/systemd?

Poste doch mal den Inhalt des Startscripts...

Bin etwas ratlos weil bei mir ging das jetzt innerhalb von 5min...

EDIT: noch ein Test mit einem fhem auf einem anderen Rechner... Ebenfalls ok...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)