Nein, das ist so nicht das, was ich beschrieben habe.
Punkt 1: Das Proxy Item wird nicht verlinkt. Überhaupt nicht. (Ein Link ist immer die Verbindung zu einem Channel, den es in diesem Fall nicht gibt)
Punkt 2: Du legst eine Rule an, welche über das Proxy Item getriggert wird, per received command.
Diese Rule errechnet anhand der vorher gemessenen Laufzeiten (getrennt für beide Richtungen, kann aber sein, dass bei horizontaler Bewegung beide Richtungen gleich lang sind, dann kannst Du natürlich auch mit nur einer Zeit arbeiten, aber bitte ausmessen) und der von der vorherigen Fahrt bekannten (gleich...) Position: bei den verschiedenen Befehlen verschiedene Dinge erledigt:
- Bei UP/DOWN den Startzeitpunkt speichern, so dass bei STOP die Dauer gemessen werden kann, außerdem wird der empfangene Befehl 1:1 an das "echte" Item geschickt.
- Bei STOP aus der vergangenen Fahrtdauer die neue Position berechnen und im Proxy Item speichern (per postUpdate). Außerdem wird an das "echte" Item der Befehl STOP gesendet.
- Bei einer Positionsangabe errechnen, wie viele Sekunden die Soll-Position von der Ist-Position entfernt ist und in welche Richtung der Antrieb laufen muss, den Antrieb starten und einen Timer starten, der den Antrieb nach der errechneten Zeit stoppt. Außerdem kann dieser Teil der Rule gleich die neue Ist-Position per postUpdate im Proxy Item speichern.
All das erledigt die weiter oben gezeigte Rule.
Wenn Du nun bei > 20 °C den Store in Position X fahren willst, schreibst Du eine Rule, welche bei Temperatur changed triggert.
Über but only if legst Du fest, dass der Rule Code nur ausgeführt werden soll, wenn die Temperatur größer 20 °C ist.
Außerdem soll die Rule nur ausgeführt werden, wenn das Proxy Item (nicht das "echte") von der angegebenen Position abweicht. Wobei es vermutlich sinnvoll ist, sich hier für einen Bereich zu entscheiden, also z.B. Store soll zu 80 % geschlossen werden -> Alles was über 75 % ist, wird als "Store steht schon auf Sollposition" gewertet, also ProxyItem <= 75.
In der Rule wird als Action nur ein einziger Befehl ausgeführt, nämlich ProxyItem.sendCommand(80).
Das heißt, Du legst zwei Rules an, die eine kümmert sich ausschließlich um die Positionsfahrt als solche, die andere gibt ausschließlich einen Steuerbefehl.
In der UI wird ausschließlich das Proxy Item sichtbar gemacht. Du bedienst den Store - soweit es openHAB betrifft - ausschließlich über das Proxy Item.
Proxy -> Stellvertreter. Das Proxy Item nimmt die Position des "echten" Items stellvertretend ein. Über die Rule im Hintergrund hat es zusätzliche Fähigkeiten, das ist der ganze Sinn der Aktion, es wird das Verhalten eines Aktors mit eingebauter Positionsfahrt emuliert.
Da Laufzeiten niemals auf die Millisekunde gleich sein werden (selbst für exakt gleiche Strecken in der gleichen Richtung) muss man mit gewissen Toleranzen leben. Das ist aber erfahrungsgemäß kein echtes Problem, da - z.B. in diesem Fall - ein Store oft immer mal wieder in eine der beiden Endstellungen gefahren wird (über UP oder DOWN, ohne selbst ein STOP zu senden). Man kann also nun die STOP-Meldung vom Aktor registrieren und mit in die Steuerung einbeziehen.
Eine weitere Möglichkeit besteht darin, bei UP/DOWN einen Timer zu starten, der nach tMax (also der maximal möglichen Laufzeit) zusätzlich ein STOP an das Proxy Item sendet, womit die Rule getriggert wird. Da im Zweifel mehr als die maximal mögliche Zeit vergangen ist, kommt bei der Berechnung der Position entweder ein negativer Wert heraus -> neue Position 0, oder es kommt ein Wert über 100 raus -> neue Position 100.
Ich hab jetzt gerade keine Lust, zu prüfen, ob ich das oben schon eingebaut habe, falls nicht, ist es jedenfalls keine große Sache, das nachzurüsten.