HM-TC-IT-WM-W-EU soll Rolladen-Aktor HM-LC-BL1-FM steuern

[Zeitisen]

Hallo,

ich habe einen HM-TC-IT-WM-W-EU, der mit dem Kanal SwitchTr  über einen Rolladen-Aktor HM-LC-BL1-FM ein Kippfenster öffnen und schliessen soll.
Beim Überschreiten der Temperaturgrenze gibt es einen Trigger  " trig_wg_TemperaturRegler_SwitchTr: 200", beim Unterschreiten der Grenze "trig_wg_TemperaturRegler_SwitchTr: 0".

Ich habe die zwei als single gepeert.
Nach meinem Verständnis sollte bei einem Trigger mit 200 JtOff -> JtDLyOn -> JtrefOn -> JtRampOn -> On gesprungen werden.
Bei einem Trigger mit 0  von JtOn -> jtDlyOff -> JtRefOff -> JtRampOff -> Off

Die Register habe ich  im HM-LC-BL1-FM so gesetzt:

Code Auswählen Erweitern


R-wg_TemperaturRegler_SwitchTr-shActionType jmpToTarget
R-wg_TemperaturRegler_SwitchTr-shBlJtDlyOff refOff
R-wg_TemperaturRegler_SwitchTr-shBlJtDlyOn refOn
R-wg_TemperaturRegler_SwitchTr-shBlJtOff dlyOn
R-wg_TemperaturRegler_SwitchTr-shBlJtOn dlyOff
R-wg_TemperaturRegler_SwitchTr-shBlJtRampOff off
R-wg_TemperaturRegler_SwitchTr-shBlJtRampOn on
R-wg_TemperaturRegler_SwitchTr-shBlJtRefOff rampOff
R-wg_TemperaturRegler_SwitchTr-shBlJtRefOn rampOn
R-wg_TemperaturRegler_SwitchTr-shCtDlyOff ltLo
R-wg_TemperaturRegler_SwitchTr-shCtDlyOn geLo
R-wg_TemperaturRegler_SwitchTr-shCtOff geLo
R-wg_TemperaturRegler_SwitchTr-shCtOn ltLo
R-wg_TemperaturRegler_SwitchTr-shCtRampOff ltLo
R-wg_TemperaturRegler_SwitchTr-shCtRampOn geLo
R-wg_TemperaturRegler_SwitchTr-shCtRefOff ltLo
R-wg_TemperaturRegler_SwitchTr-shCtRefOn geLo
R-wg_TemperaturRegler_SwitchTr-shCtValHi 100
R-wg_TemperaturRegler_SwitchTr-shCtValLo 50
R-wg_TemperaturRegler_SwitchTr-shDriveMode direct
R-wg_TemperaturRegler_SwitchTr-shMaxTimeF 25.5 s
R-wg_TemperaturRegler_SwitchTr-shOffDly 0 s
R-wg_TemperaturRegler_SwitchTr-shOffLevel 0 %
R-wg_TemperaturRegler_SwitchTr-shOffTime 111600 s
R-wg_TemperaturRegler_SwitchTr-shOffTimeMode absolut
R-wg_TemperaturRegler_SwitchTr-shOnDly 0 s
R-wg_TemperaturRegler_SwitchTr-shOnLevel 100 %
R-wg_TemperaturRegler_SwitchTr-shOnTime 111600 s
R-wg_TemperaturRegler_SwitchTr-shOnTimeMode absolut
   
Es passiert aber nichts.
shCtOn ltLo sollte doch bedeuten: Wenn der Wert des Triggers kleiner als shCtValLo, also 50, ist springe weiter, in dem Fall nach dlyOff.

Kann mir jemand dabei helfen?

[martinp876]

sollte so stimmen.
on ist 100% und entspricht offen beim Rollo offen.
Natürlich muss der Rollo im Ruhezustand sein - während des Fahrens ist er nicht in on oder off.

Gruss Martin

[Zeitisen]

Ich habe jetzt die Spannung vom Aktor kurz unterbrochen. Danach meldet  er sich mit powerOn

Code Auswählen Erweitern

2014-04-02_17:13:01 wg_Fenster_links powerOn: -
2014-04-02_17:13:01 wg_Fenster_links level: 50
2014-04-02_17:13:01 wg_Fenster_links pct: 50
2014-04-02_17:13:01 wg_Fenster_links 50
2014-04-02_17:13:01 wg_Fenster_links timedOn: zu
2014-04-02_17:13:01 wg_Fenster_links motor: err:50

