Notify oder DOIF - nur Hardware-dummys reagieren auf Befehle

Begonnen von joginet, 05 April 2015, 11:48:23

Vorheriges Thema - Nächstes Thema

joginet

Hallo Forum,
ich habe eine Variable/einen Dummystatus  durch ein DOIF erzeugt, die wird auch korrekt angelegt.

Jetzt möchte ich diesen Dummystatus mit einem weiteren DOIF (oder notify) auswerten und dazu benutzen, einen weiteren dummystatus
zu ändern.

wenn ich z.B. im DOIF
define streamcount_act DOIF ([streamcount:state] eq "zuviele_streams") (set mein_Softdummy on)
wird "mein_Softdummy" nicht geändert.

Wenn ich aber z.B. einen HM-Schalter in das DOIF setze:
define streamcount_act DOIF ([streamcount:state] eq "zuviele_streams") (set mein_HMSchalter on)
dann schaltet dieser.

Auf diesen Schalter kann ich dann auch triggern:
define streamcount_act_ueber_Umwege DOIF ([mein_HMSchalter:state] eq "on") (set mein_Softdummy on)

Mit notify ist es das selbe.

Ich hatte exakt dieses Prolem schonmal mit einer deutlich älteren fhem-Version:

http://forum.fhem.de/index.php/topic,21984.msg156023.html#msg156023

Damals habe ich das auf meine (seinerzeit) veraltete fhem Version geschoben, mittlerweile bin ich natürlich "up-to-date".
Der entsprechende HM-Schalter von damals hängt allerdings immer noch im Schrank und tut klaglos seinen Dienst als dummy-trigger  :)
Normal kann das aber doch nicht sein, oder?

Gruß, Jochen

Edit: hab's mal auf Perl-Ebene probiert, das ändert nichts:

define streamcount_act DOIF ([streamcount:state] eq "zuviele_streams") ({fhem('set mein_Softdummy on ')})

geht auch nicht...
Meine Konfig: FHEM auf NUC i5 mit Mint, HM-LAN, div. HM Schalter und Heizungsthermostate, FB 6840LTE mit Dect200, HUE bridge, HUE bulbs + Lightstrips, VU+Duo2 und Philips-TV Steuerung, Pushmail, Floorplan, Sprachsteuerung + Feedback per Arduino mit MOVI-Shield, LMS Multiroom mit 7x Pi

Damian

Zitat von: joginet am 05 April 2015, 11:48:23
Hallo Forum,
ich habe eine Variable/einen Dummystatus  durch ein DOIF erzeugt, die wird auch korrekt angelegt.

Jetzt möchte ich diesen Dummystatus mit einem weiteren DOIF (oder notify) auswerten und dazu benutzen, einen weiteren dummystatus
zu ändern.

wenn ich z.B. im DOIF
define streamcount_act DOIF ([streamcount:state] eq "zuviele_streams") (set mein_Softdummy on)
wird "mein_Softdummy" nicht geändert.

Wenn ich aber z.B. einen HM-Schalter in das DOIF setze:
define streamcount_act DOIF ([streamcount:state] eq "zuviele_streams") (set mein_HMSchalter on)
dann schaltet dieser.

Auf diesen Schalter kann ich dann auch triggern:
define streamcount_act_ueber_Umwege DOIF ([mein_HMSchalter:state] eq "on") (set mein_Softdummy on)

Mit notify ist es das selbe.

Ich hatte exakt dieses Prolem schonmal mit einer deutlich älteren fhem-Version:

http://forum.fhem.de/index.php/topic,21984.msg156023.html#msg156023

Damals habe ich das auf meine (seinerzeit) veraltete fhem Version geschoben, mittlerweile bin ich natürlich "up-to-date".
Der entsprechende HM-Schalter von damals hängt allerdings immer noch im Schrank und tut klaglos seinen Dienst als dummy-trigger  :)
Normal kann das aber doch nicht sein, oder?

Gruß, Jochen

Edit: hab's mal auf Perl-Ebene probiert, das ändert nichts:

define streamcount_act DOIF ([streamcount:state] eq "zuviele_streams") ({fhem('set mein_Softdummy on ')})

geht auch nicht...

Dir ist bewusst, dass ein DOIF insb. mit einer Bedingung ohne do always nur nach Zustandswechsel schaltet. Definiere das Attribut do always und teste noch mal.


Gruß

Damian

Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

joginet

ZitatDir ist bewusst, dass ein DOIF insb. mit einer Bedingung ohne do always nur nach Zustandswechsel schaltet. Definiere das Attribut do always und teste noch mal.

Ja, klar. Attribut ist gesetzt. Ich denke, das DOIF ist nicht das Problem. Mit notify ist's das ja gleiche. Und schalten mit Hardware-Schalter geht ja auch.

Gruß, Jochen
Meine Konfig: FHEM auf NUC i5 mit Mint, HM-LAN, div. HM Schalter und Heizungsthermostate, FB 6840LTE mit Dect200, HUE bridge, HUE bulbs + Lightstrips, VU+Duo2 und Philips-TV Steuerung, Pushmail, Floorplan, Sprachsteuerung + Feedback per Arduino mit MOVI-Shield, LMS Multiroom mit 7x Pi

