Gerätekonfiguration als sub ablegen

Begonnen von wkarl, 01 Juli 2013, 08:29:03

Vorheriges Thema - Nächstes Thema

wkarl

Hallo,

aktuell bastle ich an unserer Markisensteuerung. Dazu habe ich mir in 99_MyUtilsConfig.pm folgendes zurechtgelegt, da ich das ganze nicht immer per Hand eingeben muss.
MarkiseAktorCfg() {
    my $actor = "Markise";
    my $remote01 = "Schalter_Terasse_Btn_01";
    my $remote02 = "Schalter_Terasse_Btn_02";
    { fhem ("set $actor regSet shBlJtOff rampOn $remote02") };
    { fhem ("set $actor regSet shBlJtDlyOn no $remote02") };
    { fhem ("set $actor regSet shBlJtRefOn rampOn $remote02") };
    { fhem ("set $actor regSet shBlJtRampOn on $remote02") };
    { fhem ("set $actor regSet shBlJtOn refOn $remote02") };
    { fhem ("set $actor regSet shBlJtDlyOff no $remote02") };
    { fhem ("set $actor regSet shBlJtRefOff no $remote02") };
    { fhem ("set $actor regSet shBlJtRampOff no $remote02") };
    #
    { fhem ("set $actor regSet shBlJtOff no $remote01") };
    { fhem ("set $actor regSet shBlJtDlyOn no $remote01") };
    { fhem ("set $actor regSet shBlJtRefOn no $remote01") };
    { fhem ("set $actor regSet shBlJtRampOn no $remote01") };
    { fhem ("set $actor regSet shBlJtOn refOff $remote01") };
    { fhem ("set $actor regSet shBlJtDlyOff no $remote01") };
    { fhem ("set $actor regSet shBlJtRefOff no $remote01") };
    { fhem ("set $actor regSet shBlJtRampOff no $remote01") };
    #
    { fhem ("set $actor regSet shCtValHi 100 $remote01") };
    { fhem ("set $actor regSet shCtValLo 255 $remote01") };
    { fhem ("set $actor regSet shCtValHi 100 $remote02") };
    { fhem ("set $actor regSet shCtValLo 255 $remote02") };
    #
    { fhem ("set $actor getConfig") };
}

Der Inhalt ist noch nicht fertig. Also stört Euch bitte nicht daran.

Die Frage ist, ist dies im Sinne von fhem? Ich sehe nähmlich einige NACKs im log, während des Durchlaufs.

Danke schon mal.
ciao walter
FHEM 5.7 & TabletUI 2.2 auf Fedora22 Server auf NUC5i5RYK
CUL 868 > FAST EnergyCam
HMLAN > HomeMatic TCs & VDs, Bewegungsmelder, Schalter, Taster, Steckdosen

martinp876

Hallo Walter,

Es sollte so funktionieren, aber nur, wenn du den Aktor schon mit dem Button gepeert hast. ggf einmal roh-logs schicken.

Ueber "templates" habe ich auch schon nachgedacht - Also Treppenhausschalter also ein Kommando - habe es aber noch nicht in einer user-freundlichen Form.

Generell kannst du aber auch eine 2. Moeglichkeit ins Auge fassen:
1) programmiere einen Aktor nach deinem Gusto
2) mache "get <aktor> saveConfig"
3) im generierten File hast du fuer diesen Aktor (besser diesen Channel) ein peerBulk und ein (mehrere) "set regBulk". Suche den mit "List 3" deines gewuenschten peers.

Wenn du nun diese Funktion kopieren willst, also das gleiche Verhalten dieser Aktor/peer kompination auf einen anderen Aktor/peer uebertragen willst kannst du:
Orginal:
set RolloW peerBulk 00000000,11000105,11000106,18208307,18208308,1BCE2801,1BCE2802,
set RolloW regBulk .RegL_03:FB_Btn_07  01:00 02:00 ......


