Trotz setList wird set nicht akzeptiert

Begonnen von vbs, 15 Februar 2017, 09:05:27

Vorheriges Thema - Nächstes Thema

vbs

Angespornt von der wunderbaren DOIF-Diskussion bin ich auch gerade dabei, etwas fitter in DOIF zu werden und habe momentan ein Problem. Ich hab gelesen, dass DOIF mittlerweile auch Eigenschaften eines Dummies übernehmen kann (setList, readingList), so dass ich gerne mein presence-Dummy und mein presence-DOIF zusammenführen wollte.

Das Problem ist, dass das DOIF-Device z.B. den Befehle "set env_presence home" nicht akzeptiert, obwohl "home" Teil von setList ist.

defmod env_presence DOIF ([env_presence:transition] eq "leaving") (set $SELF away) \
DOELSEIF ([env_presence:transition] eq "arriving") (set $SELF home, set env_f_justCameHome on-for-timer 300)
attr env_presence alias Anwesenheit
attr env_presence devStateIcon home:status_available away:status_away_1 sleep:scene_sleeping
attr env_presence event-on-change-reading (state|transition|statHomeDuration.*)
attr env_presence group Zustände
attr env_presence icon status_away_1
attr env_presence readingList transition
attr env_presence room Wohnung
attr env_presence setList away home sleep
attr env_presence userReadings homeDuration integral { (Value("env_presence") ne "away") /60.0 }
attr env_presence wait 300
attr env_presence webCmd home:away:sleep


Wenn ich dann aber "set env_presence home" aufrufe, kommt:
unknown argument home for env_presence, choose one of disable initialize enable cmd away home sleep

Per

Zitat von: vbs am 15 Februar 2017, 09:05:27set $SELF home
Du kannst nicht den umbenannten Status aufrufen. Du könntest ja diesen Status auch mehrfach oder für eine Sub-Cmd verwenden.
Deshalb:
set $SELF cmd_1
wäre richtig.

vbs

Sorry, werde aus der Antwort leider nicht so richtig schlau. Soviel ich weiß ist $SELF einfach der Name des DOIF-Devices. Was meinst du mit "umbenannten Status aufrufen"? Bin jetzt verwirrt ^^

Abgesehen davon will ich ja einfach nur "set env_presence home" aufrufen können. Will also das DOIF-Device einfach nur wie einen Dummy verwenden können. Hat mMn also erstmal nichts mit den DOIF-Bedingungen zu tun.

Per

Du kannst bei set nur Befehle setzen, die DOIF auch kennt. Im GGsatz zum Dummy, der erstmal jedes set akzeptiert hat.
Und bekannt sind neben den alten wie initialize jetzt neu cmd_1, cmd_2 usw. (so sie auch existieren). home kennt DOIF nicht.
Ein Lichtschalter kennt auch nur on und off, nicht aber home oder hgdskjas.

vbs

Genau aus dem Grund gibt es ja das Attribut "setList", was ich ja auch gesetzt habe. Damit dann dem Device die Werte bekannt sind, die man zu setzen gedenkt. Klappt bei einem Dummy auch wunderbar.

Wenn ich nochmal mich selbst mit der ursprünglichen Fehlermeldung zitieren darf, da sieht manm dass DOIF ja sogar von sich aus sagt, dass er nun "home", "away" und "sleep" kennt:
Zitatunknown argument home for env_presence, choose one of disable initialize enable cmd away home sleep

Per

Entweder du nutzt setList und die alte set-Variante oder cmd_X und die neue. Mischen impossible.

Damian

#6
Das set-Kommando home usw. wird ja abgesetzt, allerdings weiß DOIF nicht, was er damit machen soll. Wenn du einen bestimmten Befehlszweig damit ausführen willst, dann musst du noch die Zuordnung zu den Kommandos definieren. Das kannst du über eventMap machen, z. B.

attr di_tt eventMap /cmd_1:home/cmd_2:sleep/cmd_3:away/

Du kannst auch Zustände definieren, die es nicht gibt, die dann auch keine Kommandos ausführen, aber den Zustand des Moduls verändern:

attr di_tt eventMap /cmd_4:home/cmd_5:sleep/cmd_6:away/

Die kannst du dann über das Attribut cmdState auf andere Namen umbiegen.

