Problem beim Schalten mehrer HomeMatic-Rollladenschalter Bl1PBU-FM

[Damian]

Hallo,

ich habe mein Haus mit MomeMatic Rollladenschaltern Bl1PBU-FM ausgestattet, soweit so gut.

Im Wohnzimmer sind es vier, die gleichzeitig herunter bzw. herauf gesteuert werden. Diese habe ich über room-Attribut dem Raum "Wohnzimmer" zugeordnet.

Mit dem Befehl: "set room=Wohnzimmer on" werden alle vier über notify bzw. at-Befehl angesteuert.

Nun zum Problem:

Beim Auslösen des Befehls werden die ersten drei Aktoren zügig ausgeführt, der vierte Aktor kommt entweder nicht durch oder mit einer Verzögerung von ca. 1 Sekunde.

Um herauszufinden, ob es am vierten Rolladenaktor lag, habe ich die Aktoren umbenannt, so dass alphabetisch ein anderer als letzter dran kam.

Das Problem wiederholte sich wieder beim letzten vierten Aktor, der ja jetzt an anderer ist. Es liegt also nicht am Aktor, sondern an fhem und HM-Protokoll.

Meine Vermutung ist, dass bei der schnellen Befehlsabfolge etwas im Funkverkehr (bei HM mit Rücksendekanal) schief geht.

Meine Notlösung sieht z. Zt. so aus:

set Rolladen_1 on;sleep 0.1;set Rolladen_2 on;sleep 0.1;Rolladen_3 on;sleep 0.1;set Rolladen_3 on

 

Auf diese Weise werden die Rollläden sauber geschaltet, das "Klicken" der Aktoren hört man nun gleichmäßig in kurzen Abständen.

Fhem läuft bei mir unter ActivPerl auf einem Windowsrechner mit HM-LAN-Adapter. Ein Fhem-Update habe ich vor ca. einer Woche gemacht.

Frage an Rudolf: Wäre es nicht sinnvoll, eine definierbare Verzögerung beim Senden von Gruppen wie "set room=Wohnzimmer on" einzubauen, ohne dass das System zwischendurch "schlafen" muss?

Gruß

Damian

 

[fhem-hm-knecht]

ich bin zwar nicht der Rudi :)

http://groups.google.com/group/fhem-users/browse_thread/thread/8b5f15406f1bd534/4cfa71e43fcdeda8?lnk=gst&q=structur+hmlan+#4cfa71e43fcdeda8

da hat er schonmal geantwortet

hary

[Damian]

Am Montag, 24. September 2012 17:07:38 UTC+2 schrieb fhem-hm-knecht:

ich bin zwar nicht der Rudi  :)

http://groups.google.com/group/fhem-users/browse_thread/thread/8b5f15406f1bd534/4cfa71e43fcdeda8?lnk=gst&q=structur+hmlan+#4cfa71e43fcdeda8

da hat er schonmal geantwortet

hary

Danke für die Info hary,

der voreingestellte Wert war bei HMLAN 0,03. Das ist meiner Meinung nach viel zu wenig. Der Vorschlag von Rudi war auch 0,3 und nicht 0,03.

Ab 0,3 funktioniert es dagegen gut.

Das sollte man dringen anpassen, sonst wird es oft Probleme geben, wie z. B. im Nachbar-Thread.

https://groups.google.com/forum/?fromgroups=#!topic/fhem-users/5kB6mSJ2c5I 

Gruß

Damian

  

[meesus]

Hallo Damian,

ich hatte ja das gleiche Problem wie du.
Rudi hat mir dann den Tip gegeben den entsprechenden Eintrag testweise
"haendisch" hochzusetzten und den Wert, wo es bei mir funktioniert,
hier mitzuteilen. Das habe ich dann gemacht. G.Funk hatte für sich
einen anderen Wert gefunden. Vermutlich hat Rudi dann den Wert von
G.Funk übernommen. Ich hatte aber nochmal explizit darauf hingewiesen
das nur der 0,3er bei mir funktioniert.