joginet

#3
Was mir noch einfällt: bei beiden Problemen - also dem beschriebenen und dem von 2014 wird der status eines dummys zum schalten benutzt, der wiederum selbst von einem DOIF (oder damals notify) erzeugt wurde.

Ist es evt. diese "Kaskade" bei der es klemmt? Die readings des ersten,  "Schaltdummy-erzeugenden" notifys oder DOIFs sind jedenfalls alle ok.
Und warum reagiert ein Hardware-Schalter - das triggern funktioniert generell scheinbar auch...
Meine Konfig: FHEM auf NUC i5 mit Mint, HM-LAN, div. HM Schalter und Heizungsthermostate, FB 6840LTE mit Dect200, HUE bridge, HUE bulbs + Lightstrips, VU+Duo2 und Philips-TV Steuerung, Pushmail, Floorplan, Sprachsteuerung + Feedback per Arduino mit MOVI-Shield, LMS Multiroom mit 7x Pi

Damian

Zitat von: joginet am 05 April 2015, 20:19:04
Was mir noch einfällt: bei beiden Problemen - also dem beschriebenen und dem von 2014 wird der status eines dummys zum schalten benutzt, der wiederum selbst von einem DOIF (oder damals notify) erzeugt wurde.

Ist es evt. diese "Kaskade" bei der es klemmt? Die readings des ersten,  "Schaltdummy-erzeugenden" notifys oder DOIFs sind jedenfalls alle ok.
Und warum reagiert ein Hardware-Schalter - das triggern funktioniert generell scheinbar auch...

Dann musst du Auszüge aus dem Event-Monitor liefern und Ausgabe von list <dein DOIF-Modul>. Alles andere sind Mutmaßungen und kosten nur Zeit.

Gruß

Damian
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

joginet

Hmm - das ist schon sehr komplex - da müsste ich glaube ich seehr weit ausholen.

Und: der Eventmonitor ballert mich dermassen mit Events zu - bis ich da das richtige rausgelesen habe, ist die Seite 3x nach oben gescrollt...

Ich kann das gerne tun, wenn das der einzige Weg ist.  Ich gebe nur (nochmals) 2 Dinge zu bedenken:

1) es ist beim notify exakt das gleiche Problem

2) Alles funktioniert mit einem Homematic-Hardware-Schalter anstelle eines Soft-dummies - also alle readings/trigger/Schaltzustände/DOIFs/whatever laufen so, wie sie sollen

Aber - wie gesagt - wenn das der einizge Weg zum Ziel ist, erstelle ich mal eine Doku mit den lists der DOIFs und dem eventmonitor-Auszug.
Ich bin mir nur nicht sicher, ob das wirklich zielführend ist (wg. Grund 1+2) und hatte gehofft, es hat jemand schonmal ähnlich beobachtet.
Da ich das Problem in einer komplett anderen fhem-Installation mit komplett anderer Hardware(damals PI1) schonmal hatte, habe ich auf einen Bug gehofft,
der nicht bei mir liegt  :)
Meine Konfig: FHEM auf NUC i5 mit Mint, HM-LAN, div. HM Schalter und Heizungsthermostate, FB 6840LTE mit Dect200, HUE bridge, HUE bulbs + Lightstrips, VU+Duo2 und Philips-TV Steuerung, Pushmail, Floorplan, Sprachsteuerung + Feedback per Arduino mit MOVI-Shield, LMS Multiroom mit 7x Pi

Damian

Zitat von: joginet am 05 April 2015, 21:10:40
Hmm - das ist schon sehr komplex - da müsste ich glaube ich seehr weit ausholen.

Und: der Eventmonitor ballert mich dermassen mit Events zu - bis ich da das richtige rausgelesen habe, ist die Seite 3x nach oben gescrollt...

Ich kann das gerne tun, wenn das der einzige Weg ist.  Ich gebe nur (nochmals) 2 Dinge zu bedenken:

1) es ist beim notify exakt das gleiche Problem

2) Alles funktioniert mit einem Homematic-Hardware-Schalter anstelle eines Soft-dummies - also alle readings/trigger/Schaltzustände/DOIFs/whatever laufen so, wie sie sollen

Aber - wie gesagt - wenn das der einizge Weg zum Ziel ist, erstelle ich mal eine Doku mit den lists der DOIFs und dem eventmonitor-Auszug.
Ich bin mir nur nicht sicher, ob das wirklich zielführend ist (wg. Grund 1+2) und hatte gehofft, es hat jemand schonmal ähnlich beobachtet.
Da ich das Problem in einer komplett anderen fhem-Installation mit komplett anderer Hardware(damals PI1) schonmal hatte, habe ich auf einen Bug gehofft,
der nicht bei mir liegt  :)

