PTM200 EasyClick zwei Icons für Channel A und B

[Timmy.m]

Hallo zusammen,

ich habe nun auch einen Busware EUL TCM310 an meiner Fritz!Box 7390.
Mein Enocean Easyclick Dualrolladenschalter PTM200 überträgt zuverlässig die Telegramme für Channel A (A1,A0) und Channel B (B1,B0).
Leider ist mir bisher mit der FHEM nicht gelungen beide Rolllädenstellungen als Icon darzustellen.
Vielleicht kann mir jemand helfen?

Grüße Tim

[klaus.schauer]

Hallo zusammen,

ich habe nun auch einen Busware EUL TCM310 an meiner Fritz!Box 7390.
Mein Enocean Easyclick Dualrolladenschalter PTM200 überträgt zuverlässig die Telegramme für Channel A (A1,A0) und Channel B (B1,B0).
Leider ist mir bisher mit der FHEM nicht gelungen beide Rolllädenstellungen als Icon darzustellen.
Vielleicht kann mir jemand helfen?

Grüße Tim

Ich verstehe die Anforderung noch nicht genau. Sollen die empfangenen Daten der Easyclick Dualrolladenschalter visualisiert werden oder soll Fhem die Rollos steuern?

Falls Fhem die Rollos steuern soll, bitte Fhem mit dem subType manufProfile am Aktor anlernen. Weitere Infos gibt's in der commandref unter Manufacturer Specific Applications (EEP A5-3F-7F), Shutter. Viele Beispiele inzwischen im Forum.

[Timmy.m]

Entschuldige bitte für meine schlechte Beschreibung und Danke für die Antwort!

Ich möchte den Rollozustand in der Raumdarstellung (nicht im Floorplan... kommt bestimmt später mal) visuell darstellen.
Bisher klappt es nur mit Channel A oder Channel B des Doppelschalters.
Ich möchte jedoch ein Icon für Channel A und ein Icon für Channel B, welches mir den Zustand des Rollo anzeigt.

Funktioniert für ein Channel:
attr RoloKueche devStateIcon B0.*:shutter_open BI.*:shutter_closed

Ich habe bereits das Folgende versucht, um zwei Icons zu bekommen, jedoch mache ich bestimmt einen Syntaxfehler oder ähnliches:

attr RoloKueche devStateIcon A0.*:shutter_open AI.*:shutter_closed B0.*:shutter_open BI.*:shutter_closed

Grüße Tim

[justme1968]

du kannst mit dieser version von devStateIcon den STATE des devices auf genau ein icon mappen. um deine beiden rollaeden unabhängig voneinander anzuzeigen musst du als erstes ein icon erzeugen das die vier möglichen kombinationen aus auf und zu darstellt. dann kannstdu mit der {} version von devStateIcon die zustände von a und b zum jeweiligen icon namen verknüpfen und zurückgeben.

eine andere möglickeit wären zwei dummys in die du per notify jeweils den zustand ein von a bzw. b kopierst. dann hast du zwei devices und kannst ganz normal jedem sein eigenes icon verpassen.

gruss
  andre

[rudolfkoenig]

Z.Zt gilt in FHEMWEB: Ein Geraet -> ein Status -> ein Bild.
Das geht auch ohne {}, man muss aber fuer alle (4?) Kombinationen (AI,BI AI,B0 A0,BI A0,B0) ein Icon zuordnen
(und da z.Zt keine Kombi-Icons gibt, erstmal welche bauen)

Mit {} kann man auch zwei Bilder zurueckliefern, das ist aber bestimmt kein Einzeiler mehr, und muesste in eine Funktion ausgelagert werden.

Ich glaube die Einfachste z.Zt. ist die von andre vorgeschlagene dummy-Loesung

Heute wuerde ich das PTM in FHEM anders implementieren, und fuer jedes 4 FHEM-EnOcean Geraete anlegen (jeweils eins fuer die Kanaele A,B,C,D).

@andre: ich denke ueber ein clone-Modul nach, bei dem die Instanz alle Readings/sets/gets des Originals, aber seine eigenen Attribute/Internals und damit STATE haben wuerde.
Was ist deine Meinung dazu?

[justme1968]

