Um die Kanäle A&B meiner unidirektionalen EnOcean Wippen zu trennen habe ich zwei readingsProxys erschaffen, die dann über structures mit den unidirektionalen EnOcean Rolladenschaltern verbunden sind. Zum Steuern verwende ich dann die structures.
Bei direktem Kommando an die readingsProxys gibt es folgenden Fehler:
Unknown argument AI, choose one of A0:noArg AI:noArg B0:noArg BI:noArg C0:noArg CI:noArg D0:noArg DI:noArg released
Leider ändert sich die Webanzeige der readingsProxys nicht beim Schalten, sondern bleibt auf dem alten Zustand der Wippen hängen. Der Zustand der Wippe (!) ändert sich erwartungsgemäß. Im Logfile steht dann:
2015.08.08 18:02:40 3: EnOcean set KU_Rolladen A0
2015.08.08 18:02:40 3: EnOcean set EZ_SW_Rolladen A0
2015.08.08 18:02:41 2: TCM unknown ORG mapping for 58
Warum ändert sich der state der readingsProxys nicht?
Warum nimmt er keine Kommandos an?
Inhalt des beschriebenen readingsProxy:
Internals:
DEF EZ_SW_Rolladen:channelA
DEVICE EZ_SW_Rolladen
NAME KU_Rolladen_prx
NR 195
NTFY_ORDER 50-KU_Rolladen_prx
READING channelA
STATE on
TYPE readingsProxy
Content:
EZ_SW_Rolladen 1
Readings:
2015-08-08 17:41:59 lastCmd A0
2015-08-08 15:32:05 state AI
Attributes:
eventMap AI:on A0:off BI:on B0:off
room Rolladen,hidden
setFn ($CMD eq "AI")?"on":"off"
setList AI A0 on off
valueFn ($VALUE eq "on")?"AI":"A0"
webCmd on off
Ich suche schon seit mehreren Tagen - bitte helft mir.
Ich habe leider ein paar Probleme den Sachverhalt zu verstehen.
Warum legst Du das readingsProxy nicht so, wie hier http://www.fhemwiki.de/wiki/EnOcean_Starter_Guide#Virtuelle_Schalter_f.C3.BCr_unidirektionale_Aktoren beschrieben an?
Hast Du per readingsProxy im Aktor(?) angelernt? Ist Aktor bei Dir gleich Schalter?
Wie sieht das Ursprungs-Device von dem readingsProxy abgeleitet wird aus (list)?
Das ist übrigens merkwürdig:
2015.08.08 18:02:41 2: TCM unknown ORG mapping for 58
Edit:
Glaube habe Deinen Sachverhalt/Problem doch noch besser verstanden, hoffe ich zumindest ;):
Fhem-Device, das am Aktor angelernt ist, und readingsProxy als Ableitung vom physischen Tasterkanal hast Du in eine structure gepackt wie in http://www.fhemwiki.de/wiki/EnOcean_Starter_Guide#Physischer_EnOcean-_und_virtueller_Fhem-Schalter_zu_einem_Device_zusammenfassen beschrieben.
Das dient aber "nur" der Anzeige; schalten musst Du weiterhin in Fhem ausschließlich über das im Aktor angelernte Fhem-Device. Das readingsProxy-Device kannst Du nicht zum Schalten nutzen, da es eine Ableitung von einem Sensor ist und der stellt eben keine set-Befehle zur Verfügung.
Ich selbst habe die structure-Variante nie genutzt, sondern ausschließlich die auch unter dem genannten Link aufgeführte notify-Variante "nAbgleich". Vorteil von structure habe ich bisher noch nicht verstanden. Kann aber auch an mir liegen.
Am Besten stellst Du EnOcean-Fragen im entsprechenden EnOcean-Forum, da lesen mehr EnOcean-User mit. Das hier ist auch ein EnOcean-Spezialfall; kannst das auch dorthin verschieben.
danke für die Fragen. Ich hoffe das klärt die Unklarkeiten auf:
Das readingsProxy spiegelt bei mir keinen Aktor, sondern einen sensor (die Schalterwippe). Damit musste ich einiges im Gegensatz zum StarterGuide ändern, aber im Prinzip habe ich mir diese Anleitung dafür vorgenommen.
Ich hätte mich auch nicht weiter darum gekümmert, wenn nicht in unregelmäßigen Abständen das readingsProxy des Sensors ohne Betätigung des deselben aktualisiert und damit auch die structure wieder in den alten Wert zurückfallen würde (interessanterweise ohne dabei den Aktor mitzunehmen).
Zitat von: BenMarloe am 08 August 2015, 21:52:23
(interessanterweise ohne dabei den Aktor mitzunehmen).
Ok, meine habe es bis auf obigen Zusatz verstanden. Der Aktor kann doch durch readingsProxy nicht geschaltet werden!?
Dein Problem suche ich gerade erst einmal bei
readingsProxy:
Habe Dein readingsProxy mal bei mir ausprobiert und kann auf Anhieb keine Fehlfunktion feststellen. Bin aber über einige Attribute, weil ich die für überkomplex halte, verwundert. Muss das noch mal in Ruhe testen und probieren.
Eventuell hat auch Andre (justme1968) direkt eine Idee (Andre liest Du mit? :) ).
Hilfreich wäre vermutlich noch ein list des Sensors (Schalterwippe) lieferst.
Wenn die structure fehlerhafterweise zurückfällt schaltet sie den Aktor (Rolladen) _nicht_ mit.
Meine Schalterwippe (Sensor) sieht so aus:
IInternals:
DEF 001B2FEB
IODev TCM_ESP2_0
LASTInputDev TCM_ESP2_0
MSGCNT 6
NAME EZ_SW_Rolladen
NR 179
NTFY_ORDER 50-EZ_SW_Rolladen
STATE AI
TCM_ESP2_0_MSGCNT 6
TCM_ESP2_0_TIME 2015-08-08 15:29:19
TYPE EnOcean
Readings:
2015-08-08 15:29:19 buttons released
2015-08-08 15:29:19 channelA AI
2015-08-08 12:37:12 channelB B0
2015-08-08 23:49:16 state AI
Attributes:
IODev TCM_ESP2_0
group button
room EG_WZ,EnOcean,Rolladen
subType switch
Es kann sein, dass ich den readingsProxy bei meiner Fehlersuche etwas komplexer gemacht habe als unbedingt notwendig.
Bedenke bitte, dass ich auch den Channel B habe und in gleicher Weise bearbeite. Evtl. macht das eine oder andere (Umsetzung auf on/off) bei Channel A keinen Sinn, ist aber bei Channel B nicht überflüssig.
Danke dass Du Dich meines Problems annimmst.
Irgendwie habe ich noch ein Verständnisproblem bei Deinem Sachverhalt, so dass ich Dir keine direkte Lösung anbieten kann. :-[
Hinweise:
Beim readingsProxy sind valueFn und setFn Perl-Aufrufe. Die Funktionen der Attribute gehören in {}. Das funktioniert zwar interessanterweise auch ohne, aber produziert Warnungen im Log und was das für Seiteneffekte hat, kann ich gar nicht überblicken.
Deine readingsProxy-Attribute verwirren mich, wie gesagt. Wenn ich das readingsProxy folgendermaßen anlege, dann macht das für mich mehr Sinn, da Dein Ursprungsdevice für readingsProxy doch mit A0 und AI Schalten signalisiert (->valueFn):
Internals:
CFGFN
DEF EZ_SW_Rolladen:channelA
DEVICE EZ_SW_Rolladen
NAME channelA
NR 374
NTFY_ORDER 50-channelA
READING channelA
STATE off
TYPE readingsProxy
Content:
EZ_SW_Rolladen 1
Readings:
2015-08-09 03:16:51 lastCmd off
2015-08-09 03:09:22 state off
Attributes:
room EnOcean
setFn {($CMD eq "on")?"AI":"A0"}
setList on off
userattr room_map structexclude
valueFn {($VALUE eq "AI")?"on":"off"}
Wofür man im readingsProxy-Device für den Sensor, den man sowieso nicht schalten kann, überhaupt eine setFn und setList nutzen sollte ist mir nicht klar. Eigentlich sollte es für Deine Zwecke doch reichen nur die passende valueFn zu definieren. Für den anderen Kanal (channelB) wäre das readingsProxy analog einzurichten.
Hoffe, dass die Anmerkungen Dir wenigstens ein wenig helfen.
Danke - Du hast natürlich recht und ich habe die readingsProxys vereinfacht, da es ja sowieso nicht funktioniert.
Ich bin dem Problem auf der Spur!
Hauptursache all der Umständlichkeiten ist, dass die structures wieder auf Wert der readingProxys zurück fällt, obwohl die readingsProxys (und deren Sensorquelle, die Wippen) nicht geändert wurden.
Ich habe eben herausgefunden, dass das passiert wenn man
- ein readingsProxy kopiert
- eine structure kopiert
- fhem.cfg editiert & speichert
- FHEM neu startet (einziger wirklich logischer Fall)
nicht passiert wenn man:
- ein structure DEF ändert
- config abspeichert
- ein readingsProxy Attribute ändert
Bug oder Feature?
Bitte! Ist das so gedacht, dass bei jeder Änderung an der fhem.cfg (also auch ein define <device> at <event> <command>) die ReadingProxys wieder zurück fallen? Das ist bei mir nachvollziehbar!
Zitat von: BenMarloe am 22 August 2015, 22:44:06
Bitte! Ist das so gedacht, dass bei jeder Änderung an der fhem.cfg (also auch ein define <device> at <event> <command>) die ReadingProxys wieder zurück fallen? Das ist bei mir nachvollziehbar!
Verstehe ich nicht. Wann und wieso sollte jede Änderung an fhem.cfg Auswirkungen auf ein readingsProxy haben? Kannst Du das an (d)einem Beispiel darstellen?
Ausgangslage wie in Bild1. Alle stc von hand auf off gestellt. Dann löst ein notify ein define at aus:
WG_Rolladen:A0|WG_Rolladen:AI define at_wgrolladen_released at +00:00:05 set WG_Rolladen released; {
Log 1, "Wg_Rolladen_released: at defined"
}
Anschliessen nehmen alle stc wieder den Zustand der notify ein (Bild2). Ist auch im Event Monitor sichtbar!
2015-08-22 23:24:05 structure AZ_Rolladen_stc on
2015-08-22 23:24:05 readingsProxy AZ_Rolladen_prx on
2015-08-22 23:24:05 structure BAD_Rolladen_stc off
2015-08-22 23:24:05 readingsProxy BAD2_Rolladen_prx off
2015-08-22 23:24:05 structure BAD_Rolladen_stc off
2015-08-22 23:24:05 readingsProxy BAD_Rolladen_prx off
2015-08-22 23:24:05 structure DZ_Rolladen_stc off
2015-08-22 23:24:06 readingsProxy DZ2_Rolladen_prx off
2015-08-22 23:24:06 structure DZ_Rolladen_stc off
2015-08-22 23:24:06 readingsProxy DZ_Rolladen_prx off
2015-08-22 23:24:06 structure EZ_Rolladen_stc off
2015-08-22 23:24:06 readingsProxy EZ_Rolladen_prx off
2015-08-22 23:24:06 structure KU_Rolladen_stc on
2015-08-22 23:24:06 readingsProxy KU_Rolladen_prx on
2015-08-22 23:24:06 structure SZ_Rolladen_stc on
2015-08-22 23:24:06 readingsProxy SZ2_Rolladen_prx on
2015-08-22 23:24:06 structure SZ_Rolladen_stc on
2015-08-22 23:24:06 readingsProxy SZ_Rolladen_prx on
2015-08-22 23:24:06 readingsProxy WG_Rolladen_prx off
2015-08-22 23:24:06 structure WZ_Rolladen_stc off
2015-08-22 23:24:06 readingsProxy WZ_Rolladen_prx off
2015-08-22 23:24:06 EnOcean WG_Rolladen on
2015-08-22 23:24:06 structure WG_Rolladen_stc on
2015-08-22 23:24:10 structure WG_Rolladen_stc released
2015-08-22 23:24:10 EnOcean WG_Rolladen released
2015-08-22 23:24:10 structure AZ_Rolladen_stc on
2015-08-22 23:24:10 readingsProxy AZ_Rolladen_prx on
2015-08-22 23:24:11 structure BAD_Rolladen_stc off
2015-08-22 23:24:11 readingsProxy BAD2_Rolladen_prx off
2015-08-22 23:24:11 structure BAD_Rolladen_stc off
2015-08-22 23:24:11 readingsProxy BAD_Rolladen_prx off
2015-08-22 23:24:11 structure DZ_Rolladen_stc off
2015-08-22 23:24:11 readingsProxy DZ2_Rolladen_prx off
2015-08-22 23:24:11 structure DZ_Rolladen_stc off
2015-08-22 23:24:11 readingsProxy DZ_Rolladen_prx off
2015-08-22 23:24:11 structure EZ_Rolladen_stc off
2015-08-22 23:24:11 readingsProxy EZ_Rolladen_prx off
2015-08-22 23:24:11 structure KU_Rolladen_stc on
2015-08-22 23:24:11 readingsProxy KU_Rolladen_prx on
2015-08-22 23:24:11 structure SZ_Rolladen_stc on
2015-08-22 23:24:11 readingsProxy SZ2_Rolladen_prx on
2015-08-22 23:24:11 structure SZ_Rolladen_stc on
2015-08-22 23:24:11 readingsProxy SZ_Rolladen_prx on
2015-08-22 23:24:11 structure WG_Rolladen_stc off
2015-08-22 23:24:11 readingsProxy WG_Rolladen_prx off
2015-08-22 23:24:11 structure WZ_Rolladen_stc off
2015-08-22 23:24:11 readingsProxy WZ_Rolladen_prx off
hat aber keine Auswirkungen auf echte Schalteraktivität - Rolläden bleiben wie sie sind..
Tritt Event "released" im <device>:<reading> von dem das readingsProxy abgeleitet wurde auf? Falls ja: kann es sein, dass Event "released" im readingsProxy nicht bzw. nicht richtig in der entsprechenden valueFn-Funktion berücksichtigt wurde?
Ja - ist beides der Fall. Was sollte ich im readingsProxy auch mit der Information anfangen? Anzeigen will ich sie ja nicht und auslesen ist auch langweilig.. :-\
Was wäre denn das richtige Vorgehen?
Habe jetzt ein wenig den Überblick verloren, wie Dein derzeitiger Code-Stand ist.
Aber Du musst vermutlich Deine valueFn entsprechend anpassen. Bei der valueFn
{($VALUE eq "AI")?"on":"off"}
führt "released" nach meinem Verständnis eben zum state "off".
ja das stimmt.
Aber da die Definition der Proxys
EZ_SW_Rolladen:channelA
die Releases bereits filtert funktioniert es trotzdem.
Versuchshalber habe ich mal die Funktion umgeschrieben in:
{ my $ret=""; if ($VALUE eq "AI") { $ret = "on"; } if ($VALUE eq "A0") { $ret = "off"; } return $ret;}
Aber die Structure fällt trotzdem zurück
Internals:
ATTR room
DEF room EZ_Rolladen_prx EZ_Rolladen
NAME EZ_Rolladen_stc
NR 192
NTFY_ORDER 50-EZ_Rolladen_stc
STATE on
TYPE structure
Content:
EZ_Rolladen A0
EZ_Rolladen_prx on
Readings:
2015-08-30 21:15:58 LastDevice EZ_Rolladen_prx
2015-08-30 21:15:58 LastDevice_Abs EZ_Rolladen_prx
2015-08-30 21:15:58 state on
Attributes:
clientstate_behavior last
eventMap AI:on A0:off BI:on B0:off
room EG_WZ,Rolladen
off topic: Warum löscht ValueFn meine returns im Code?!
Du schaffst mich ;)
Kann Dich vermutlich mit weiteren Fragen quälen, bin aber nicht sicher, ob es hilft. Habe den Überblick bei Deinem Vorgehen verloren :-[.
ZitatWarum löscht ValueFn meine returns im Code?!
Kann vermutlich nur Andre (oder anderer Entwickler) beantworten....
Bitte (!) quäl mich! :P
Wenn einer der Entwickler drauf sieht möchte ich nicht etwas ganz Dummes gemacht zu haben und dann noch die Entwicklung FHEM aufhalten.
Struktur ist so:
Schalterwippe -> ReadingsProxy -> Structure <-> Virtueller Schalter -> Rolladenschalter
| ^
------------------------------------------------------------------------------------|
Für mich erstaunlich ist aber, dass die Structure prima funktioniert, bis irgendwas in die fhem.cfg schreibt. Dann, und nur dann wird das Readingsproxy erneut ausgelesen und die structure fällt auf den Zustand den Readingsproxys zurück, auch wenn der virtuelle Schalter oder die Structure später geschaltet wurden.
Aber ich verstehe, wenn Dir das Thema langweilig wird. :(
Zitat von: BenMarloe am 30 August 2015, 21:58:31
Aber ich verstehe, wenn Dir das Thema langweilig wird. :(
Mir ist es nicht langweilig. Habe nur die Befürchtung, dass ich etwas nicht erkenne/erkannt habe und darum im Nebel stochere.
Habe jetzt durch Deine "Skizze" die Struktur (wieder?) erkannt und frage mich, wie fhem.cfg schreiben mit structure zusammenhängt!?
Wirklich bei jedem Schreiben von fhem.cfg? Auch wenn Du ein Attribut bei einem unbeteiligten Device änderst und speicherst?
Es bleibt wie am 9.8. geschrieben. Readings ändern ändert nichts. Bin am Ende - habe keine Ahnung was das sein könnte.
Ich werde versuchen jetzt erst mal alle anderen Fehler zu bekämpfen.