Es ist relativ simpel: Wenn dein besagtes Device kein Event sichtbar im Event-Monitor liefert, dann kann im Notify bzw. DOIF auch nichts passieren.

Da würde ich als erstes schauen.

Gruß

Damian
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

hjgode

#7
Hallo

auch ich bin fast verzweifelt, DOIF verhält sich mit dummy Geräten schon seltsam.

OK, ich kann verstehen, dass ein dummy Gerät im IF Teil nicht funktioniert, weil dummy Geräte wohl keine Events auslösen, obwohl notify mit dummy Geräten funktioniert. Also sowas geht nicht:

define di_test dummy
define di_test DOIF ([du_test] eq "on") (set myaktor off) DOELSE (set myaktor on)
set di_test on

Der Event Monitor zeigt nur "di_test on" an, nix mit DOIF

Aber das DOIF auch keine dummy Geräte ändert ist schon ein erheblicher Mangel:
Beispiel: sonoff7_141 ist ein MQTT_DEVICE und du_test ein dummy

define di_test DOIF ([sonoff7_141] eq "on") (set du_test off) DOELSE (set du_test on)
set sonoff7_141 on


Nun zeigt der Event Monitor zwar brav an, dass du_test on ausgeführt wird, aber das du_test wird nicht geändert und behält seinen alten Zustand.

Ich habe das so gelöst, dass ich dummy IT Geräte für Schalt-Dummy benutze und habe mir noch ein NUL device angelegt.

define nuldev SIGNALduino /dev/nul
define du_test IT 0000F0000F 01 10
define di_test DOIF ([sonoff7_141] eq "on") (set du_test off) DOELSE (set du_test on)
set sonoff7_141 on


Wenn man dann einen Wechsel von sonoff7_141 hat, dann wird das du_test auch aktualisiert. (und ein notify über du_test auch)

Warum das Ganze? Na, weil MQTT devices zB kein on-for-timer kennen aber dummy Devices oder auch IT Devices kennen on-for-timer. Über ein notify auf das du_test zu meinem MQTT device kann ich dann auch on-for-timer mit dem MQTT.

Hier mal die komplette Test-Umgebung (fhem.cfg):

attr global userattr cmdIcon devStateIcon devStateStyle icon sortby webCmd webCmdLabel:textField-long widgetOverride
attr global autoload_undefined_devices 1
attr global logfile -
attr global modpath .
attr global motd SecurityCheck:\
\
WEB,WEBphone,WEBtablet has no associated allowed device with basicAuth.\
telnetPort has no associated allowed device with password/globalpassword.\
\
Restart FHEM for a new check if the problem is fixed,\
or set the global attribute motd to none to supress this message.\

attr global statefile ./log/fhem.save
attr global verbose 5
#attr global logfile ./log/fhem-%Y-%mTEST.log


#attr global logfile -
# Fake FileLog entry, to access the fhem log from FHEMWEB
define Logfile FileLog ./log/fhem-%Y-%mTEST.log fakelog

define telnetPort telnet 7072 global

define WEB FHEMWEB 8083 global

define WEBphone FHEMWEB 8084 global
attr WEBphone stylesheetPrefix smallscreen

define WEBtablet FHEMWEB 8085 global
attr WEBtablet stylesheetPrefix touchpad


define autocreate autocreate

define eventTypes eventTypes ./log/eventTypes.txt

define nuldevice SIGNALduino /dev/nul

define du_carport dummy
attr du_carport room TEST
attr du_carport setList on off
attr du_carport useSetExtensions 1

define du_test dummy
attr du_test room TEST
attr du_test setList on off

define di_ittest DOIF ([du_ittest] eq "on") ({fhem("set du_itcarport on")}) DOELSE ({fhem("set du_itcarport off")})
attr di_ittest room TEST
attr di_ittest verbose 5

define du_itcarport IT F0000F0FFF 0F F0
attr du_itcarport IODev 1
attr du_itcarport room TEST

define no_itcarport notify du_itcaport:.* set du_carport $EVENT
attr no_itcarport room TEST

define du_ittest IT F0000F0FFF 0F F0
attr du_ittest IODev sduinoTEST
attr du_ittest room TEST

define di_test DOIF ([du_test:&STATE] eq "on") {fhem("set du_carport on")} {fhem("set du_carport off")}
attr di_test addStateEvent 1
attr di_test do always
attr di_test room TEST
attr di_test verbose 5


Nur nebenbei bemerkt: Wenn man "set du_carport on" in der Kommandoeingabe oder über telnet eingibt, ändert sich du_test entsprechend. Nicht aber, wenn DOIF dasselbe versucht.

Gruss

~Josef
Debian SID mit aktuellem FHEM, nanoCUL 866, JeeLink EC3000, fhemduino, SIGNALduino,
3 x TFA TH Sensor, 1 x TFA TH Arduino Sender, 3 x EC3000, 4 x Elro Schaltsteckdosen, ESA2000
offline: Wibo Funkthermostat, 2 x ELV Funkthermostat FHT80, 2 FS20 ST4 Funksteckdose