dummy - event trotz 'attr disable 1’

Begonnen von Jamo, 03 Oktober 2019, 15:44:50

Vorheriges Thema - Nächstes Thema

Jamo

Hi,
ich habe folgenden dummy Schalter. Wenn ich das "attr disable 1" setze, und 'on' oder 'off' schalte, ändert sich zwar der dummy state nicht mehr, aber es wird trotzdem ein Event generiert (e.g. im "Event monitor"), und mein nachfolgendes notify reagiert. Ich kann das nachfolgende notify nicht auf disabled setzten, weil das Suchmuster des nachfolgenden Notify mehrere Schalter enthält.

Ich hätte erwartet, dass, wenn 'attr disable = 1' gesetzt ist, kein Event mehr generiert wird. In der Comandref oder Wiki ist das nicht beschrieben, soll das so sein oder ist das ein Fehler?

defmod test1 dummy
attr test1 disable 1
attr test1 event-on-change-reading state
attr test1 room Test
attr test1 webCmd on:off
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

rudolfkoenig

Das ist zwar keine Absicht, aber es zu fixen wuerde einen groesseren Umbau mit Nebenwirkungen nach sich ziehen.
Mir faellt nur ein cmdalias als Workaround ein.

Jamo

OK, danke, dann weiss ich Bescheid, und werde mir dann einen Workaround bauen.
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

frank

setze doch zb
attr test1 event-on-change-reading blabla
damit sollten keine events mehr kommen.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Jamo

'blabla' funktioniert auch nicht, gerade probiert ...
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

Damian

Du könntest einen Event-Handler nehmen, der den Status auswertet, statt das Event.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Jamo

Hallo Damian,
falls Du sowas meinst:
defmod testfhem1_n notify test1:.* {
my $state = ReadingsVal ("test1","state","nA");
if ($state eq "on") {...}
}

das hier funktioniert für den Fall, das der gegenwärtige state 'off' ist (der sich durch das disable ja dann auch nicht mehr ändert), ich ein 'on' auslöse, und und ich dann prüfe, ob der Status 'on' ist. Also für den Fall das der Schalter aus ist.
Aber für den Fall das der state schon 'on' ist, wird das Event immer noch durchgelassen.

Wahrscheinlich meinst Du aber folgendes: Bei jedem Event den aktuellen state separat abspeichern (zum beispiel in einem seperaten Reading), und schauen ob dieses Reading und der Event unterschiedlich sind. Ja, das funktioniert wenn man ein event-on-change-reading state gesetzt hat ....
Danke für die Idee!
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

Damian

Im Prinzip das Gleiche nur etwas kürzer und ohne mehrfache Ausführung (erst wieder wenn test1 zwischendurch off war):

defmod testfhem1 DOIF ([test1:state] eq "on") (set ...)
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

DeeSPe

Eine weitere Lösung wäre z.B. den disabled Status im notify abzufragen:
defmod testfhem1_n notify test1:.* {
return if (IsDisabled($NAME));
if ($state eq "on") {...}
}


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