fuehre folgendes aus:
set Rollo<next> peerBulk 00000000,<HMIdBtn1>,<HMIdBtn2>,<HMIdBtn3>,
set Rollo<next> regBulk .RegL_03:<HMIdBtn1>  01:00 02:00 ......
set Rollo<next> regBulk .RegL_03:<HMIdBtn2>  01:00 02:00 ......
set Rollo<next> regBulk .RegL_03:<HMIdBtn3>  01:00 02:00 ......

Die Registerliste natuerlich jeweils vom 'known-good-sample' kopieren.

Kopieren sollte man nur innerhalb gleicher Aktor-Typen
Vorteil - geht viel schnellern und geraeuschloser. Viel weniger Messages.

Gruss Martin



wkarl

Hallo,

aktueller Zwischenstand.


(siehe Anhang / see attachement)

    Ausgangslage: Markise vollkommen eingefahren.
    Drücken Btn_02: Markise fährt aus.
    Drücken Btn_02: Markise stoppt.
    Drücken Btn_02: Markise fährt weiter aus.
    Drücken Btn_01: Keine Reaktion.

(siehe Anhang / see attachement)

Obige Ergänzung führt zu folgendem:
    Ausgangslage: Markise vollkommen eingefahren.
    Drücken Btn_02: Markise fährt aus.
    Drücken Btn_02: Markise stoppt.
    Drücken Btn_02: Markise fährt weiter aus.
    Drücken Btn_01: Markise stoppt.
Ok, di Steuerung der Markise beim Ausfahren befindet sich im Status rampOn und Btn_01 führt zum Status refOff. Warum führt Btn_02 über Status On direkt zu refOn? Müssten nicht zweimal Btn_02 nötig sein?

ciao walter
FHEM 5.7 & TabletUI 2.2 auf Fedora22 Server auf NUC5i5RYK
CUL 868 > FAST EnergyCam
HMLAN > HomeMatic TCs & VDs, Bewegungsmelder, Schalter, Taster, Steckdosen

martinp876

Hallo Walter,

es gab gerade eine Anmerkung, dass die Blind Aktoren so schnell sterben - und die Idee, dass es am schnellen Umschalten zwischen Hoch und Runter liegen koennte - alles Vermutungen.
Zweitens ist mir nicht klar, was im Zustand 'ref' gemacht wird - koennte aber sein, dass dieser ein Umschalten der Relais 'verzoegert' um diese nicht zu ueberlasten. Umschalten der Relais mit laufenden Motoren kann schon einen ganz schoenen Stromfluss erzeugen.
Bei den fhem Schaltkommandos werde ich einen 'zwangs'stop einbauen... bin am testen.

Wenn du direkt die Statemachine programmierts musst du in jeden Fall selbst dafuer sorgen (wie HM intern ablaeuft kann ich nicht sagen...).
Ich programmiere immer nur den 'normalen' Ablauf. Will sagen
NICHT von Off nach 'rampOn' sondern nach 'refOn'.

Mal ueberlegen - die Regel waere also:
- nie nach 'rampxx' springen, immer nach 'refxx' oder nach 'dlyxx'(man kann den delay-timer ja auf '0' setzen)

Es stoeren mich 2 Pfeile:
'off'->'rampOn'. Wuerde ich 'off'->'refOn' machen.
'refOn'-> 'rampOn' wuerde ich eliminieren - das dauert wie lange es dauert.

Die Ergaenzung, dass man beim Fahren mit beiden Buttons ein 'stop' erreichen muss (was nicht HM-default ist) hat mich auch gestoert. Habe auch einen Vorschlag im Einsteigerdoc gemacht, der bei mir laeuft.

ZitatOk, die Steuerung der Markise beim Ausfahren befindet sich im Status rampOn und Btn_01 führt zum Status refOff. Warum führt Btn_02 über Status On direkt zu refOn? Müssten nicht zweimal Btn_02 nötig sein?