Vieleich wird es ja jetzt geändert..


Gruß Micha

On 24 Sep., 20:04, Damian <damian.sordy...@gmail.com> wrote:
> Am Montag, 24. September 2012 17:07:38 UTC+2 schrieb fhem-hm-knecht:
>
>
>
> > ich bin zwar nicht der Rudi  :)
>

> >http://groups.google.com/group/fhem-users/browse_thread/thread/8b5f15...

>
> > da hat er schonmal geantwortet
>
> > hary
>
> > Danke für die Info hary,
>
> der voreingestellte Wert war bei HMLAN 0,03. Das ist meiner Meinung nach
> viel zu wenig. Der Vorschlag von Rudi war auch 0,3 und nicht 0,03.
>
> Ab 0,3 funktioniert es dagegen gut.
>
> Das sollte man dringen anpassen, sonst wird es oft Probleme geben, wie z.
> B. im Nachbar-Thread.
>

> https://groups.google.com/forum/?fromgroups=#!topic/fhem-users/5kB6mS...
>
> Gruß
>
> Damian

[Rudolf Koenig]

> Ich hatte aber nochmal explizit darauf hingewiesen das nur der 0,3er bei mir
> funktioniert.

Das habe ich wohl uebersehen. Ich habe jetzt 0.3 uebernommen, bitte nochmal
testen und Probleme melden. Koennt ihr bitte auch pruefen, ob eine HM-CC-TC
Konfiguration damit besser klappt?

[meesus]

Danke Rudi für die Umsetztung. Wie gesagt mit 0.3 kein Problem.
Leider kann ich mit HM-CC-TC nicht testen. Das Ding würde ich nicht
vorbei an meiner Frau ins WZ bekommen.. lol
Warte noch darauf das die MAX Komponenten den Weg in das FHEM finden.

Gruss Micha

[fhem-hm-knecht]

Hust........

Hary

[elo]

Das Ding gewinnt auch den Negativ Design Avard der letzten 10 Jahre!

[Martin]

Hallo,

eigentlich haette ich gerne eine andere Loesung. Die verzoegerung von .3sec ist doch mittlerweile erheblich.

Zum einen hat die neue (noch nicht in SVN, ... aber ich bindran) CUL_HM hier einige Verbesserungen. So wird ein Device nicht mehr zugemüllt sondern es wird auf ACKs gewartet - und die Behandlung mehrere Kanaele eines device wird sequenzielisiert. Damit habe ich erst einmal keine Probleme mehr mit einem Device.

als 2. sollte der repeat machanismus greifen - den habe ich auch angepasst.

Falls moeglich haette ich gerne eien Beschreibung deines tests - bei mir sind alle 2 Rollos ohne Probleme gefahren.
Und wenn du die neue Version testen willst - mit der einstellung 0.03 ! waere ich sehr an denTrace interessiert

Gruß
Martin

[Damian]

Hallo Martin,

ich nehme an, dass du mich gemeint hast;)

Wenn du mir deine Version zukommen lässt und mir genau sagst, was ich einstellen soll, dann kann ich die Sache testen.

Bei 2 Rollos wäre mir auch kein Problem aufgefallen, das Problem bei 0.03 sec. hat sich bei mir, wie oben beschrieben, erst beim vierten Rollladen hochgeschaukelt.

Gruß

Damian

[Martin]

Hallo Daniel,

ich habe noch einmal meine 4 Rollos getesten - alle 4, ohne sleep. HMLAN auf 0.03.
Alle 4 laufen ohne Probleme auf und zu und wieder auf.

HMLAN hat m.E. kein Problem mit 0.03, und ein Setzen auf 0.3 beseitigt nur ein Syptom - mit Nebenwirkungen.Wenn du jetzt 4 Lichter gleichzeitig einschalten willst kannst du ein delay von 1.2sec nicht mehr verhindern - das ist sichtbar und unschön.