Danach kann ich mit fhem auf 0 fahren:

Code Auswählen Erweitern

2014-04-02_17:18:59 wg_Fenster_links set_zu
2014-04-02_17:18:59 wg_Fenster_links aesKeyNbr: FF
2014-04-02_17:18:59 wg_Fenster_links level: 50
2014-04-02_17:18:59 wg_Fenster_links pct: 50
2014-04-02_17:18:59 wg_Fenster_links deviceMsg: 50 (to HMLANCFG)
2014-04-02_17:18:59 wg_Fenster_links 50
2014-04-02_17:18:59 wg_Fenster_links timedOn: zu
2014-04-02_17:18:59 wg_Fenster_links motor: down:50
.....
2014-04-02_17:19:23 wg_Fenster_links level: 0
2014-04-02_17:19:23 wg_Fenster_links pct: 0
2014-04-02_17:19:23 wg_Fenster_links deviceMsg: zu (to HMLANCFG)
2014-04-02_17:19:23 wg_Fenster_links zu
2014-04-02_17:19:23 wg_Fenster_links timedOn: zu
2014-04-02_17:19:23 wg_Fenster_links motor: err:zu

und weiterhin passiert nichts. Hier ein Trigger mit 200:

Code Auswählen Erweitern

2014-04-02_17:19:41 wg_Fenster_links trig_wg_TemperaturRegler_SwitchTr: 200
2014-04-02_17:19:41 wg_Fenster_links trigLast: wg_TemperaturRegler_SwitchTr :200
2014-04-02_17:19:52 wg_Fenster_links level: 0
2014-04-02_17:19:52 wg_Fenster_links pct: 0
2014-04-02_17:19:52 wg_Fenster_links deviceMsg: zu (to HMLANCFG)
2014-04-02_17:19:52 wg_Fenster_links zu
2014-04-02_17:19:52 wg_Fenster_links timedOn: zu
2014-04-02_17:19:52 wg_Fenster_links motor: stop:zu

und dann einer mit 0

Code Auswählen Erweitern

2014-04-02_18:18:41 wg_Fenster_links trig_wg_TemperaturRegler_SwitchTr: 0
2014-04-02_18:18:41 wg_Fenster_links trigLast: wg_TemperaturRegler_SwitchTr :0

Nach diesem Trigger kommt nicht eine einzige Meldung vom Aktor.

Es fällt auch auf, dass SwitchTr bei 200 jede Minute einen Trigger sendet. Ich habe noch keine Beinflussungsmöglichkeit gefunden.
Der Trigger 0 wird nur einmal gesendet

Kann man irgendwo nachlesen, in welchem Zustand sich der Aktor befindet?
Ich bin jetzt ratlos.

[martinp876]

Hi Zeitisen,


ich habe es einmal mit meinen Dimmer simuliert. Das klappt eigentlich gut.
a) ich habe ein paar neue Readings in SwitchTR eingebaut - das ändert für dich nichts,... nur zur Info

b)  so habe ich es gesetzt

Code Auswählen Erweitern

   TC_IT_SwitchTr shCtDlyOff       :ltLo
   TC_IT_SwitchTr shCtDlyOn        :geLo
   TC_IT_SwitchTr shCtOff          :geLo
   TC_IT_SwitchTr shCtOn           :geLo
   TC_IT_SwitchTr shCtRampOff      :geLo
   TC_IT_SwitchTr shCtRampOn       :geLo
   TC_IT_SwitchTr shCtValLo        :50
testen kannst du, indem du die desired-temp setzt - auf on oder off. Der TC sendet dann einen trigger nach ein paar minuten

das ist die jumptabelle

Code Auswählen Erweitern

   TC_IT_SwitchTr shDimJtDlyOff    :rampOff
   TC_IT_SwitchTr shDimJtOff       :dlyOn
   TC_IT_SwitchTr shDimJtRampOff   :off

   TC_IT_SwitchTr shDimJtDlyOn     :rampOn
   TC_IT_SwitchTr shDimJtOn        :dlyOff
   TC_IT_SwitchTr shDimJtRampOn    :on


[Zeitisen]

Jetzt habe ich ein Verständnisproblem.

Beim Dimmer gibt es kein rampOff/rampOn, aber das ist hier auch egal.