Hast du beachtet, dass der Rollo im Status rampxx faehrt und im status on/off steht?
wenn du in rampOn bist und stoppen willst musst du nach 'on'. Wenn du nach refOff gehts wird der Aktor automatisch nach rampOff und nach Ablauf nach 'off' gehen.
Nur On und Off sind  zustaende, die 'forever' stehen, alle anderen sind ueber kurz oder lang automatisch beendet.
On und Off unterscheiden sich nur darin, wie man Hingekommen ist - und das hat Auswirkungen auf "muss eine Jalousie die Lamellen drehen" u.ae.

Gruss Martin
Ich denke deine Pfeile sind nicht komplett. Da fehlen doch noch welche.



wkarl

Hallo Martin,

das mit dem ramp... habe ich inzwischen verworfen. Die Kommentare von HomeMatic-Inside verweisen auf Geräte, die man gezielt hoch- oder runterfahren kann - also Dimmer, etc. Da ich keinen Motor mit Anfahrfunktion habe ist das natürlich Humbug. Die rev... Zustände nutze ich als Zwischen-Stopp-Status. Also kein direktes Schalten von vor nach zurück, bzw vice versa.

Ich hab ja mal was Vernünftiges gelernt - Industrieelektroniker. Da weiß man was passiert, wenn ein fetter Motor von jetzt auf gleich in den Rückwärtsgang schaltet.

Poste demnächst mal den nächsten Zwischenstatus.

ciao walter
FHEM 5.7 & TabletUI 2.2 auf Fedora22 Server auf NUC5i5RYK
CUL 868 > FAST EnergyCam
HMLAN > HomeMatic TCs & VDs, Bewegungsmelder, Schalter, Taster, Steckdosen

wkarl

Hallo Martin,

tja, soweit zu Theorie und Praxis. Meine Tests ergeben Du musst über ramp... gehen. Ansonsten ist das Kontrollverhalten nicht nachvollziehbar.

Hier mein aktuelles stateful diagram:


(siehe Anhang / see attachement)

On und Off stellen die Endpositionen dar. Während rampOn und rampOff fährt die Markise aus oder ein.

Weiteres folgt.

ciao walter
FHEM 5.7 & TabletUI 2.2 auf Fedora22 Server auf NUC5i5RYK
CUL 868 > FAST EnergyCam
HMLAN > HomeMatic TCs & VDs, Bewegungsmelder, Schalter, Taster, Steckdosen

martinp876

Hallo Walter,

hm - seltsam. Wenn du deine buttons peerst - dual, also 2 auf einmal sollte eine konfiguration vorhanden sein, an der ich mich festmachen wuerde.
Die Trigger funktionieren dann
on->offDly
offDly->refOff
refOff->rampOff
ramp_off->rampOff # nicht verlassen bei 'klick'
off->offDly
onDly-> offDly
refOn ->on
...

Daraus folgere ich, dass der naruerliche Vorgaenger von rampOn ein refOn ist.
Was die Zustaende im Einzelnen machen kann ich nicht mit Sicherheit sagen
In jedem Fall empfehle ich, nicht (NIE) nach rampOn zu springen, ausser von rampOn selbst oder von refOn. rampOff entsprechend. Das gilt insbesondere wegen der hohen Ausfallrate der Blind-Aktoren - geruechteweise wegen verklebter Relais.
Keine Probleme darf es geben wenn man von off nach dlyOn springt und die dazugehoerige onDly time auf '0' setzt. Sollte genauso schnell reagieren und der HM ausgedachte Weg wird nicht unterbrochen.

Im Einsteigerdoc habe ich das noch nicht so sonders springe von on nach rampOn, anstatt auf dlyOn. Halte ich aber fuer viel ngefaehrlicher also von off nach rampOn, da hier eine umkehr der Richtung stattfinden.

Wie gesagt, da ich keine Ahnung habe, wie HM es intern realisiert hat, nur dass einigen Usern die Blind-Aktoren verstorben sind, ncoh einiger Zeit, im grossen Stil - bin ich noch vorsichtiger geworden.