Meine Version ist jetzt in SVN version 1906 - und sollte mit update kommen
Wuerde mich freuen, wenn du es noch mal testen kannst - und noch mehr wenn es auch bei dir funktioniert.
=> beim Test natürlich HMLAN auf 0.03 setzen!

Gruß
Martin

[Rudolf Koenig]

> Meine Version ist jetzt in SVN version 1906 - und sollte mit update kommen

Hab fhemupdate nochmal angestossen.

[Damian]

Hallo Martin,

ich heiße zwar nicht Daniel, aber da es hier im Thread keinen Daniel gibt, nehme ich auch diesmal an, dass du mich meinst;)

Ich weiß nicht genau, wie die bisherige Logik bei HM_LAN programmiert ist. Z. B.:

Wird der Status ausgewertet und eine Wiederholung bei Fehlermeldung durchgeführt und wenn ja wie oft?

Was regelt bei nicht korrekter Übertragung der HM-LAN-Adapter und was das HM_LAN-Modul?

Wird der nächste Aktor angesteuert, bevor der vorherige abgearbeitet wurde?

Dass es bei Dir funktioniert und bei mir definitiv nicht, liegt wahrscheinlich an unterschiedlichen Testbedingungen.

was mir auf Anhieb einfällt:

-Geschwindigkeit der Hardware, auf der FHEM läuft

-Qualität der Übertragung: Wenn bei mir eine Wiederholung stattfindet, wegen Fehlermeldung und bei dir nicht.

-Unterschiedliche Betriebssysteme

-Unterschiedliche Perl-Versionen

usw.

Bei mir läuft unter Windows das Update nicht. Wenn ich die 1906-Version  finde, kann ich sie bis zu 13 Rollladen-Aktoren testen und dir ein Feedback geben.

Es war mal bei mir mit 0.03 sec so heftig, dass nicht nur ein Aktor in der Viererkette nicht ausgelöst hat,  sondern er so "zerschossen" war, dass er noch nicht mal mehr auf Tastendruck funktionierte, auch ein Reset am Resetknopf funktionierte nicht mehr, ich musste ihn von der Stromversorgung trennen, um ihn wiederzubeleben. Mit 0.3 sec hatte ich dieses Phänomen noch nicht gehabt. Ob es tatsächlich an 0.03 sec lag, kann ich natürlich nicht beweisen.

Gruß

Damian

[Martin]

Hallo Damian

ich heiße zwar nicht Daniel, aber da es hier im Thread keinen Daniel gibt, nehme ich auch diesmal an, dass du mich meinst;)

sorry

Ich hoffe, der Update hat mittlerweile funktioniert.
Klar gehen die Testbedingungen ein- ich benutze die 7390.

Die Verzoegerung um .3s ist immer nur ein workaround weil das Problem nicht verstanden wurde. Klar ist, das damit die Moeglichkeit der präzisen Zeitgleichheit weiter erschwert wird...
Bin sehr gespannt auf deinen test - und die Traces.

Gruß
Martin

[Damian]

Hallo Martin,

ich habe über den Umweg - Fritzbox - ein aktuelles updatefhem gemacht, da mein FHEM unter Windows läuft. Ich sehe dort u. A. ein stark geändertes 10_CUL_HM.pm-Script. Sind das deine Änderungen?

Welche Art von Log brauchst du?

Sag mir Bescheid, bevor ich mit dem Test loslege.

Gruß

Damian

[Martin]

Hallo Damian,

korrekt, das sind die Aenderungen.

wenn du "inform on" und "inform timer" setzt sollten die Messages ausgegeben werden - mit Zeitstempel.

Dann eben deine 4 (oder mehr) rollos ansteuern - und loggen.

Natuerlich ein Test mit timer auf 0.03.
Und wenn du schon dabei bist noch einen mit timer 0.3 zum Vergleich

Danke
Martin