Ich lese deine Jumptable so: JtOff -> dlyOn -> rampOn -> on -> dlyOff -> rampOff -> off

Gesprungen wird, wenn die zugehörigen Bedingungen erfüllt sind:

JtOff -> dlyOn : Bedingung shCtOff          :geLo , also aus dem Zustand Off nach dlyOn wenn der Wert des Triggers >= 50
JtOn -> dlyOff : Bedingung shCtOn         :geLo , also aus dem Zustand On nach dlyOff wenn der Wert des Triggers >= 50

Das ist doch die gleiche Bedingung?. Wenn der Aktor mit Trigger 200 irgendwann bei On  landet, dann kann er doch nicht mit der gleichen Bedingung  mit Trigger 0 bei off landen? Müssten nicht die Bedingungen von on -> dlyOff -> rampOff -> off alle LTLo sein?

Wenn der Aktor bei Trigger 0 bei  dlyOff nach rampOff geht , dann bleibt er doch dann hier stehen, weil  shCtRampOff      :geLo  , also Trigger >= 50 . Der Trigger war aber 0!

Ziel ist ja, dass das Fenser bei trigger 200 von ganz zu nach ganz auf geht und bei Trigger 0 von ganz auf nach ganz zu
Wenn das Fenster ganz offen ist und es kommt Trigger 200, dann passiert nichts.

Wenn das Fenster ganz zu ist und es kommt Trigger 0, dann passiert nichts.


Gibt es irgendwo eine Dokumentation zu den eQ3 State-Machiens, die ich auch verstehe?

[Bennemannc]

Hallo Zeitisen,

wenn ich das richtig verstehe macht das Fenster nur auf oder zu und das abhängig von der Raumtemperatur. In diesem Fall würde ich das peeren sein lassen und über THRESHOLD von fhem steuern lassen.
Der Actor sollte eigentlich seine "Stellung" an fhem senden. Allerdings ist dies die Fahrzeit. Ich habe letztens einen Rolladenactr verbaut. Bei 10% war der schon komplett zu. Also habe ich erst einmal die Fahrzeiten für zu und auf (sind getrennt einstellbar) angepasst. Jetzt stimmt es so etwa.
Die Stellung wird nach fhem Übertragen - ich habe ein devStateIcon für on und off, und wenn der Actor dazwischen steht, wird eine Prozentzahl angezeigt.

Gruß Christoph

[martinp876]

Beim Dimmer gibt es kein rampOff/rampOn

doch. Ein ref gibt es nicht.
ramp ist das dimmen, also die Änderung

Ich lese deine Jumptable so: JtOff -> dlyOn -> rampOn -> on -> dlyOff -> rampOff -> off

da hast du recht. Das
shCtOff          :ltLo
sollte es heissen

Gibt es irgendwo eine Dokumentation zu den eQ3 State-Machins, die ich auch verstehe?

das Einsteigerdoc... mehr kenne ich nicht.


klappt offensichtlich immer noch nicht?
Du kannst ja alle 'on' Bedingungen mit ltLo (also dlyOn, on, refOn, rampOn )und alle 'off' mit geLo versehen.
Lo selbst auf 50 also irgendwo in der mitte. dann die desired-temp auf  on oder off setzen - immer warten bis der trigger gekommen ist.

[Zeitisen]

@bennemanc

Natürlich könnte man das Öffnen auch über fhem steuern. Dabei wäre sogar die Möglichkeit einer variablen Öffnungsweite drin. Ich möchte aber bewusst so wenig wie möglich über fhem aktiv regeln. Wenn sich alle Aktoren und Sensoren direkt unterhalten, ist das erstens schneller und zweitens weniger ausfallkritisch. Wenn alles über eine Zentrale läuft und die fällt aus, geht gar nichts mehr. Fällt andernfalls ein Gerät aus, sind andere nicht direkt betroffen.

@martinp877

es geht immer noch nicht. Ich habe alle Register mehrfach kontrolliert. Kann es sein, dass irgendwelche Register vertauscht sind? Ich habe erst versucht, mit der Windows Homematic Konfigurationssoftware die Register im Expertenmodus zu setzen. Danach war aber in fhem etwas anderes drin. Das muss ich aber erst nochmal in Ruhe prüfen.
Ich habe leider erst immer Abends Zeit, wenn ich geistig nicht mehr fit bin.

[Bennemannc]

Hallo Zeitisen,

