PRESENCE Bluetooth Perfmon

Begonnen von der-Lolo, 14 Dezember 2013, 09:40:23

Vorheriges Thema - Nächstes Thema

der-Lolo

Der Perfmon meldet sich sobald ich ein Bluetooth Gerät einbinde sehr häufig FHEM verliert deutlich an bedienbarkeit, mache ich etwas falsch?
Ich habe lediglich ein


define MichaelBT PRESENCE local-bluetooth D8:9E:3F:30:0C:1E 10 60
attr MichaelBT event-on-change-reading state

Markus Bloch

Hast du etwas mehr Informationen für mich? So ist einfach sehr wenig Fleisch am Knochen um was dazu zu sagen ;-)

Viele Grüße

Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

herrmannj

Hallo der-Lolo,

vermutlich machst Du alles richtig.

fhem kann kein echtes multitasking. Rudi hat das recht intelligent realisiert indem alle module die "was wollen" der Reihe nach drankommen. Das funktioniert auch solange perfekt wie jedes modul selbst sich so kurz fasst wie irgendwie möglich. Einige Module machen aber folgendes: sie verschicken eine Anfrage (wohin auch immer, hier vermutlich dein bluetooh device) und warten dann direkt auf die Antwort und wenn keine kommt dann eben bis zum time-out. In genau dieser Zeit steht der Rest von fhem auch still.

Wenn ich dem presence modul jetzt dieses Verhalten falsch unterstelle bitte ich um Entschuldigung, das von Dir beschriebene ist aber Symptomatisch dafür. Damit das nicht mehr auftritt müsste presence forken (was eigene Schwierigkeiten mit sich bringt) oder aber asynchron arbeiten (was deutlich aufwendiger zu programmieren ist es weil typischerweise eine statemachine erfordert).

vg
Jörg




   

Markus Bloch

Zitat von: herrmannj am 14 Dezember 2013, 19:50:02
Wenn ich dem presence modul jetzt dieses Verhalten falsch unterstelle bitte ich um Entschuldigung, das von Dir beschriebene ist aber Symptomatisch dafür. Damit das nicht mehr auftritt müsste presence forken (was eigene Schwierigkeiten mit sich bringt) oder aber asynchron arbeiten (was deutlich aufwendiger zu programmieren ist es weil typischerweise eine statemachine erfordert). 

So funktioniert PRESENCE bereits von Anfang an ;-)

Der Bluetooth-Request wird asynchron vom Main-Thread von FHEM ausgeführt via Forking. Dies verhindert den Stillstand von FHEM während PRESENCE auf die Antwort wartet. Daher währe nun interessant zu wissen was der-Lolo genau angezeigt bekommt (Logeinträge, Config, etc.) um hier genaueres sagen zu können.

Viele Grüße

Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

herrmannj

damit tritt automatisch dieser Teil in Kraft den ich hiermit nochmal ausdrücklich unterstreiche:

Wenn ich dem presence modul jetzt dieses Verhalten falsch unterstelle bitte ich um Entschuldigung,

Dann wäre es wirklich gut zu wissen was mit verbose 5 und mseclog 1 vor einem freeze im log passiert.

vg
Jörg

der-Lolo

Hallo zusammen,
Zuerst möchte ich mich mal entschuldigen - diesen Thread habe ich total aus den Augen verloren...
Deswegen reagierte ich auch nicht auf eure Posts gerade habe ich erst entdeckt das es hier Antworten gab.

Ich habe mehrere Probleme nach dem Einsatz von perfmon festgestellt und einmal etwas detailreicher im Zusammenhang mit HUE gepostet - André gab mir den tip mal einen genaueren Blick auf meine netzwerkumgebung zu werfen. Hier bin ich dann auch fündig geworden - habe nun allen Teilnehmern in meinen LAN/WLAN eine eigene IP per Mac Adresse zugewiesen. Das war vorher in jedem fall nicht so sauber aufgebaut wie es jetzt ist.

Zur zeit bin ich allerdings nur auf einer minimal konfig unterwegs und setze das PRESENCE Bluetooth nicht ein. Ich denke aber das ich das bald nochmal versuchen werde. Glaube aber das nach lösen meiner Konflikte im LAN / WLAN auch das PRESENCE besser arbeitet.

Danke für eure Mühe falls es dennoch Probleme mit PRESENCE geben sollte werde ich mich erneut melden...