[Damian]

Hallo Martin,

ich habe das neue Script CUL_HM bereits seit gestern mit 0.03 sec laufen - bisher ohne Probleme:)

Manchmal werden bestimmte Aktoren trotzdem (hörbar am Klicken) verzögert ausgelöst, womöglich finden dann Wiederholungen statt.

Im Anhang findest du die dazugehörigen Traces mit kurzer Zustandsbeschreibung mit 0.03 sec und 0.3 sec.

Ich lasse es bei mir erstmal auf 0.03 sec, mal schauen, ob es noch Probleme gibt.

Gruß

Damian

[Martin]

Hallo Damian,

danke, werde die Traces noch durchsehen.
Sicher hast du schon an die Alternative gedacht - devicepair.
Das Prinzip ist klar: mit einem schalter gleichzeitig mehrere Aktoren steuern. Muss noch testen - aber es ist dann auch nur eine Message.
Problem: man will ja nicht immer alle Rollos steuern.
Ich plane einen virtuellen Schalter in FHEM - also eine beliebige Anzahl virtueller Buttons. Diese kann man mach belieben pairen. Des weiteren kann man das schaltverhalten in jedem Aktor auf jeden Schalter nahezu beliebig einstellen. Einziges Problem ist die uebersicht zu behalten :-)
Wenn du wirklich zeitsynchron sein willst ist dies sowieso die einzige Moeglichkeit! Selbstverstaendlich kann HM auch definierte verzoegerungen - also ein Kommando, licht1 an, 2sec licht 2 an,... endlos

Interessiert dich das? Ist es bekannt?
Gruss Martin

[Damian]

Hallo Martin,

danke für die Infos.

Für die Tests habe ich alle 13 Aktoren per set group=Rollladen on/off gesteuert.

Normalerweise brauche ich nicht alle Rollos gleichzeitig anzusprechen.

Die Sache mit den virtuellen Buttons finde ich interessant.

Für´s Wohnzimmer habe ich mir eine FS20-Fernbedienung (HM-Fernbedienungen finde ich zu überteuert) zugelegt und kann per notify sowohl einzelne Rollos, als auch alle vier gleichzeitig per zugeordnete Tasten steuern.

Um Grunde funktioniert die Sache mit folgendem Kommando (hier am Beispiel aller Rollos im Wohnzimmer):

define R_Wohnzimmer_alle notify R_Wohnzimmer set room=Wohnzimmer %

wobei R_Wohnzimmer on/off -Taste der FS20-Fernbedienung ist.

Es hat aber den entscheidenden Haken, wie bereits im Nachbar-Thread erläutert, dass man damit die Rollos nicht stoppen kann, sondern immer nur rauf (on) oder runter (off) ansteuert. Beim längeren Halten der Taste hat man sogar in dem Fall das Problem, dass ein Dimm-Befehl geschickt wird, der zu Fehlermeldung beim Rollladenaktor führt.

Eleganter wäre natürlich das Verhalten so nachzubilden, wie es direkt am Schalter funktioniert, nämlich mit der Option des Stopps und zwar nur mit on/off-Befehl, wie an der Wippe des Schalters.

 

Die Frage stellt sich für mich, ob man so etwas in CUL_HM einbauen kann?

Gruß

Damian

[Stetanchi]

Die Frage stellt sich für mich, ob man so etwas in CUL_HM einbauen kann?

Hallo Damian,

so wie ich Martin verstanden habe ist das lösbar, indem mann einige Register der Rolladenaktoren neu beschreibt, dann bleiben diese bei erneuten "on" oder "off" Kommando stehen.

Ich wühl mich gerade durch das PDF Dokument indem die Register beschrieben sind. Das mit den Zeiten für Rauf und runter fahren habe ich schon mal verstanden, aber wie das Verhalten zum Stoppen der Rolladen zu ändern ist noch nicht...

Ich studier mal weiter... :-)

Viele Grüße, Stefan. 