ich sehe das Grundsätzlich auch so, das alles auch ohne Fhem laufen muss. Allerdings sind Steuerungen und bestimmte Bedingungen einfach eine Sache die Fhem erledigen kann. Dafür ist es ausgelegt. Wenn Fhem mal nicht läuft, geht das Rollo eben nicht automatisch runter - was Solls, dann kann man über einen Schalter immer noch selber den Fahrbefehl geben. Früher sind wir doch auch durchs Haus gelaufen und haben die Rollos von Hand geschlossen.
Für mich gehört alles was mit Steuerung, Regelung, Messwerterfassungmund Auswertung zu tun hat auf fhem. Dazu gibt es bei mir immer die Möglichkeit mittels Fernbedienung (direkt mit Actor verbunden) zu steuern.
Wie schon gesagt - früher haben wir alles von Hand gemacht und sind damit auch klar gekommen.

Gruß Christoph

[martinp876]

Wie schon gesagt - früher haben wir alles von Hand gemacht und sind damit auch klar gekommen.

aber dafür sind wir nicht hier - oder?

@ Zeitisen
Ich habe einmal simuliert.

Code Auswählen Erweitern

define vc CUL_HM 112233
set vc virtual 1
rename vc_Btn1 bmSim
set bmSim peerChan 0 RolloFH  single
set RolloFH getConfig
# warten bis alle Daten da
set RolloFH regSet prep shCtDlyOff  ltLo  bmSim
set RolloFH regSet prep shCtOff     ltLo  bmSim
set RolloFH regSet prep shCtRampOff ltLo  bmSim
set RolloFH regSet exec shCtRefOff  ltLo  bmSim
somit ist RolloFH mir dem virtuellen Button bmSim gepeert.

Du kannst nun das einschalten und ausschalten des TC simulieren

Code Auswählen Erweitern

set bmSim postEvent 0
set bmSim postEvent 200

wenn ich 0 senden fährt der Rollo auf. Wenn ich 200 sende fährt er zu.
Wiederholen ändert nichts.

Klappt das auch so bei dir? Der TC sollte es genauso senden.

Gruss Martin

[Zeitisen]

Ich  habe deine Befehle so eingegeben. Ausnahme: RolloFH heißt bei mir wg_Fenster_links

nach
set bmSim postEvent 0
kommt

Code Auswählen Erweitern

2014-04-07 22:42:23 CUL_HM wg_Fenster_links trig_bmSim: 0
2014-04-07 22:42:23 CUL_HM wg_Fenster_links trigLast: bmSim:0
2014-04-07 22:42:23 CUL_HM bmSim set_postEvent 0
2014-04-07 22:42:23 CUL_HM vc CMDs_done
2014-04-07 22:42:23 CUL_HM vc CMDs_done
2014-04-07 22:42:23 CUL_HM vc CMDs_done

nach
set bmSim postEvent 200

kommt

Code Auswählen Erweitern


2014-04-07 22:43:32 CUL_HM wg_Fenster_links trig_bmSim: 200
2014-04-07 22:43:32 CUL_HM wg_Fenster_links trigLast: bmSim:200
2014-04-07 22:43:32 CUL_HM bmSim set_postEvent 200
2014-04-07 22:43:33 CUL_HM vc CMDs_done
2014-04-07 22:43:33 CUL_HM vc CMDs_done
2014-04-07 22:43:33 CUL_HM vc CMDs_done

die Register von wg_Fenser_links:

 

Code Auswählen Erweitern

  3:bmSim shActionType     :jmpToTarget
   3:bmSim shBlJtDlyOff     :refOff
   3:bmSim shBlJtDlyOn      :refOn
   3:bmSim shBlJtOff        :dlyOn
   3:bmSim shBlJtOn         :dlyOff
   3:bmSim shBlJtRampOff    :off
   3:bmSim shBlJtRampOn     :on
   3:bmSim shBlJtRefOff     :off
   3:bmSim shBlJtRefOn      :on
   3:bmSim shCtDlyOff       :ltLo
   3:bmSim shCtDlyOn        :geLo
   3:bmSim shCtOff          :ltLo
   3:bmSim shCtOn           :geLo
   3:bmSim shCtRampOff      :ltLo
   3:bmSim shCtRampOn       :geLo
   3:bmSim shCtRefOff       :ltLo
   3:bmSim shCtRefOn        :geLo
   3:bmSim shCtValHi        :100
   3:bmSim shCtValLo        :50
   3:bmSim shDriveMode      :direct
   3:bmSim shMaxTimeF       :25.5 s
   3:bmSim shOffDly         :0 s
   3:bmSim shOffLevel       :0 %
   3:bmSim shOffTime        :111600 s
   3:bmSim shOffTimeMode    :absolut
   3:bmSim shOnDly          :0 s
   3:bmSim shOnLevel        :100 %
   3:bmSim shOnTime         :111600 s
   3:bmSim shOnTimeMode     :absolut

