73_PRESENCE.pm verarbeitet disable nicht wie erwartet

Begonnen von betateilchen, 04 Juli 2016, 19:35:43

Vorheriges Thema - Nächstes Thema

betateilchen

In meiner fhem Installation gibt es zwei PRESENCE devices, beide gekoppelt an lepresenced.

Leider wird ein gesetztes Attribut "disable" nicht wie erwartet verarbeitet.
Trotz eines auf 1 gesetztem Attribut wird ein event für device_name erzeugt.
Die events für state und presence werden nicht mehr erzeugt.

Eigentlich habe ich erwartet, dass bei einem gesetzten Attribut disable gar keine events mehr erzeugt werden.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Markus Bloch

Hallo Udo,

danke für den Hinweis. Hab ich soeben gefixt.

Gruß
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)

betateilchen

Hallo Markus,

danke.

Ich hatte vorhin mal wegen des Verhaltens in das Modul geschaut. Wäre es nicht viel einfacher, mit IsDisabled() zu arbeiten,
anstatt den ganzen Verwaltungsaufwand mit dem hash->helper zu betreiben?

Viele Grüße
Udo
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Markus Bloch

Hi Udo,

jaaa, das ist mir bei der gestrigen Änderung auch aufgefallen. Bei meinen anderen Modulen hatte ich das schonmal geändert um damit auch disabledForIntervals zu unterstützen. Hatte ich bei PRESENCE wohl vergessen. Ist halt eines meiner ersten Module.

Werde ich die Tage aber nochmal glatt ziehen.

Gruß
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)

betateilchen

Nur keinen Streß, es stört ja nicht. Macht halt nur alles ziemlich unübersichtlich *lach*
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

KernSani

zwar unwichtig aber trotzdem...
Der Raspi an dem mein BT-Dongle hängt ist schon etwas altersschwach und wird daher nachts um 3 durchgestartet. Da ich ein Freund eines sauberen Logfiles bin, setze ich bei den lan-bluetooth PRESENCE Devices zunächst disable 1 und lösche 5 Minuten später das disable Attribut wieder, Logausgabe ist trotzdem:

2017.03.23 03:00:00 5: PRESENCE (gTag_red_BT) - received data: present;Gigaset G-tag
2017.03.23 03:00:00 5: PRESENCE (gTag_red_BT) - received data: no command running
2017.03.23 03:00:06 1: 192.168.1.210:5333 disconnected, waiting to reappear (gTag_red_BT)
2017.03.23 03:01:06 1: 192.168.1.210:5333 reappeared (gTag_red_BT)
2017.03.23 03:05:00 5: SW: 7C:2F:80:AD:C2:29|30

d.h. obwohl disabled scheint er irgendwie weiter nachzufragen... Bug oder feature?

RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

Markus Bloch

Ich werde das Handling von disabled morgen überarbeiten, wie betateilchen schon angemerkt hat ist das aktuell etwas arg verkrukst. Da merkt man noch, das es aus meinen Anfängen der Modulprogrammierung stammt.

Gruß
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)