Ref koennte etwas mit dem umschaltern der Motorrichtung zu tun haben oder mit dem Wenden der Lamellen (jalousie) - also auch die change-time des Aktors beachten

Gruss Martin

martinp876

Hi Walter,
Noch eins - hast du dir schon eine Referenz erzeugt? Mein vorschlag ist erst einmal "resetn" wie folgt

set <Btn_01> peerChan 0 <rollo> dual set aktor # HM setzt alles auf 2Button default

Dann auslesen mit HMinfo
define hm HMinfo
set hm register -f <rollo>

ist m.E. die beste und uebersichtlichste Darstellung der Register, die ich bieten kann. Besonders fuer List3 Register.
Nur aendern was funktional sinn macht ist meine (defensive) Einstellung

Natuerlich kannst du als Hardwerker auch einmal messen was passiert, wenn man direkt schaltet - evtl hast du ein Oszi parat. Waere cool.

Gruss Martin

wkarl

Hallo Martin,

der Status Off ist die Endposition der eingefahrenen Markise, also steht sie. Der Sprung nach rampOn ist daher ungefährlich. Meinen Tests zufolge befindet man sich im Status rampOn während dem Ausfahren der Markise (nicht im Status On). Mit einem weiteren Btn_02 gehts über On zu refOn (hier gibt es ein Fragenzeichen - wieso funktioniert das so?). Wieder Btn_02 führt von refOn nach rampOn und die Markise wird weiter ausgefahren.

Ach ja, wie komme ich darauf, dass das Ausfahren der Markise dem Status rampOn entspricht. Ein Springen zu refOff mit Btn_01 funktioniert von rampOn aber nicht von On, währen der Ausfahrt. Von On aus geht es erst, wenn die Markise in der ausgefahrenen Endposition ist.

Ist die Markise in der Endposition vollausgefahren gilt das selbe für Btn_01.

Da dlyOn default-mäßig auf 0s steht, bin ich der Meinung dann kann man  auch drauf verzichten.

Letztendlich funktioniert das Konstrukt wie es soll. Auch wenn ich den Punkt 'über On zu refOn' nicht nachvollziehen kann.

Bleibe dran.

ciao walter
FHEM 5.7 & TabletUI 2.2 auf Fedora22 Server auf NUC5i5RYK
CUL 868 > FAST EnergyCam
HMLAN > HomeMatic TCs & VDs, Bewegungsmelder, Schalter, Taster, Steckdosen

martinp876

Hallo Walter,

Zitatder Status Off ist die Endposition der eingefahrenen Markise
fast. Der Status off ist NICHT der fhem "status:off". Der Aktor ist im status "off" IMMER wenn ein zufahren gestoppt ist. Also auch wenn du von 100% nach 99% gefahren bist und dort stehen bleibst.
Der Motor sollte in diesen Zustand aus sein, da stimme ich zu. Dir letzte Fahrrichtung war mit Sicherheit "markise einfahren".
Auch korrekt ist, dass der fahrzustand immer 'rampxx' ist. Habe ich im Einsteigerdoc so beschrieben.

Also - egal welchen Trigger du gibst - der Aktor kann nur einen stabilen Zustand in On oder Off haben - aus ALLEN andern wird er ohne dein Zutun weiterfahren, wenn die Zeit abgelaufen ist. Uns selbst in On und Off bleibt er nur stehen, wenn du die On/OffTime nicht gesetzt hast (unendlich ist nur 111600 oder so, siehe regList). Sonst wird er ewig (evtl langsam, mit delay) im Kreis fahren.