auch mit {} ist es noch ein einzeiler wenn man die icons geschickt benennt. dann muss man nur den A und B zustand aneinander hängen und als icon namen verwenden. wenn beide schon im STATE stehen geht es natürlich auch ohne {} oder mit stateFormat. ich kenne das device um das es geht nicht. immer vorausgesetzt man hat sich die vier icons gebastelt.


zum clone device:

das clone modul wäre dann im prinzip eine erweiterte readingsGroup mit der möglichkeit wie in der structure die set und get weiter zu reichen.

vielleicht ist es aber verwirrend wenn man z.b. je einen clone für a und b anlegt und dann b immer noch über den a clone bedienen kann.

wenn man die readings wirklich kopiert ginge STATE automatisch per stateFormat. es wäre nur schhön wenn man das auch hin bekommt ohne die readings wirklich ins clone device zu kopieren.

[rudolfkoenig]

Andre, ich glaube wg. dem PTM sind wir beide auf dem Holzweg: das PTM ist _ein_ Geraet mit 2 Wippen: A+B. Wenn man oben links drueckt, dann kommt AI, unten links A0, oben rechts BI, unten rechts B0. Man kann auch oben links _UND_ unten rechts gleichzeitig druecken, dann kommt AI,B0. Oben links und unten links gleichzeitig geht physikalisch nicht.

Das alte Status/Reading B0 verschwindet, wenn man A0 bekommt, auch wenn es ja logisch weiterhin gueltig ist: devStateIcon kann nicht wissen, was der Zustand der B-Wippe ist.

D.h. man muss zwei dummys bauen, und diese per notify steuern:

Code Auswählen Erweitern

define PTM EnOcean 123456
define PTM_A dummy
define n_A notify PTM:.*A.* { fhem("set PTM_A ".($EVENT=~m/AI/ ? "on" : "off") }
define PTM_B dummy
...


Clone Modul
> wenn man die readings wirklich kopiert ginge STATE automatisch per stateFormat.

Readings waere ein Zeiger auf das gleiche Hash, kopieren waere damit nicht notwendig, userReadings wuerde nicht funktionieren, genausowenig wie die event-* Attribute. Im NotifyFn wuerde ich im clone nur STATE kopieren, diesen kann man mit stateFormat ueberschreiben.

Man koennte das gleiche Geraet mehrfach in FHEMWEB/FLOORPLAN darstellen mit unterschiedlichen webcmd/icon/status. Wuerde fuer das hier genannte Fall aber auch nicht helfen. Seufz. Bin nicht mehr so sicher, ob es sinnvoll waere :)

[justme1968]

wenn es keine readings gibt die den status von beiden wippen halten dann ist es natürlich schwierig den status von beiden wippen anzuzeigen :)

ja. der dummy ist dann warscheinlich wirklich das beste.

oder ein userReading um aus state je ein reading für a und b zu machen das nicht verschwindet. hat leider das problem das die userReadings mit state nicht richtig funktionieren sondern immer ein event zu spät.

oder im notify nicht den dummy setzen sondern dort jeweils die a und b readings für das device erzeugen.

oder das modul so ändern das es a und b readings hat :)


mit den vielen einschränkungen würde das clone device glaube ich einige probleme bei den anwendern machen wenn manches dann doch nicht so geht wie erwartet (die event-* attribute, ...) und genau das was es tun soll dann nicht geht (unabhängig von der a/b problematik mit ptm)

vielleicht sollte man mal sammeln was so ein clone modul können soll und welche anwendungsfälle es löst.

[klaus.schauer]

wenn es keine readings gibt die den status von beiden wippen halten dann ist es natürlich schwierig den status von beiden wippen anzuzeigen :)

ja. der dummy ist dann warscheinlich wirklich das beste.

oder ein userReading um aus state je ein reading für a und b zu machen das nicht verschwindet. hat leider das problem das die userReadings mit state nicht richtig funktionieren sondern immer ein event zu spät.

oder im notify nicht den dummy setzen sondern dort jeweils die a und b readings für das device erzeugen.

oder das modul so ändern das es a und b readings hat :)


mit den vielen einschränkungen würde das clone device glaube ich einige probleme bei den anwendern machen wenn manches dann doch nicht so geht wie erwartet (die event-* attribute, ...) und genau das was es tun soll dann nicht geht (unabhängig von der a/b problematik mit ptm)