[Stetanchi]

Hallo Damian,

ich habe gerade die stelle im aktuell erweiterten PDF Dokument gefunden.

--> http://fhem.de/Heimautomatisierung-mit-fhem.pdf

Auf Seite 52 unten...

Ich vermute stark, dass dies die Konfiguration von Martin ist :-)

So nun mal sehen ob und wie ich die Register beschrieben bekomme...

VG, Stefan

[Martin]

Damian,

Dir stehen fuer das Rollo die Befehle on, off und stop zur verfügung. Wie du dies auf events von FS20 mappen kannst dir ueberlassen. Evtl kannst du bein ersten drücken ein on schicken, beim 2. ein stop und beim 3. ein hoch.

Basteln kann man auch anderes. Du kannst diene DS20 schalter auf die Virtuellen HM schalter mappen (ich habe sie bei mir am laufen;-) und somit die Funktionen von HM benutzen (die endlos sind, bei Rollos).
Schwierig ist das lange Tasten druecken... geht aber generell. Es haengt dnnsehr von diener FS20 ab.....

Gruß
Martin

[Damian]

Hallo Martin,

danke erstmal für die Tipps.

Die zweite Lösung mit virtuellen HM-Schaltern gefällt mir wesentlich besser. Gibt es zu den virtuellen HM-Schaltern schon eine Doku?

Denn sonst müsste ich, um das Verhalten einer Wippe nachzubilden, erstmal den Zustand Rollladen_läuft_noch abfragen (wenn es überhaupt geht), um beim Richtungswechsel den Stopp-Befehl abzusetzen.

Der Zustandsautomat der Default-Einstellung der Rollladenaktoren für kurzen Tastendruck, sieht ja so aus:

Hier nur die Fälle aufgelistet, die eine Zustandsveränderung verursachen:

Rollladen:aus und Aktion: hoch, dann Rollladen hoch

Rollladen: läuft hoch und Aktion: runter, dann Rollladen stopp

Rollladen:aus und Aktion: runter, dann Rollladen runter

Rollladen: läuft runter und Aktion: hoch, dann Rollladen stopp

Gruß

Damian

[Martin]

Hallo Damian,

ich hatte zu Beginn meiner Aktivitaeten einmal ein bisschen dokumentiert - gerade den BL.
Schau mal in
http://fhem.de/Heimautomatisierung-mit-fhem.pdf
so gegen ende ist HM und der BL etwas beschrieben

Hier nur die Fälle aufgelistet, die eine Zustandsveränderung verursachen:

Rollladen:aus und Aktion: hoch, dann Rollladen hoch

Rollladen: läuft hoch und Aktion: runter, dann Rollladen stopp

Rollladen:aus und Aktion: runter, dann Rollladen runter

Rollladen: läuft runter und Aktion: hoch, dann Rollladen stopp

dein Vorschlag ist der Standard -wenn du nur kurz drueckst. Das Verhalten hast du ja direkt an der Wippe des Bl1PBU.
Wenn du eine Fernbedienung anlernst (devicepair) mit 2 Tasten (option dual) dann arbeiten sie exact wie die Wippe.

Meines habe ich uebrigens geaendert, da ich Jalousien habe und die Steuerung der Schraegstellung sehr praezise sein muss hat mir folgendes besser gefallen:

Rollladen:aus und Aktion: hoch, dann Rollladen hoch

Rollladen: läuft hoch und Aktion: EGAL , dann Rollladen stopp

Rollladen:aus und Aktion: runter, dann Rollladen runter

Rollladen: läuft runter und Aktion: EGAL, dann Rollladen stopp

So, das alles ist noch unabhaengig von virtuellen Schaltern. Diese musst du definieren und angeben, wieviele Tasten du simulieren willst. Dann machst du eine devicepair genau wie bei realen Schaltern - ein schalter mehrere Aktoren, ein Aktor mehrere Schalter.....
Zum Schaltern hast du dann den Befehl 'press' oder 'press long' - also set <buttonname> press
Einziger Unterschied ist 'long'. Bei einem realen Schalter kannst du auf den Knopf bleiben und der Befehl wird entsprechend lange wiederholt. Virtuell habe ich dies nicht, deshalb kommt nur einmal long.

