fhempy: remote, ble und Casts

[SouzA]

Moin Dominik,

habe mich an die Remote-Installation von fhempy gewagt.
Da sind mir ein paar Sachen aufgefallen und ein paar Fragen habe ich noch...

Zum Stand:
1.) Hauptinstanz: FHEM und fhempy auf Raspi 4 mit buster
2.) Remoteinstanz: KEIN FHEM, fhempy und zusätzlich

Code Auswählen Erweitern

pip3 install --upgrade fhempy# systemd service installation
curl -sL https://raw.githubusercontent.com/dominikkarall/fhempy/master/install_systemd_fhempy.sh | sudo -E bash -
auf Raspi 3 mit bullseye.

Auffälligkeiten:
1.) Im Gegensatz zu der Beschreibung auf Github steht in FHEM auf der Hauptinstanz nicht fhempy_remote_IP, sondern fhempy_peer_IP.
2.)  Die Versionsnummer des peers wurde erst nach dem zweiten Mal 

Code Auswählen Erweitern

pip3 install --upgrade fhempy# systemd service installation
curl -sL https://raw.githubusercontent.com/dominikkarall/fhempy/master/install_systemd_fhempy.sh | sudo -E bash -
angezeigt.
3.) In der Anleitung steht:

Code Auswählen Erweitern

Test fhempy by just running it with user pi, type fhempy and enter. Wait a few seconds until it gets discovered and you see the incoming FHEM connection.

Das funktioniert auch erst nach Schritt 2.)

Dann bei BLE Presence auf dem Remote-Pi:
1.) Mit dem Befehl

Code Auswählen Erweitern

find $HOME/.local -name bluepy-helper
passiert genau gar nichts.
Somit funktioniert der sudo setcap auch nicht.
Erst mit

Code Auswählen Erweitern

pip3 install bluepy wurde das überhaupt installiert... Das muß man auch erstmal wissen...
Auch danach funktioniert das find nicht. Nur den Ordner selber finden und im Befehl eintragen hilft.

BLE Presence in FHEM auf Hauptraspi:
1.) funktioniert hier auch die Änderung des hci-Devices?
2.) ich habe den Eindruck, dass das attr scan_interval nicht so ganz ernst genommen wird. Habe 15 eingegeben. Eine Aktualisierung erfolgt dann irgendwann zwischen 15 und 30 Sekunden.
3.) Was bedeutet das attr scan_duration?
4.) Kopiert man ein ble-Device in FHEM und ändert in dem kopierten Device das IODev von peer zu binding, um es auf den beiden Instanzen zu erfassen, funktioniert das erste nicht mehr und der remote-Server wird als offline angezeigt (obwohl der Punkt grün ist...). Ein sudo reboot beider Raspis hilft nicht. Siehe Bild im Anhang.
Die ganzen anderen Geräte scheinen sich nicht entscheiden zu können, zu welchem Device sie gehören... Siehe Bild 2 im Anhang.
Ein IODEV kann bei den Casts nicht gesetzt werden. Wie funktioniert das richtig?

Fhempy auf Hauptraspi:
1.) Wenn man den den Remote_Peer ausmacht, kommen alle paar Sekunden Fehlermeldungen von wegen nicht erreichbar. Leider ist der peer nicht zu disablen.
2.) Löscht man den Peer in FHEM wird der log mit einer Meldung

Code Auswählen Erweitern

2021.11.16 00:00:01 0: Strange call for nonexistent fhempy_peer_192_168_178_48: ReadyFn2021.11.16 00:00:01 1: stacktrace:2021.11.16 00:00:01 1: main::CallFn called by fhem.pl (836)
konfrontiert. Die kommt mehr als 10x in der Sekunde. Mein Log ist heute explodiert und lässt sich nicht mehr öffnen. Deswegen kann ich dir auch nur die obere Zeile schicken...^^
Welche Möglichkeit gibt es den peer aus FHEM wieder zu entfernen?

Viel Text viele Fragen...Ich hoffe, du kannst mir dabei helfen das grade zu biegen.

Thx und bis denn
SouzA

[dominik]

Hi SouzA,

etwas spät meine Antwort, aber ich habe diesen Thread leider nicht gesehen.

READMEs habe ich aktualisiert, danke für die Hinweise!

BLE:
1.) funktioniert hier auch die Änderung des hci-Devices?
Ja, Attribut hci_device auf hciX setzen

2.) ich habe den Eindruck, dass das attr scan_interval nicht so ganz ernst genommen wird. Habe 15 eingegeben. Eine Aktualisierung erfolgt dann irgendwann zwischen 15 und 30 Sekunden.
scan_interval ist das Intervall zwischen 2 Scans. Ein Scan kann jedoch bis zu scan_duration (default 10) dauern. Nach scan_duration wird der Scan abgebrochen.

3.) Was bedeutet das attr scan_duration?
Maximale Zeit des Scanvorgangs in Sekunden.

4.) Kopiert man ein ble-Device in FHEM und ändert in dem kopierten Device das IODev von peer zu binding, um es auf den beiden Instanzen zu erfassen, funktioniert das erste nicht mehr und der remote-Server wird als offline angezeigt (obwohl der Punkt grün ist...). Ein sudo reboot beider Raspis hilft nicht. Siehe Bild im Anhang.
Ich frage sicherheitshalber nach...Devicename ist eh unterschiedlich? Also 2 unterschiedliche Devices (NAME) in FHEM mit unterschiedlichen IODev, richtig? Das sollte problemlos funktionieren. Du kannst sogar Devices transferieren. Einfach IODev ändern und schon wird das Device auf das neue IODev transferiert. So kann man die Last verteilen.

Um das Problem zu beheben, einfach BindingsIo Device vom Peer löschen und FHEM neu starten, dann sollte es weg sein. Aber wahrscheinlich ist es schon weg, nachdem jetzt 2 Monate vergingen   

[SouzA]

Moin Dominik,
du hier???!!! 

Hi SouzA,

etwas spät meine Antwort, aber ich habe diesen Thread leider nicht gesehen.

Macht nix... bin geduldig und hart im nehmen

READMEs habe ich aktualisiert, danke für die Hinweise!

Das war der Plan! 

4.) Kopiert man ein ble-Device in FHEM und ändert in dem kopierten Device das IODev von peer zu binding, um es auf den beiden Instanzen zu erfassen, funktioniert das erste nicht mehr und der remote-Server wird als offline angezeigt (obwohl der Punkt grün ist...). Ein sudo reboot beider Raspis hilft nicht. Siehe Bild im Anhang.
Ich frage sicherheitshalber nach...Devicename ist eh unterschiedlich? Also 2 unterschiedliche Devices (NAME) in FHEM mit unterschiedlichen IODev, richtig? Das sollte problemlos funktionieren. Du kannst sogar Devices transferieren. Einfach IODev ändern und schon wird das Device auf das neue IODev transferiert. So kann man die Last verteilen.

Sicher waren das unterschiedliche Namen... Geht ja auch gar nicht anders.
Hat nicht funktioniert. Musste ich dann sein lassen.

Um das Problem zu beheben, einfach BindingsIo Device vom Peer löschen und FHEM neu starten, dann sollte es weg sein. Aber wahrscheinlich ist es schon weg, nachdem jetzt 2 Monate vergingen   

Jup, is weg. Hab den Ausflug mit nem Peer-Pi mal probiert. Hat für mich aber ehrlich gesagt nicht sonderlich gut geklappt. (Siehe oben)

Ich danke dir trotzdem ganz herzlich für deine Rückmeldung und deine klasse Arbeit hier!

Thx und bis denn
SouzA