vielleicht sollte man mal sammeln was so ein clone modul können soll und welche anwendungsfälle es löst.

Jetzt bin ich total verstört 8.-) Seit mehreren Monaten gibt es im EnOcean-Modul die zusätzlichen Readings channelA, channelB usw., die die jeweiligen Kanalstati A0|AI, B0|BI usw. halten. Ab der nächsten Version wird immer der letzte Betätigungsstatus in buttons mit pressed|released ausgegeben. Damit sollte man eigentlich alle Schalterzustände wechselwirkungsfrei parat haben.

[justme1968]

nicht hauen :)

wie die information mit den kanälen ist von rudi.

ich hatte nur ganz oben beschrieben wie man das mit den icons hin bekommt wenn die information für die kanäle da sind:

-> 4 icons für die 4 möglichen kombinationen bauen und dann STATE mit stateFormat so passend machen das die namen für die icons dabei raus kommen.

gruss
  andre

[Timmy.m]

So, ich habe gestern Abend mit den beiden Dummy experimentiert.

D.h. man muss zwei dummys bauen, und diese per notify steuern:

Code Auswählen Erweitern

define PTM EnOcean 123456
define PTM_A dummy
define n_A notify PTM:.*A.* { fhem("set PTM_A ".($EVENT=~m/AI/ ? "on" : "off") }
define PTM_B dummy
...

Leider werden für den Enocean Stick keinerlei Auswertungen mehr gefahren, wenn die Dummys laufen.
Irgendwie scheint es, als wäre FHEM nur noch mit der Statusprüfung beschäftig.
Erst wenn die die Dummys raus nehme und FHEM neu starte, läuft die Enocean Auswertung wieder.

Gibt es noch einen Trick?

Ich sehe, dass nun für Channel A und für Channel B der jeweils letzte Zustand gespeichert wird. Wie kann ich denn nun für das DevStatIcon die beiden Kanäle abfragen?

[justme1968]

also zuerst die 4 icons mit den kombinierten zusähen basteln. diese dann so benennen das du mit stateFormat den STATE so mappen kannst das es zu den icon namen passst.

gruss
  andre

[klaus.schauer]

So, ich habe gestern Abend mit den beiden Dummy experimentiert.

D.h. man muss zwei dummys bauen, und diese per notify steuern:

Code Auswählen Erweitern

define PTM EnOcean 123456
define PTM_A dummy
define n_A notify PTM:.*A.* { fhem("set PTM_A ".($EVENT=~m/AI/ ? "on" : "off") }
define PTM_B dummy
...

Die Stati der einzelnen Kanäle werden in channelA, channelB bereit gestellt. Falls nicht, bitte Fhem "update" starten. Wahrscheinlich ist dann die neueste Version noch nicht installiert.

Leider werden für den Enocean Stick keinerlei Auswertungen mehr gefahren, wenn die Dummys laufen.
Irgendwie scheint es, als wäre FHEM nur noch mit der Statusprüfung beschäftig.
Erst wenn die die Dummys raus nehme und FHEM neu starte, läuft die Enocean Auswertung wieder.

Gibt es noch einen Trick?

Ich sehe, dass nun für Channel A und für Channel B der jeweils letzte Zustand gespeichert wird. Wie kann ich denn nun für das DevStatIcon die beiden Kanäle abfragen?

[rudolfkoenig]

@Timmy.m:

Ich habe einen Klammerfehler in meinem Notify, folgendes habe ich getestet (allerdings ohne TCM):

Code Auswählen Erweitern

define n_A notify PTM:.*A.* { fhem("set PTM_A ".($EVENT=~m/AI/ ? "on" : "off")) }


@klaus.schauer
Koenntest Du bitte in 00_TCM.pm MODEL vor der "none" Pruefung&return setzen, sonst bekommt man dauernd ein

Code Auswählen Erweitern

Use of uninitialized value in string eq at ./FHEM/00_TCM.pm line 604.

wenn man kein TCM zur Hand hat.

[Timmy.m]

Funktioniert wunderbar! Vielen Dank.

[justme1968]

ich hab eben hier http://forum.fhem.de/index.php/topic,16827.0.html eine erste version eines moduls gepostet mit dem sich teile aus einem device reading als neues device definieren lassen. mit eigenem state, eigenen icons, webCmd und eigenen set/get kommandos.

gruss
  andre