aber:

Code Auswählen Erweitern

   3:bmSim shCtOff          :ltLo
   3:bmSim shCtOn           :geLo
sollten  nicht die Bedingungen anders herum sein? shCtOff :geLo  und shCtOn : ltlo ?

Ich will die Bedingungen umdrehen mit :

Code Auswählen Erweitern

set wg_Fenster_links regSet prep shCtOn     ltLo  bmSim
set wg_Fenster_links regSet prep shCtOff     geLo  bmSim

Das habe ich mehrmals gemacht.
Danach

Code Auswählen Erweitern

set wg_Fenster_links getConfig und nach einer Wartezeit

Code Auswählen Erweitern

get wg_Fenster_links regVal all
Die Register ändern sich nicht.
wie lange muss man denn mindestens/maximal warten?

Hat der Aktor einen Schuss? leider habe ich keinen anderen zum Testen.

Ich habe für heute fertig. Morgen ein neuer Versuch.

[martinp876]

sollten  nicht die Bedingungen anders herum sein? shCtOff :geLo  und shCtOn : ltlo ?

das war mit in Test egal... kommt darauf an, wie rum du steuern willst. Im TC kannst du das sicher auch drehen, wenn du von heizung auf kühlung stellst... aber egal. Hier geht es darum, dass dein Rollo überhaupt reagiert

Ich will die Bedingungen umdrehen mit :

nur die beiden oder den ganzen Block? Also alle ge nach lt und umgekehrt?

Die Register ändern sich nicht.
wie lange muss man denn mindestens/maximal warten?
Hat der Aktor einen Schuss? leider habe ich keinen anderen zum Testen.

Der Rollo reagiert quasi sofort. Du kannst in den "proto"-Internals prüfen, dass alles übertragen ist - und ob fehler aufgetreten sind. Das ist eigentlich immer Pflicht.

[Zeitisen]

Hallo,

Grund für meine "Drehwünsche" : Nach meinem Verständnis und der Theorie müssen alle Bedingungen in der Folge  JtOff -> dlyOn -> rampOn ->  die gleiche Bedingung haben, sonst bleit die Schrittkette stehen. WEnn das nicht so ist, habe ich es entweder falsch verstanden oder die Theorie ist falsch.

Was genau meinst Du mit ""proto"-Internals "?

Ich habe jetzt komplett neu begonnen:
Ich habe den Aktor aus gebaut und in den Auslieferungszustand zurück gesetzt. Ich habe alle Vorkommnisse von wg_fenster_links aus fhem.cfg gelöscht, gespeichert und fhem neu gestartet. Dann habe ich den Aktor mit fhem neu gepaart. Zunächst ohne den Homematic Konfigurator. Das bedeutet, dass zunächst auch kein AES-Schlüssel verfügbar ist im Aktor und sign auf off stehen muss (Ist das wirklich so?)

Dann habe ich alle Aktionen von gestern wiederholt. Und siehe da: set bmSim postEvent 200 macht auf und set bmSim postEvent 0 macht zu

Und das mit

Code Auswählen Erweitern

   3:bmSim shCtOff          :geLo
   3:bmSim shCtOn           :ltLo

Nun die Gegenprobe mit umgedrehten Bedingungen:

Code Auswählen Erweitern

   3:bmSim shCtOff          :ltLo
   3:bmSim shCtOn           :geLo
die Aktionen werde numgedreht: set bmSim postEvent 0 macht auf und set bmSim postEvent 200 macht zu

Das bedeutet aber:

• dass die Zwischen-Bedingungen nicht ausgewertet werden?
• Oder der Wert nur einmal ausgewertet wird?
• Oder die Zustände gar nicht erreicht werden?

Vielleicht gibt es jemand der diese Lücken klären kann.