ZitatMit einem weiteren Btn_02 gehts über On zu refOn (hier gibt es ein Fragenzeichen - wieso funktioniert das so?).
Verstehe ich nicht. In welchen Zustand drueckst du Btn2?
Nur zur Klarstellung - bin nicht sicher ob das Verstanden ist - Mit der Jumptable wird NICHT der automatische Ablauf programmiert. Das kann man nicht. Die JumpTabelle programmiert die Ausnahme! Also der Rollo ist 'on forever' und du sendest einen Trigger (z.B. Tg1-short von peer Tg1). Der Aktor schaut in der shJtOn nach, was er machen soll - default waere "gehe sofort nach Zustand OffDly". Also wird der Zustand geaendert nach offDly. Beim Eintritt in dlyOff wird der timer "Tg1-shOffDly" aufgezogen und der Aktor wartet in diesen Zustand, bis
a) der timer ausgelaufen ist
b) Irgend ein anderer gueltiger Trigger kommt

Im Fall a) wird in den Zustand 'refOff' gewechselt. Keine Ahnung, wie lange der dauert, aber danach nach rampOff. (falls keine weiteren Trigger kommen, egal welche Quelle!!!)
im Fall b) wird nachgesehen, welcher Trigger gekommen ist, sagen wir noch einmal Tg1-short - also ein 2. Click. Jetzt wird in shJtOffDly nachgesehen was gemacht werden soll. Klassich waere, das delay abzugrechen und sofort weiterzu machen. Dann stuende in shJtOffDly = refOff - und dann gehts eben dahin.

ZitatDa dlyOn default-mäßig auf 0s steht, bin ich der Meinung dann kann man auch drauf verzichten.
ja, aber nur, wenn du dann refOn nicht auch noch auslaesst. Was da passiert koennen wir nur vermuten.
Und da es eh auf '0' steht, die Arbeit in einer optimierten FW machine abgearbeitet wird - warum sollten wir darauf verzichten? Es kostet nichts und erlaubt dir ggf den delay mit einem Reister zu setzen.
ZitatAuch wenn ich den Punkt 'über On zu refOn' nicht nachvollziehen kann.
Das wuerde mich auch interessieren.

ZitatLetztendlich funktioniert das Konstrukt wie es soll.
prima. Ich hoffe, dass er nicht, wie bei den beiden anderen auch nach 3 Monaten nur noch eine Fahrrichtung.
Gruss Martin

wkarl

Hallo Martin,

ich hab noch keine Erklärung für das ein oder andere Verhalten aber das folgende Diagram funktioniert so wie es soll.

(siehe Anhang / see attachement)

Verhalten ist wie folgt.
    Ausgehend von der Endposition 'Eingefahrene Markise'
    Btn_02 > Markise fährt aus.
    Btn_02 > Markise stoppt.
    Btn_02 > Markise fährt weiter aus.
    Btn_01 > Markise stoppt.
    Btn_02 > Markise fährt weiter aus.
    Btn_01 > Markise stoppt.
    Btn_01 > Markise fährt ein.
    Btn_01 > Markise stoppt.
    Btn_02 > Markise fährt aus.
    Btn_01 > Markise stoppt.
    Btn_01 > Markise fährt ein.
    Btn_01 > Markise stoppt.
    Btn_01 > Markise fährt weiter ein. > Bis zur Endposition 'Eingefahrene Markise'
Also kein direktes Umschalten des Motors in die umgekehrte Richtung. Und hier die settings der Register.
MarkiseAktorCfg() {
    my $actor = "Markise";
    my $remote01 = "Schalter_Terasse_Btn_01";
    my $remote02 = "Schalter_Terasse_Btn_02";
    { fhem ("set $actor regSet shBlJtOff rampOn $remote02") };
    { fhem ("set $actor regSet shBlJtDlyOn no $remote02") };
    { fhem ("set $actor regSet shBlJtRefOn rampOn $remote02") };
    { fhem ("set $actor regSet shBlJtRampOn on $remote02") };
    { fhem ("set $actor regSet shBlJtOn refOn $remote02") };
    { fhem ("set $actor regSet shBlJtDlyOff no $remote02") };
    { fhem ("set $actor regSet shBlJtRefOff no $remote02") };
    { fhem ("set $actor regSet shBlJtRampOff on $remote02") };
    { fhem ("set $actor regSet shBlJtOff refOff $remote01") };
    { fhem ("set $actor regSet shBlJtDlyOn no $remote01") };
    { fhem ("set $actor regSet shBlJtRefOn rampOff $remote01") };
    { fhem ("set $actor regSet shBlJtRampOn no $remote01") };
    { fhem ("set $actor regSet shBlJtOn rampOff $remote01") };
    { fhem ("set $actor regSet shBlJtDlyOff no $remote01") };
    { fhem ("set $actor regSet shBlJtRefOff rampOff $remote01") };
    { fhem ("set $actor regSet shBlJtRampOff off $remote01") };
    { fhem ("set $actor regSet shCtValHi 255 $remote01") };
    { fhem ("set $actor regSet shCtValLo 1 $remote01") };
    { fhem ("set $actor regSet shCtValHi 255 $remote02") };
    { fhem ("set $actor regSet shCtValLo 1 $remote02") };
    { fhem ("set $actor getConfig") };
}