Mit dem Attribut devStateIcon kannst du wiederum weiter z. B. Icons definieren
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

vbs

Ich wollte eigentlich gar keine Logik dahinter haben bzw. wollte auch gar keine Zweige o.ä. ausführen. Ich wollte wirklich nur (wie bei einem dummy), dass der Wert als state übernommen wird und entsprechend ein Event generiert wird.
Geh ich recht in der Annahme, dass ich damit einfach etwas auf dem Holzweg bin? Vermutlich sollte ich das wieder trennen in ein DOIF + ein separaten Dummy.

Damian

Zitat von: vbs am 15 Februar 2017, 16:53:07
Ich wollte eigentlich gar keine Logik dahinter haben bzw. wollte auch gar keine Zweige o.ä. ausführen. Ich wollte wirklich nur (wie bei einem dummy), dass der Wert als state übernommen wird und entsprechend ein Event generiert wird.
Geh ich recht in der Annahme, dass ich damit einfach etwas auf dem Holzweg bin? Vermutlich sollte ich das wieder trennen in ein DOIF + ein separaten Dummy.

Das Problem ist, dass Dummy keine interne Zustandsverwaltung hat. DOIF aber schon. D.h. intern wird der Zustand nicht über den Status, sondern über bestimmte Readings: cmd, cmd_nr, verwaltet. home hat aber keine Nummer, deswegen muss man beim DOIF das über eventMap abbilden. Das ist zumindest der aktuelle Stand des Moduls. Man könnte ggf. automatisch weitere Zustandsnummern vergeben, aber das ist bisher nicht programmiert.

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

vbs

Ok, danke euch trotzdem. Vielleicht ist die Idee auch sowieso nicht so gut, den Zustands-Dummy und seine Logik in ein Gerät zu packen, keine Ahnung. Andererseits wirds auch nicht übersichtlicher, wenn man für eine Logik 3 Geräte + Perl-Code braucht...

Ellert

#10
Mir stellt sich die Frage, was der Dummy für eine Aufgabe hatte bevor er ins DOIF gewandert ist.

Das Reading state kann einen beliebigen Wert annehmen mit setreading state env_presence <wert>, dazu benötigst Du die setList nicht. Der Wert wird allerdings bei jedem Schaltvorgang überschrieben.

Wenn Dir aber wichtig ist übers Frontend state zusetzen geht es mit einem zusätzlichen DOELSEIF-Zweig und cmdState

([env_presence:transition] eq "leaving" or [$SELF:dummy] eq "away")
DOELSEIF ([env_presence:transition] eq "arriving"  or [$SELF:dummy] eq "home") (set env_f_justCameHome on-for-timer 300)
DOELSEIF ([$SELF:dummy] eq "sleep")

und die Attribute
readingList transition dummy
setList dummy:away,home,sleep
webCmd dummy
cmdState away|home|sleep

vbs

Der Dummy ist wirklich ganz plump der Anwesenheitsstatus, also ein Dummy, das einfach den Wert home, sleep oder away annimmt (noch etwas Transistionslogik drumrum). Klar, ich kann mit setreading u.ä. beliebig irgendwo "reingreifen", aber das ist mir schon etwas zu "low-levelig". Ich möchte schon gerne straightforward auf das Device zugreifen mit Value("") und co, sonst wird mir das zu kryptisch.
Werde dann einfach bei einem normalen Dummy bleiben, danke!

Ellert

So wie ich es in Dein DOIF eingebaut habe wird state gesetzt und Du könntest auch mit Value darauf zugreifen, wenns aber schon läuft besteht ja auch keine Notwendigkeit es zu ändern.

vbs

Verstehe es erst jetzt richtig, ehrlich gesagt. Das cmdState ist ja sehr genial, denk ich! Allein damit wird ja aus dem DOIF schon ein kleiner Dummy. Das setList ist dann eigentlich nur wichtig, damit Frontends die möglichen Befehle auslesen könne, oder?
Danke für den nochmaligen Hinweis! Habe gerade sehr viele Idee, wo ich das einsetzen kann!

Ellert

Die ursächliche Idee war, die benutzereigenen Readings im DOIF direkt im Frontend zusetzen, ohne zwischen geschalteten Dummy.