Nun habe ich über den Homematic-Konfigurator den Temperaturregler gepeert und auf sign auf on gestellt.
Komischerweise gibt es jetzt die Channel Register, die zum Temperaturregler gehören, aber der Temperturregler erscheint nciht in der Peerliste. Hier steht nach wie vor nur bmsim
Ein Schalten funktioniert jetzt auch nicht mehr. Ich setze sign auf off, und schon geht Schalten mit bmSim wieder.

Das ist wieder nicht nachvollziehbar, da auch bei sign on ein Schalten über webcmd möglich ist. Warum also nicht über die Aktion "set bmsim postEvent" ?

Noch ein paar Fragezeichen. die Reglist für den Temperaturregler Kanal SwitchTr liefert folgendes:

Code Auswählen Erweitern

   1: dblPress         |   0 to 1.5s        |          | time to detect double press
   1: longPress        | 0.3 to 1.8s        |          | time to detect key long press
   1: sign             |     literal        |          | signature (AES) options:on,off
   4: expectAES        |     literal        | required | expect AES options:on,off
   4: peerNeedsBurst   |     literal        | required | peer expects burst options:on,off

Ich war der Meinung, dass sign nur bei Aktoren vorkommt und bedeutet, dass vor der Aufforderung etwas zu tun, zunächst die Signierung angefordert wird. Jetz ist aber der kanal SwitchTr kein Aktor sondern ein Sender?

Für heute reichts wieder

[martinp876]

Nach meinem Verständnis und der Theorie müssen alle Bedingungen in der Folge  JtOff -> dlyOn -> rampOn ->  die gleiche Bedingung haben, sonst bleit die Schrittkette stehen

falsch. Der Aktor ist immer in einem der Zustände. Wenn ein Trigger kommt wird geprüft ob dieser JETZT gültig ist. Wenn dem so ist wird er genutzt, ansonsten nicht. Danach geht der Aktor ggf in einen anderen Zustand. Der Trigger darf dann nicht mehr wichtig sein. Stehen bleiben darf die statemachine NIE. Es könnte bestenfalls sein, dass der timeout in einem state unendlich ist... das ist aber kein stehen bleiben.

Was genau meinst Du mit ""proto"-Internals "?

in der Gruppe internals gibt es im Device proto(koll) variablen. Die zeigen an, ob deine Kommunikation erfolgreich war und beendet ist.