Wenn ich Erklärungen zu den offenen Punkte habe, werde ich sie hier in die Runde posten.

ciao walter
FHEM 5.7 & TabletUI 2.2 auf Fedora22 Server auf NUC5i5RYK
CUL 868 > FAST EnergyCam
HMLAN > HomeMatic TCs & VDs, Bewegungsmelder, Schalter, Taster, Steckdosen

martinp876

Hallo Walter,

Sicher hast du recht, dass der Rollo erst steht und wahtscheinlich alles passt. Was ref macht weiss ich immer noch, vielleicht eine Zwangspause - oder doch ein komplexeres umschalten.
Egal, dies ist deine Variante.
Wenn an mit minimalen Aenderungen das gleiche erreichen will - incl reset ALLER register dieses peerings siehe Unten.
Ich habe dennoch einige Anmerkungen - falls es dich interessiert.
 1) Long hast du garnicht programmiert - kein interresse? Wenn es nur im das 'stop' geht sollte es der Default richten
 2) peerChan resettet die Register dieses Links, siehe Beispiel unten
 3) wenn du die Conditiontable ausschalten willst solltest du shCtValLo = 0 und alle CT entries auf geLo setzen

Hier mein Vorschlag:
MarkiseAktorCfg() {
    my $actor = "Markise";
    my $remote01 = "Schalter_Terasse_Btn_01";
    my $remote02 = "Schalter_Terasse_Btn_02";
#setze defaults fuer Link Register in Aktor.
    { fhem ("set $remote01 peerChan 0 $actor dual set actor") };
#erlaube stop, egal welcher 'short' button
    { fhem ("set $actor regSet shBlJtRampOn  on      $remote02") };
    { fhem ("set $actor regSet shBlJtRampOff off     $remote01") };
}


kann erweitert werden (wuerde ich bei einem Button nicht)
#fuer remotes sollte die CT  nicht relevant sein, da kein Wert geliefert wird
#Wenn man will:
    { fhem ("set $actor regSet shCtValLo     0       $remote01") };
    { fhem ("set $actor regSet shCtValLo     0       $remote02") };

{ fhem ("set $actor regSet shCtRampOn    geLo    $remote02") };
{ fhem ("set $actor regSet shCtRampOff   geLo    $remote02") };
{ fhem ("set $actor regSet shCtDlyOn     geLo    $remote02") };
{ fhem ("set $actor regSet shCtDlyOff    geLo    $remote02") };
{ fhem ("set $actor regSet shCtOn        geLo    $remote02") };
{ fhem ("set $actor regSet shCtOff       geLo    $remote02") };

{ fhem ("set $actor regSet shCtRampOn    geLo    $remote01") };
{ fhem ("set $actor regSet shCtRampOff   geLo    $remote01") };
{ fhem ("set $actor regSet shCtDlyOn     geLo    $remote01") };
{ fhem ("set $actor regSet shCtDlyOff    geLo    $remote01") };
{ fhem ("set $actor regSet shCtOn        geLo    $remote01") };
{ fhem ("set $actor regSet shCtOff       geLo    $remote01") };


