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
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
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
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.
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
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
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
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
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
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
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
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?
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
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 (//www.elv.de/controller.aspx?cid=726&detail=38635)). Habt Ihr diese Anleitung ? Könnte hilfreich sein !
Gruß, Marc
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
Hallo Marc,
danke für den Tipp. Hab das PDF gekauft und gleich folgende Erkenntnis gewonnen.
Zitat3) wenn du die Conditiontable ausschalten willst solltest du shCtValLo = 0 und alle CT entries auf geLo setzen
mit
set Markise regSet lgActionType Schalter_Terasse_Btn_01geht es einfacher.
ciao walter
Hallo Walter,
Zitatset Markise regSet lgActionType Schalter_Terasse_Btn_01
verstehe ich nicht. der Parameter fuer lgActionType fehlt.
Auch das Ziel verstehen ich nicht. ConditionTable und JumpTable sid Grundverschieden. Was willst du erreichen?
Wenn du einen trigger komplett ignorieren willst musst du
lgActionType off
setzen - also keinen "lang" trigger DIESER quelle
wenn du die ganze Quelle ignorieren willst, dann auch noch short:
shActionType off
Beim Schreiben merke ich, wir brauchen erst einmal Begriffe
TriggerQuelle: ein Button oder ein MDIR... - jeweils ein SensorKanal
TriggerTyp: long oder short (MDIR und ein paar Buttons koennen nur short!)
TriggerParam: ein MDIR gibt die Helligkeit im Trigger mit. Buttons natuerlich nicht.
Einer TriggerQuelle ist ein ganzer Satz register zugeordnet. Die Haelfte dem Typ short und die andere long.
Wenn der Trigger kommt wird ueber ActionType primaer die Reaktion festgelegt. Nur wenn es jumpToTarget ist, ist auch die jumptable integessant. Bei "off" wird der Trigger ignoriert.
EGAL was in ActionType steht - der Actor arbeitet immer noch in seiner statemachine. Auch wenn die Spezial-Spruenge nicht genutzt werden - "ActionType ne jumpToTarget". Ohne statemachine geht es nie.
Bevor das Ganze ausgewertet wird - und wenn der Trigger einen TriggerParam mitbringt - wird in der ConditionTable geprueft, ob der Trigger gueltig ist. Also je nachdem in welchen State der Aktor bei eintreffen des Triggers gerade ist wird geschaut welche condition-bedingung genutzt werden muss (eine ist es immer).
Ist also der Aktor in 'on' und es kommt ein short-trigger wird in shCtOn nachgesehen. Steht da geLo wird eben geprueft, ob der TriggerParam groesser als der shCtValLo ist. Nur wenn die Bedingung stimmt!!! ist der Trigger gueltig - ansonsten wird er verworfen.
CtValLo und shCtValHi sind nur Namen. Man kann (siehe Bedingungen) beide als obere oder untere Grenze nutzen.
Wenn ich also die Condition-table nicht nutzen will sollte ich erreichen, dass die Bedingung immer wahr ist. Wenn ich den Trigger nicht nutzen will sollte ich mich an ActionType halten.
Hoffe, man kann es verstehen.
Gruss Martin
Hallo Walter,
Zitatset Markise regSet lgActionType Schalter_Terasse_Btn_01
verstehe ich nicht. der Parameter fuer lgActionType fehlt.
Auch das Ziel verstehen ich nicht. ConditionTable und JumpTable sid Grundverschieden. Was willst du erreichen?
Wenn du einen trigger komplett ignorieren willst musst du
lgActionType off
setzen - also keinen "lang" trigger DIESER quelle
wenn du die ganze Quelle ignorieren willst, dann auch noch short:
shActionType off
Beim Schreiben merke ich, wir brauchen erst einmal Begriffe
TriggerQuelle: ein Button oder ein MDIR... - jeweils ein SensorKanal
TriggerTyp: long oder short (MDIR und ein paar Buttons koennen nur short!)
TriggerParam: ein MDIR gibt die Helligkeit im Trigger mit. Buttons natuerlich nicht.
Einer TriggerQuelle ist ein ganzer Satz register zugeordnet. Die Haelfte dem Typ short und die andere long.
Wenn der Trigger kommt wird ueber ActionType primaer die Reaktion festgelegt. Nur wenn es jumpToTarget ist, ist auch die jumptable integessant. Bei "off" wird der Trigger ignoriert.
EGAL was in ActionType steht - der Actor arbeitet immer noch in seiner statemachine. Auch wenn die Spezial-Spruenge nicht genutzt werden - "ActionType ne jumpToTarget". Ohne statemachine geht es nie.
Bevor das Ganze ausgewertet wird - und wenn der Trigger einen TriggerParam mitbringt - wird in der ConditionTable geprueft, ob der Trigger gueltig ist. Also je nachdem in welchen State der Aktor bei eintreffen des Triggers gerade ist wird geschaut welche condition-bedingung genutzt werden muss (eine ist es immer).
Ist also der Aktor in 'on' und es kommt ein short-trigger wird in shCtOn nachgesehen. Steht da geLo wird eben geprueft, ob der TriggerParam groesser als der shCtValLo ist. Nur wenn die Bedingung stimmt!!! ist der Trigger gueltig - ansonsten wird er verworfen.
CtValLo und shCtValHi sind nur Namen. Man kann (siehe Bedingungen) beide als obere oder untere Grenze nutzen.
Wenn ich also die Condition-table nicht nutzen will sollte ich erreichen, dass die Bedingung immer wahr ist. Wenn ich den Trigger nicht nutzen will sollte ich mich an ActionType halten.
Hoffe, man kann es verstehen.
Gruss Martin
Hallo Martin,
mein Fehler
Zitatset Markise regSet lgActionType off Schalter_Terasse_Btn_01
muss es natürlich heißen.
Es soll damit erreicht werden, dass alle lg-TriggerTypen ausgeschalten werden. Habe dies für alle Triggerquellen gesetzt. Warum? Meine drei Mädchen sind leider nicht so technikbegeistert. Also muss ich mögliche Fehlerquellen/Fehlverhalten weitestgehend ausschließen ;-)
Und noch ein Fehler meinerseits. Du hast Recht, die CTs der sh-TriggerTypen explizit zu behandeln.
Du schreibst in Deiner vorherigen note, den CtValLo auf 0 zu setzen und die Cts mit ge zu prüfen. Müsste es nicht lt sein, damit die Überprüfung immer negativ ist?
ciao walter
Hallo Walter,
CT<state> geLo
TriggerParam groesser als CtValLo
TriggerParam groesser als 0
==> das ist immer wahr, es werden also keine Trigger unterdrueckt.
Alternativ sollte
CtValLo = 255
CT<state> ltLo
dann ist
TriggerParam <ltLo fuer alle TriggerParam [0-255[ - oder bei integer:TriggerParam [0-254]
identisches bewirken - nur wenn TriggerParam = 255 waere klappt es nicht (lt, nicht le!)
255 ist aber unwahrscheinlich, da HM bisher bei 200 aufhoert.
Hallo Walter,
ich habe gerade in HMinfo eine "template" Methode eingebaut. Hatte so etwas in der Art schon länger vor... und duhast mir jetzt den Anschub gegeben.
Die Beschreibung der Kommandos ist in HMinfo vorhanden. Zum Überblick:
man kann
- templateDef: definieren
- templateLst: definierte templates anzeigen
- templateChk: prüfen, ob ein Device/peering dem Template entspricht
- templateSet: schreiben eines templates in ein Device
Templates ein unabhängig von short und long. Man kann also das gleiche template für short und/oder long nutzen - und natürlich für jeden peer einzeln.
Templates gehen mit jedem reload verloren - man sollte sie also im fhem.cfg beschreiben ( nur templateDef )
Es sind 2 oder 3 Templates exemplarisch vorhanden, ist aber nur Beispielhaft.
Ein Vorteil ist, dass das schreiben extrem vekürzt ist, es wird bei set nicht jedes Register separat geschrieben.
Ausserdem kann man die templates parametrisieren - also ein treppenhausschalter-template und die Schaltzeit kommt per parameter hinzu.
Würde mich freuen, wenn du es einmal ansiehst. Gerne auch Anregungen - es sind noch ein paar Punkte offen zum wirklich einfachen Handling.
EIN nächster Schritt ist dann, templates für simple-user bereitzustellen. Man koennte dies in Wiki sammeln.
Gruss Martin