!!! Der aktuelle Stand ist unter Antwort 18 beschrieben !!!
Hallo,
folg. Zustand: (eigentlich viele) EnOcean 4-fach Taster, jeder der 4 Tasten steuert einen anderen Aktor (FAM12, alles unidirektional). FHEM hängt via FAM12RS232 mit auf dem Bus.
# der physikalische Schalter
define kueche.sw EnOcean 00253CE4
attr kueche.sw IODev FAM12RS232
attr kueche.sw comment EnO_switch_00253CE4
attr kueche.sw room EnOcean
attr kueche.sw subType switch
define FileLog_kueche.sw FileLog ./log/kueche.sw-%Y.log kueche.sw
attr FileLog_kueche.sw logtype text
attr FileLog_kueche.sw room EnOcean
(Um die 4 Taster im Webfrontend darstellen zu können, 4x readingsProxy je Schalter)
# zugeröriger readingsProxy
define kueche.licht.spots readingsProxy kueche.sw:state
attr kueche.licht.spots room Ansicht_1
attr kueche.licht.spots setFn {"A0"}
attr kueche.licht.spots setList on off
attr kueche.licht.spots valueFn {$LASTCMD}
attr kueche.licht.spots webCmd toggle
Funktioniert eigentlich, aber wenn ich mit dem physikalischen Schalter schalte, wechselt im Webfrontend das Lampen-Icon im readingsProxy nicht den Zustand.
Schalte ich direkt auf dem Icon des readingsProxy funktioniert dies.
Kann mir hier jemand weiterhelfen?
Danke.
Gruß,
Walter
Kann denn niemand helfen?
Hast Du das http://www.fhemwiki.de/wiki/EnOcean_Starter_Guide#Physischer_EnOcean-_und_virtueller_Fhem-Schalter_zu_einem_Device_zusammenfassen anlog probiert?
Ich habe es gelesen. Passt allerdings nicht ganz, da ich kein virtuelles device habe. Ich kann direkt mit der Kennung des Tasters schalten, da ich fhem nicht über Funk, sondern seriell über FAM12RS232 angebunden habe.
Ich betreibe also nur den physikalischen Schalter mit 4 readingsProxy.
Kannst du denn nicht mit einem notify auf Events A0 vom phys. Schalter reagieren und per setreading den Zustand vom readingsProxy Device entsprechend ändern? Habe es nicht probiert, aber vielleicht ist das ein Ansatz.
die version mit $LASTCMD in der valueFn ist für geräte die keine rückmeldung über den tatsächlichen status liefern.
wenn du eine rückmeldung bekommst musst du den readingsProxy auf das reading konfigurieren in dem die rückmeldung steht und valueFn so anpassen das dieses reading auf den zustand des readingsProxy umgesetzt wird.
gruß
andre
@justme1968 (andre):
Er toggelt mit A0 und bekommt keine Rückmeldung über den tatsächlichen Zustand. Darum wäre mein Ansatz, damit das readingsProxy immmer den richtigen Zustand hat, beim Toggeln mit dem phys. Schalter den Zustand vom Proxy mit einem notify auf phy. Schalterevents und setreading (auf state?) in den entgegengesetzten Zustand zu bringen: Wenn readingsProxy "on", dann auf "off" und umgekehrt. Keine Ahnung, ob das mit readingsProxy funktioniert; hab es nicht getestet.
dazu gibt das lastCmd reading im readingsProxy. hier 'merkt' sich der readingsProxy den aktuellen zustand. $LASTCMD ist nur eine abkürzung und wird automatisch über ReadingsVal gefüllt. ohne es selber aufrufen zu müssen.
es solle also möglich sein aus einem entsprechenden notify das lastCmd reading selber zu toggeln.
ich habe keine EnOcean devices und kann es nicht wirklich selber testen da ich das verhalten nicht wirklich verstehe :). könntet ihr einen 'simulator' aus drei normalen dummys und den passenden notifys bauen der sich so verhält wie das echte device? also einen dummy der einen zweifach taster in fhem repräsentiert und an den ich hinterher meinen readingsProxy hängen kann und zwei zusätzliche dummys die die lokale bedienung über die beiden tasten simulieren und den ersten dummy beeinflussen.
Danke für die vielen Rückmeldungen.
Kann jemand, basierend auf meinem Code, Codeschnipsel liefern?
Ich kenne den Guide, die commandref, Wiki, muss aber gestehen, dass ich damit nicht ganz klar komme.
Bitte testen und berichten:
define nProxyAbgleich notify kueche.sw:A0 {if (Value("kueche.licht.spots") eq "on") {fhem "setreading kueche.licht.spots lastCmd off"} else {fhem "setreading kueche.licht.spots lastCmd on"}}
Getestet: passt so 100%, danke vielmals.
Nun kann ich schonmal alle Schalter konfigurieren ...
Gibt es eigentlich einen einleuchtenden Grund, weshalb dies nicht automatisch passiert?
sollte man das noch im wiki ergänzen oder ist das ein sonderfall?
gruss
andre
Hallo Andre!
Ist nach meiner Meinung eigentlich ein Sonderfall; Wiki schadet aber nicht ;).
Wenn Du es nicht selbst machen möchtest, dann schreib ob es im Artikel zu readingsProxy oder EnOcean landen soll und ich kümmere mich darum.
Gruß, Christian
da ich die EnOcean spezislität immer noch nicht wirklich verstanden habe wäre es mit lieb wenn du die 1-2 sätze dazu schreiben kannst.
passen würde es zum EnOcean beispiel auf der readingsProxy seite.
wenn es von der EnOcean seite noch keine verlinkungen gibt wäre die vermutlich auch sinnvoll oder?
gruß
andre
Verlinkung ist immer inklusive ;). Kümmere mich in Kürze...
danke
Bitte wartet noch kurz, es passt leider trotzdem noch nicht.
Da das Verhalten schwierig zu beschreiben ist, bitte ich noch um etwas Geduld.
OK, dann habe ich aber vermutlich Dein Problem auch noch nicht verstanden. Du müsstest dann bitte noch weiter erläutern.
Also ich versuche es nochmal mit aktualisierter Beschreibung.
Folg. Zustand: (eigentlich viele) EnOcean 4-fach Taster, jeder der 4 Tasten steuert einen anderen Aktor (FAM12, alles unidirektional). Also Rechts oben drücken ändert den Zustand des Aktors/Lichts, war das Licht an ist es nun aus oder umgekehrt.
FHEM hängt seriell via FAM12RS232 mit auf dem Bus.
# der physikalische Schalter
define kueche.sw EnOcean 00253CE4
attr kueche.sw IODev FAM12RS232
attr kueche.sw comment EnO_switch_00253CE4
attr kueche.sw room EnOcean
attr kueche.sw subType switch
define FileLog_kueche.sw FileLog ./log/kueche.sw-%Y.log kueche.sw
attr FileLog_kueche.sw logtype text
attr FileLog_kueche.sw room EnOcean
(Um die 4 Taster im Webfrontend darstellen zu können, 4x readingsProxy je Schalter)
# zugehöriger readingsProxy1, Spots Küche
define kueche.licht.spots readingsProxy kueche.sw:state
attr kueche.licht.spots room Ansicht_1
attr kueche.licht.spots setFn {"BI"}
attr kueche.licht.spots setList on off
attr kueche.licht.spots valueFn {$LASTCMD}
attr kueche.licht.spots webCmd toggle
# zugehöriger readingsProxy2, Lampe Küchentisch
define kueche.licht.tisch readingsProxy kueche.sw:state
attr kueche.licht.tisch room Ansicht_1
attr kueche.licht.tisch setFn {"B0"}
attr kueche.licht.tisch setList on off
attr kueche.licht.tisch valueFn {$LASTCMD}
attr kueche.licht.tisch webCmd toggle
# zugehöriger readingsProxy3 und readingsProxy4 ähnlich mit weiteren Aktoren/Lampen.
Wenn ich im Webfrontend nun schalte, funktionieren die physikalischen Lampen und auch das Lampen-Icon des readingsProxy wechelt jedesmal den Zustand.
Wenn ich jedoch mit dem physikalischen Schalter schalte, wechselt im Webfrontend das Lampen-Icon des readingsProxy nicht den Zustand.
Bitte berücksichtigen: ein virtuelles FHEM-Device habe ich nicht bzw. wird nicht benötigt, da ich nicht über Funk, sondern über die serielle Schnitstelle des FAM12RS232 aufgeschaltet bin.
Nun kam der Vorschlag mit folgenden Notify's zu arbeiten:
define n.kueche.licht.spots notify kueche.sw:BI {if (Value("kueche.licht.spots") eq "on") {fhem "setreading kueche.licht.spots lastCmd off"} else {fhem "setreading kueche.licht.spots lastCmd on"}}
define n.kueche.licht.tisch notify kueche.sw:B0 {if (Value("kueche.licht.tisch") eq "on") {fhem "setreading kueche.licht.tisch lastCmd off"} else {fhem "setreading kueche.licht.tisch lastCmd on"}}
Damit kommt es zu eigenartigem und schwer nachvollziehbarem Verhalten, sowohl über den physikalischen Schalter als auch im Webfrontend funktioniert prinzipiell das Schalten, aber die Icons des readingsProxy ändern das Icon in Abhängigkeit vom Zustand, bei bestimmter History ändern sich beim Schalten eines Tasters beide Icons!
Kann es sein, dass man das Notify gar nicht braucht, da ja kein virtuelles device eingesetzt wird, sondern nur das richtige Attribut mit dem passenden Inhalt versehen muss?
Ich hoffe ich habe das Problem verständlich beschrieben ...
Ich klinke mich mal gaanz vorsichtig ein...
- mit physikalischem Schalter meinst Du einen normalen Enocean Taster (Sensor, z.B. PTM210/PTM215 )?
- Dein Aktor ist auf dem RS485 Bus?
- Wie hasst Du dann den Aktor mit dem Taster verknüpft?
- Eventuell muss der FAM12 noch konfiguriert werden dass er den Enocean Funk über RS232 weiterleitet? (Kenne FAM12 nicht - ich habe nur FAM14)
Grüße, Norbert
ZitatDamit kommt es zu eigenartigem und schwer nachvollziehbarem Verhalten, sowohl über den physikalischen Schalter als auch im Webfrontend funktioniert prinzipiell das Schalten, aber die Icons des readingsProxy ändern das Icon in Abhängigkeit vom Zustand, bei bestimmter History ändern sich beim Schalten eines Tasters beide Icons!
Genau das wäre aber interessant zu wissen.
Eigentlich hätte ich erwartet, dass das readingsProxy immer den richtigen Zustand zeigt und schalten über Proxy und Schalter funktionieren.
Mein Verständnis:
Der phys. Taster=Aktor schaltet mit A0, AI, B0 ,BI
Jeder dieser Befehle steuert genau einen Aktor und wechselt dessen Zustand (toggeln)
Aus den erzeugten Events lässt sich nicht erkennen, ob der Aktor gerade an oder aus ist.
Vielleicht lieferst Du mal eine Eventlist des Tasters.
ZitatKann es sein, dass man das Notify gar nicht braucht, da ja kein virtuelles device eingesetzt wird, sondern nur das richtige Attribut mit dem passenden Inhalt versehen muss?
Ja, kann sein. Ich habe aber noch keine Idee welches. Deshalb so auseinanderpflücken, dass auch Nicht-EnOcean-User (Andre!) das verstehen können.
Und bitte Norberts Dinge abarbeiten....
Zitat- mit physikalischem Schalter meinst Du einen normalen Enocean Taster (Sensor, z.B. PTM210/PTM215 )?
Ja, PTM210
Zitat- Dein Aktor ist auf dem RS485 Bus?
Ja, alle Aktoren sind direkt auf dem RS485 Bus
Zitat- Wie hasst Du dann den Aktor mit dem Taster verknüpft?
Enocean eingelernt, Neubau, nur Enocean Schalter, funktionieren alle
Zitat- Eventuell muss der FAM12 noch konfiguriert werden dass er den Enocean Funk über RS232 weiterleitet? (Kenne FAM12 nicht - ich habe nur FAM14)
FAM12RS232 hat noch eine serielle Schnittstelle, die Signale des RS485 werden hier automatisch ein/ausgeleitet. Ich habe ja automatisch darüber die Schalter/Switches ins FHEM eingelernt. http://www.eltako.com/fileadmin/downloads/de/Datenblatt/FUNK_datenblatt_FAM12.pdf
Von meinem Verständnis, sollte eigentlich kein Notify nötig sein.
Zitat
Mein Verständnis:
Der phys. Taster=Aktor schaltet mit A0, AI, B0 ,BI
Jeder dieser Befehle steuert genau einen Aktor und wechselt dessen Zustand (toggeln)
Aus den erzeugten Events lässt sich nicht erkennen, ob der Aktor gerade an oder aus ist.
Genau so ist es, man sieht nur das "toggeln" und weiss nur dass der Zustand gerade wechselt, d.h. es muss beim Start eine "Initialisierung", in einen definierten Zustand, stattfinden.
OK, verstanden. D.h. Du sendest mit der gleichen ID wie der Encoean Taster. Da bin ich dann mal raus - hier müssen wohl Experten weiterhelfen.
Gruß, Norbert
Begreife es nicht. Bei meinen Tests mit PTM210 und einem readingsProxy funktioniert das Vorgehen mit dem notify. Da ich aber keine 12er-Reihe nutze, sollte der Fehler dort irgendwo liegen. Wenn keine anderen Ideen kommen, hätte ich zum Weitergrübeln gerne:
- "list" der von Dir mit den Attributen dargestellten Devices
- log mit verbose 5, wenn notify aktiv ist und Du Taster sowie readingsProxy auslöst. Bitte für 2 Aktoren eines Tasters.
Alles ohne Erfolgsversprechen, bin auch kein Experte. Aber derzeit fehlen mir einfach die Infos, da ich aus Deiner Fehlerbeschreibung keine Rückschlüsse ziehen kann.