Und dann noch
   # wenn man autoReadReg gesetzt hat wird das Lesen automatisch aufgesetzt
    { fhem ("set $actor getConfig") };


Gruss Martin

p.s.: hast du eine Verzoegerung bemerkt, wenn man anstatt von On nach rampOff erst nach dlyOff springt und shOffDly = 0 ist?

wkarl

Hallo Martin,

ZitatWas ref macht weiss ich immer noch, vielleicht eine Zwangspause - oder doch ein komplexeres umschalten.
Das hab ich bei Homatik-Inside gefunden.

ZitatDie Zustaende REFON/OFF sind zum wenden der Jalousie gedacht. Die Prozentuale Steuerung der Rollos ist eine reine Zeitsteuerung. Die Fahrzeit rauf und runter muss in die Register geschrieben werden genauso wie die Wendezeit der Lamellen. Der Zustand REF.. ist also zwischen ..DELAY und RAMP.. . Prinzipiell scheint der Zustand auch im Dimmer vorhanden zu sein, da die Register vorprogramiert sind. Er wird hier aber nicht benutzt - wahrscheinlich ist einfach die Wendezeit auf 0 gesetzt. Es hat den Anschein, dass die FW im dimmer und im Jalousieaktor identisch sind und nur durch die Parameter unterschieden werden. Die Leistungs HW ist natuerlich unterschiedlich
Genauso wird es auch bei mir genutzt. refOn und refOff sind die Stoppzustände, während des Rauf- und Runterfahrens. On und Off die Endpositionen. So mein Verständnis.

Zitat1) Long hast du garnicht programmiert - kein interresse?
Aktuell (habe noch keine Veränderungen vorgenommen) verhält es sich so, dass bei long die Markise so lange aus- oder einfährt bis man loslässt. Allerdings jede Taste im toggle-Modus - lang Drücken > ausfahren, loslassen > Stopp, lang Drücken > zufahren, loslassen > Stopp.
Meine Idee wäre bei long zu einer vorbestimmten Position zu fahren. Muss ich mir noch Gedanken dazu machen.

ZitatWenn es nur im das 'stop' geht sollte es der Default richten
Verstehe ich nicht. Was meinst Du mit Default?

Zitat3) wenn du die Conditiontable ausschalten willst solltest du shCtValLo = 0 und alle CT entries auf geLo setzen
Danke für den Tipp. Hab mich schon gefragt warum das es hier kein no gibt.

Zitatp.s.: hast du eine Verzoegerung bemerkt, wenn man anstatt von On nach rampOff erst nach dlyOff springt und shOffDly = 0 ist?
Nein, ich habe keine merkliche Verzögerung festgestellt.

ciao walter
FHEM 5.7 & TabletUI 2.2 auf Fedora22 Server auf NUC5i5RYK
CUL 868 > FAST EnergyCam
HMLAN > HomeMatic TCs & VDs, Bewegungsmelder, Schalter, Taster, Steckdosen

marc2

Moin !

Da günstiger, habe ich meine Rolladenaktoren als Bausätze erworben. Zum Bausatz gehört die verhältnismäßig ausführliche Anleitung "Aktionsprofile für Aktoren erarbeiten", die man auch online bei ELV bekommt (http://www.elv.de/controller.aspx?cid=726&detail=38635). Habt Ihr diese Anleitung ? Könnte hilfreich sein !

Gruß, Marc

wkarl

Hallo Martin,

Zitat3) wenn du die Conditiontable ausschalten willst solltest du shCtValLo = 0 und alle CT entries auf geLo setzen

Müsste das nicht auf ltLo gesetzt werden?

ciao walter
FHEM 5.7 & TabletUI 2.2 auf Fedora22 Server auf NUC5i5RYK
CUL 868 > FAST EnergyCam
HMLAN > HomeMatic TCs & VDs, Bewegungsmelder, Schalter, Taster, Steckdosen