Mit deiner FS20 remote kannst du nun sinngemaess folgendes Aufsetzen
FS20Key1Event =>notify : vrituellBtn1 press
FS20Key2Event =>notify : vrituellBtn2 press
und deine FS20 ist quasi ein HM remote - fuer kurzes Druecken.
Falls die FS20 auch lange druecken kann,... musst du testen
Gruss
Martin

 

Gruß

Damian

[Damian]

Hallo Martin,

ich habe nun deine neue Doku und die neue commandref studiert.

Ich habe bei mir nun ein virtuelles Device definiert:

set vRemote CUL_HM 100000

set vRemote virtual 10

R_Dachboden ist bei mir ein bereits definierter Rollladenaktor mit DevID 19638C

nun führt:

set vRemote_Btn1 devicepair 0 R_Dachboden

sowie

set vRemote_Btn1 devicepair 0 19638C

oder 

set vRemote_Btn1 devicepair 0 19638C01

zu einer Fehlermeldung:

"not a CUL_HM device"

Daraufhin habe ich definiert:

define testhm CUL_HM 19638C01

nun klappt auch: 

set vRemote_Btn1 devicepair 0 testhm

allerdings führt: 

set vRemote_Btn1 press

oder

set vRemote_Btn2 press

zur keiner Reaktion beim Rollladen R_Dachboden.

Habe ich da noch etwas falsch verstanden?

Gruß

Damian

[Martin]

Hallo Damian

Am Freitag, 5. Oktober 2012 20:30:00 UTC+2 schrieb Damian:

Hallo Martin,

ich habe nun deine neue Doku und die neue commandref studiert.

Ich habe bei mir nun ein virtuelles Device definiert:

set vRemote CUL_HM 100000

define vRemote CUL_HM 100000
 

set vRemote virtual 10

gehts dann?

Gruss
Martin

[Damian]

Hallo Martin,

es war natürlich ein define, sonst hätte ich die Buttons nicht definieren können.

Ich habe wohl gemerkt, dass der Status des Aktors NACK liefert.

Gruß

Damian

[Damian]

Am Samstag, 6. Oktober 2012 18:07:25 UTC+2 schrieb Damian:

Hallo Martin,

es war natürlich ein define, sonst hätte ich die Buttons nicht definieren können.

Ich habe wohl gemerkt, dass der Status des Aktors NACK liefert.

Gruß

hier nochmal ein Auszug von R_Dachboden

DEF	19638C
HMLAN_MSGCNT	4
HMLAN_RAWMSG	R36DE9EE3,0001,431A7016,FF,FFCB,7E800219638C26026584
HMLAN_RSSI	-53
HMLAN_TIME	2012-10-06 18:18:10
LASTIODev	HMLAN
MSGCNT	4
NAME	R_Dachboden
NR	34
STATE	NACK
TYPE	CUL_HM
lastMsg	No:7E - t:02 s:19638C d:260265 84

[Martin]

Hallo Damian,

Habe es gerade noch einmal getestet. Bei mir funktioniert es bis auf ein Problem
=> die defaults bei devicepair sind noch falsch

also besser
set vRemote_Btn1 devicepair 0 R_Dachboden dual set

ausführen.

Aber die Fehlermeldung mit CUL_HM prüft nur ob R_Dachboden existiert und als TYPE CUL_HM besitzt.
Sind da irgendwelche steuerzeichen drin?

Nach den devicepair kannst du
set R_Dachboden getdevicepair
ausführen. Da sollte dann vRemote_Btn1 stehen

Der default steht auf unset, mein fehler - also noch mal mit set explizit

Gruss
Martin