Das bedeutet, dass zunächst auch kein AES-Schlüssel verfügbar ist im Aktor und sign auf off stehen muss (Ist das wirklich so?

lese die Register aus. Da steht die Warheit drin.

dass die Zwischen-Bedingungen nicht ausgewertet werden?

jain. Wenn ein trigger kommt und du dich in einem zwischenzustand aufhältst wird dieser ausgewertet. Oft sind die Zwischenzustände nicht genutzt oder kurz, daher nicht/selten relevant.
So du einen dimmer hast und diesen von off auf on schaltest und 5 min ramptime einstellst kannst du trigger zulassen
- wenn er off ist
- wenn er dimmt
- wenn er on ist
du könntest also verhindern, dass jemand die hochdimmphase unterbrechen darf...
dlyoff/on sind meist 0, also nicht relevant. Du kannst es aber nutzten... um trigger zu erlauben oder zu blockieren.

Oder der Wert nur einmal ausgewertet wird?

korrekt . Es ist eigentlich garnicht anders möglich. Der Trigger wird beim Eintreffen als gültig oder ungültig erklärt. dann ist er gültig oder ungültig. danach kann er nicht mehr ungültig werden. ....

Komischerweise gibt es jetzt die Channel Register, die zum Temperaturregler gehören, aber der Temperturregler erscheint nciht in der Peerliste.

Sind die Werte Aktuell? Mache ggf ein set <device> clear register und dann ein getConfig. Alles was dann noch da ist sollte Real sein.

Ein Schalten funktioniert jetzt auch nicht mehr. Ich setze sign auf off, und schon geht Schalten mit bmSim wieder.

der virtuelle Aktor kann kein AES. Wenn sign on ist wird dies nicht akzeptiert.

Ich war der Meinung, dass sign nur bei Aktoren vorkommt und bedeutet, dass vor der Aufforderung etwas zu tun, zunächst die Signierung angefordert wird. Jetz ist aber der kanal SwitchTr kein Aktor sondern ein Sender?

wenn du sign auf on stellst kannst du (die Zentrale) den Schalter nur noch programmieren, wenn du AES beherrschst.
Wenn AES ein ist wird für "kommende" Anforderungen eine signatur verlangt. Ggf. kannst du nicht mehr den Schalter auslesen (getConfig). HM ist hier nicht ganz konsistent, manchmal geht es doch....
Wenn du also sign einschaltest solltest du sicher sein, dass du den AES key korrekt vergeben hast. Es könnte sonst passieren, dass du nicht mehr ausschalten kannst.
=> sender haben auch "sign" (AES) für die messages, die sie empfangen. Operational sind dies wenige, konfiguration gibt es aber immer

[Zeitisen]

Wenn ein Trigger kommt wird geprüft ob dieser JETZT gültig ist. Wenn dem so ist wird er genutzt, ansonsten nicht. Danach geht der Aktor ggf in einen anderen Zustand. Der Trigger darf dann nicht mehr wichtig sein. Stehen bleiben darf die statemachine NIE. Es könnte bestenfalls sein, dass der timeout in einem state unendlich ist... das ist aber kein stehen bleiben.

Entschuldige , dass ich jetzt darauf rumreite. Aber das muss sauber und zweifelsfrei sein.

Beispiel: Rolladen Aktor ist im Zustand RampOn. Das bedeutet, er fährt den Rolladen in der definierten Richtung bis zur maximalen Laufzeit, z.B. 22 Sekunden.
Wenn während dieser Zeit ein neuer Trigger kommt, der die Bedingung erfüllt, springt er dann sofort zum nächsten Zustand?

lese die Register aus. Da steht die Warheit drin.

Leider scheint die Anzeige das zu sein, das am unsichersten funktioniert.
Beispiel: ich will das virtuelle Gerät loswerden und lösche deshalb zuerst das Peering mit

Code Auswählen Erweitern

set  wg_TemperaturRegler_SwitchTr peerChan 0  vatc single unset both
das funktioniert ohne Fehlermeldung. In der Anzeige -Gruppe Internals peerList bleibt nur noch wg_Fenster_links übrig. Dann ändere ich hier irgendein Attribut, und plötzlich ist das Gerät vatc wieder in der peerList sichtbar. Dumm nur, dass ich in der Zwischenzeit vatc gelöscht habe.

Weiterhin behauptet der wg_TemperaturRegler:

Code Auswählen Erweitern

protEvt_AESerrReject 5 last_at:2014-04-10 21:28:41

obwohl ich bei keinem der gepeerten Geräte sign auf on habe.

Nach den eingestellten Werten müsste er das Fenster Schliessen, aber er sendet wiederholt trigger 200 .

Code Auswählen Erweitern

2014-04-10 22:03:02 CUL_HM vatc trigLast: wg_TemperaturRegler_SwitchTr :200
2014-04-10 22:03:02 CUL_HM wg_Fenster_links trig_wg_TemperaturRegler_SwitchTr: 200
2014-04-10 22:03:02 CUL_HM wg_Fenster_links trigLast: wg_TemperaturRegler_SwitchTr :200
2014-04-10 22:03:02 CUL_HM wg_TemperaturRegler_SwitchTr Short (to 123456)
2014-04-10 22:03:02 CUL_HM wg_TemperaturRegler_SwitchTr trigger: Short_F3
2014-04-10 22:03:02 CUL_HM wg_TemperaturRegler_SwitchTr level: 100

Das Gerät 123456 war va, vatc der zugehörige Kanal 01

Also va wieder hinzufügen und nochmal versuchen. Nach dem Einfügen wird aus (to 123456) wieder (to va)
Nach fünf Einträgen mit short (to va) hört der Trigger auf. Ein Trigger mit 0 wird aber nie gesendet.
Ein erneutes unset scheint das peering jetzt dauerhaft zu löschen.

Nun setze ich die SollTemperatur wieder auf  24°. Bei einer Isttemperatur von 22,3° müsste das Fenster offen bleiben. Es kommt aber ein Trigger 0, das Fenster schliesst.
Im Proto von wg_TemperaturRegler steht:

Code Auswählen Erweitern

protEvt_AESerrReject 2 last_at:2014-04-10 22:24:04
protEvt_AESok 1 last_at:2014-04-10 22:12:38
Wieso, wenn ich nirgendwo sign on habe?

Die Anzeige bleibt auch des öfteren stehen. In der Gruppe Internals steht dann z.B 8 CMDs pending und unter Readins state CMDs done. Erst ein Seitenrefresh aktualisiert dann die Anzeige.

Spass macht das nicht mehr so richtig, für heute reichts mir