Toggle-Taste soll Status zyklisch weiterschalten

[BeetleX]

OK, jetzt muss ich doch mal tiefer ansetzen:

Mein System basiert zum größten Teil auf FS20-Komponenten mit der Besonderheit des Subsystems FS20_Manager (im weitesten Sinne ähnlich FHZ1000, jetzt leider obsolet). Besteht aus 868MHz Rx/Tx, und über I2C 32 Relais-Ausgänge. Das ist der harte Kern meiner Hausanlage: solange der Atmel seinen Dienst tut, ist die Grund-Überlebensfunktionalität im Haus gesichert.

FHEM ist als Komfort-Erweiterung seriell angekoppelt. Ich habe mehr schlecht als recht das Modul 00_FS20Manager.pm zusammengebastelt. Bin leider kein Perl-Experte. Auf meine Nachfrage wurde damals CUL oder FHZ als Vorlage empfohlen. Habe CUL gewählt, nach meinem heutigen Verständnis wäre wohl FHZ besser gewesen.

Sicher werden hier die falschen toggle Einträge erzeugt. Ich hänge verschämt das Modul mal an. Mein Plan wäre jetzt, das aktuelle FHZ1000 als Vorlage zu nehmen und noch mal anzufangen. Bin für jeden Tipp zur Platzierung der seriellen I/O dankbar, da mir die grundsätzlichen Wege der Events durch System nicht klar sind.

[rudolfkoenig]

Ich kann z.Zt. noch nicht vorstellen, dass dieses Modul (00_FS20MANAGER.pm) die Ursache des 3-fach Triggerns ist. Das 3 in Klammern ist die Laenge der CHANGED Array, und das wird von readingsSingleUpdate() in FS20.pm gefuellt. Ich kann mir nicht vorstellen, wie FS20_Parse() mehr als einen Eintrag pro Funknachricht/FS20 Instanz reinschreiben soll.

dupTimeout betrifft nur die von unterschiedlichen Geraeten empfangene Nachricht, z.Bsp wenn man 2+ CULs einsetzt. Dass man nur eine Nachricht empangen hat, sieht man an dem Log.

Es sei denn, FS20.pm wurde auch modifiziert: solche Sachen spaeter zu erwaehnen ist nicht gut, da das Vertrauen dann schnell hinueber ist.

[BeetleX]

Nein, FS20.pm ist nicht angerührt. Wenn es nicht an meiner falschen Implementation im FS20Manager Modul liegt, dann vielleicht am Verhalten des FS20Manager-Geräts: der serielle Kanal wurde nur auf meine Nachfrage hin ergänzt. Er spiegelt einfach Funk und seriellen Kanal. Ich vermute, dass ein serielles Kommando an den FS20Manager auch über seinen Funk gesendet und nochmals dort und vom CUL empfangen wird. Egal, was dort passiert, das Gerät ist fix und nicht mehr änderbar.
Ich würde nun einfach ein paar tracking Logeinträge einfügen, um mehr zu sehen.

[BeetleX]

hier ist die Ausgabe

Code Auswählen Erweitern


2015.12.22 21:59:44 5: Triggering EG_Decke (3 changes) dim62% RSSI: -27.5 RAWMSG: 810b04xx0101a0015a5f12000a


erzeugt durch

Code Auswählen Erweitern


my @hhh = @{$hash->{CHANGED}};
Log 5, "Triggering $dev ($max changes) @hhh";


Heisst das, dass FS20Manager dim, RSSI und RAWMSG an FS20_Parse fälschlicherweise als als 3 Events verkauft? Bitte um Nachsicht, ich hab mangelnden Durchblick...
Ich habe mal das Log angehängt.

[rudolfkoenig]

Ich gehe davon aus, dass du addvaltrigger gesetzt hast.
In diesem Fall wird RSSI und RAWMSG zum Liste der Events hinzugefuegt.

[BeetleX]

ja, addvaltrigger ist gesetzt.
Ich wollte mit der Ausgabe eigentlich die 3 Inhalte von CHANGED sehen, sehe aber nur ein event 3-teilig - oder?

[Cybers]

defmod n notify Taste set Dimmer {(Each("Dimmer","off,dim25%,dim50%,dim75%,dim100%"))}

Das hat mich nach langem Suchen endlich weiter gebracht. Jetzt möchte ich aber statt "dim25%"wie in dem Beispiel folgendes haben um zwischen verschiedenen Farben umschalten zu können:

Code Auswählen Erweitern

hsv 62,83,100
Leider wird das Komma beim HSV-Wert als Trennzeichen in der Auflistung (ist auch klar) interpretiert und demnach stimmt dann der HSV-Befehl nicht. Wie kann ich den HSV-Wert in richtig mit Komma maskieren?

Gruß, Sascha

[rudolfkoenig]

Each() nimmt einen optionalen dritten Parameter, den Separator. Default ist ","

[Cybers]

Each() nimmt einen optionalen dritten Parameter, den Separator. Default ist ","

Das verstehe ich leider nicht.

Mein Code soll quasi so aussehen damit mit jedem Tastendruck die Farbe wechselt (erst HSV 63,82,100 dann HSV 120,60,100 und dann HSV 180,80,100:

Code Auswählen Erweitern

Taster2.4_sKurzerLangerDruck:trigger set LED_Kueche {(Each("LED_Kueche","HSV 63,82,100,HSV 120,60,100,HSV 180,80,100"))}

[rudolfkoenig]

Code Auswählen Erweitern

Taster2.4_sKurzerLangerDruck:trigger set LED_Kueche {(Each("LED_Kueche","HSV 63,82,100;HSV 120,60,100;HSV 180,80,100", ";"))}

[Cybers]

Super, Danke! Jetzt habe ich den Aufbau verstanden. Läuft auch.
Jetzt habe ich noch eine Kleinigkeit:
Mit Longpress schalte ich das Device aus. Mit dem ersten Shortpress möchte ich den ersten HSV-Wert, mit dem zweiten Shortpress den zweiten Wert, usw. Momentan schaltet er mit dem ersten Shortpress nach einem Longpress den nachfolgenden Wert der vor dem Longpress eingestellt war.
Ist das möglich?

Gruß Sascha

[rudolfkoenig]

Der Longpress muss  dafuer $defs{$dev}{EACH_INDEX} zuruecksetzen.

[Cybers]

Danke für deine schnelle Antwort. Damit kann ich jetzt gerade gar nichts anfangen. Ich versuche mich gleich mal da rein zu basteln.

Gruß Sascha

[Cybers]

Der Longpress muss  dafuer $defs{$dev}{EACH_INDEX} zuruecksetzen.

Trotzt langer Suche und verschiedener Versuche habe ich keine Lösung finden können wie ich den Wert eines Internals ändern kann. Hast du noch einen Tip für mich?

Gruß, Sascha

[rudolfkoenig]

Code Auswählen Erweitern

define n notify Taster2:Longpress { $defs{LED_Kueche}{EACH_INDEX}=0 }
Bitte Regexp anpassen, ich kenne die HomeMatic Events nicht.