[Damian]

Hallo Martin,

mit:

set vRemote_Btn1 devicepair 0 R_Dachboden dual set 

klappt das devicepair schon mal.

set R_Dachboden getdevicepair

liefert

DEF	19638C
HMLAN_MSGCNT	10
HMLAN_RAWMSG	E19638C,0000,466E5FC3,FF,FFCC,B4A01019638C26026501100000021000000100000000
HMLAN_RSSI	-52
HMLAN_TIME	2012-10-07 09:48:35
LASTIODev	HMLAN
MSGCNT	10
NAME	R_Dachboden
NR	34
STATE	getdevicepair
TYPE	CUL_HM
lastMsg	No:B4 - t:10 s:19638C d:260265 01100000021000000100000000

soweit so gut.

set vRemote_Btn2 press

fährt bei mir den Rollladen hoch.

ein

set vRemote_Btn1 press

müsste den Rollladen, bei meiner Default-Einstellung der Aktors, während der Fahrt wieder stoppen

und ein wiederholtes

set vRemote_Btn1 press

den Rollladen wieder runter fahren.

Beides funktioniert bei mir aber nicht.

Erst nach einer gewissen timeout-Zeit lässt sich mit

set vRemote_Btn1 press

der Rollladen tatsächlich wieder runter fahren.

Das ist aber nicht im  Sinne des Erfinders.

Gruß

Damian

[Martin]

Hallo Damian,

wird korrigiert

Martin

[Martin]

probier 1935.Defaults sollten stimmen und Press auch ohne wartezeit.

Offen ist noch das Speichern der peerlist bei Save - operationell aber (noch) kein problem - solange die Acks nicht gezaehlt werden

[Damian]

da muss ich wohl auf das nächtliche Update warten und über Wiki Dhs-Link laden; Oder wie komme ich schneller an die 1935-Version? Der Umweg mit updatefhem über Fritzbox ist mir auf die Dauer zu umständlich. 

Gruß

Damian

[Martin]

das file steht in SVN
http://fhem.svn.sourceforge.net/viewvc/fhem/trunk/fhem/FHEM/10_CUL_HM.pm?revision=1935&pathrev=1935

[Damian]

Hallo Martin,

gute Arbeit!

Jetzt funktioniert´s, wie es soll.

Was mir noch aufgefallen ist:

Wäre es nicht sinnvoll beim Definierten der virtuellen Buttons mit set vRemote virtual ... auch gleich die Standardaktion press  in der web-Darstellung automatisch zu definieren? So wie on bzw off bei FS20-Schaltaktoren.

Sieht sonst recht spartanisch aus:

CUL_HM

vRemote_Btn1 ? vRemote_Btn2 ? vRemote_Btn3 ? vRemote_Btn4 ? vRemote_Btn5 ? vRemote_Btn6 ? vRemote_Btn7 ? vRemote_Btn8 ? vRemote_Btn9 ?

Ich werde es für meine FS20-Fernbedienung sowieso per notify schalten, daher habe ich mir die Press-Buttons per webCmd in erster Linie zum Testen definiert.

CUL_HM vRemote_Btn1 ? press vRemote_Btn2 ? press

Gruß

Damian

[Martin]

Hallo Damian

gute Arbeit

danke

Wäre es nicht sinnvoll beim Definierten der virtuellen Buttons mit set vRemote virtual ... auch gleich die Standardaktion press  in der web-Darstellung automatisch zu definieren? So wie on bzw off bei FS20-Schaltaktoren.

sicher - aber da habe ich noch nicht gearbeitet. Ich bin mit dem CUL_HM noch nicht zufrieden. Neben den Problemen mit dem TC sind noch andere Fragen offen (sichern der device-config, flags bei matic devices, komplettes auslesen der deviceconfig mit einem klick getConfig ist noch nicht komplett, evtl alarm handling und config sanity check).  Mal sehen wie weit ich komme....

Gruss
Martin