org.openhab.binding.rflink
org.openhab.binding.rflink copied to clipboard
cyrilcc
RTS Shutter position tracking
This is some BIG feature : being able to have a status on the RTS Shutter objects. This means :
- having a feedback status on the Shutter position (like : 50% on the OpenHab Shutter Thing Channel widget)
- being able to send a specific target position (like : Input 60% on the OpenHab Shutter Thing Channel widget -> the store will then start to move in the right direction and stop once at the expected position)
These features are pretty difficult to develop as the physical RTS Shutter is passive : it does NOT send any message, it only listen to messages (from physical remotes as well as from a virtual remote in the RfLink EPROM) and react to these messages. So we must "guess" the shutter position by replicating precisely the way the shutter works.
Well, 1st step is pushed on my fork. The RfLinkRTS device is now able to track the shutter position from the internal RfLink RTS remote (external physical remotes are not supported for now... it will come later on).
HOW DOES IT WORK
There is a new input in the RTS remote configuration :
in the config file, this is the following parameter : shutterDuration
You MUST set the shutter timing to enable the tracking. By "timing", I mean the time (in seconds) required by the roller shutter to go from one bound to the other (full CLOSED to full OPEN). By doing so, the RfLink plugin is able to "count" the time between the events, and deduce the position.
UNITS AND CONVENTION The Shutter duration is an Integer expressed in seconds The Position is expressed in percent of Opening :
- 0 means FULL CLOSED
- 100 means FULL OPEN a UP command will increase the position a DOWN command will decrease the position At startup, the position is assumed to be 0 (= FULL CLOSED) => there is no way to guess the real position
HOW TO USE IT
Once setup, you can interact with the Shutter channel on the RTS remote (the Swith widget is limited for these complex instructions)
So, two ways to input an order.
First using the UP/DOWN/STOP commands :
The Roller Shutter starts to move UP.
Meanwhile, the position on the widget is updated (almost) in real time.
In fact : the position is updated 1x/second on UP/DOWN moves, until you give another order, or the shutter is full open at 100%
On the STOP action, the RollerShutter will trop moving, and the position is updated a last time to reflect the actual position.
Second using the Percent input on the widget
By clicking on the Position, you can enter a target position.
On target position validation, the store will move in the right direction and stop on the target position.
You can order a STOP / UP / DOWN or even another target position whenever you want : the plugin will automatically update its position and process the new order.
NEXT STEPS
- Allow external physical remotes (linked to the physical RollerShutter) to interact also with this virtual position.
- on UP/DOWN moves, the Shutter widget value "blinks" at 0 or 100 percent before displaying the expected value. Need to find why
- Find a way to reduce "lag" on command send : it seems the RfLink bridge "freeze" for quite a while on some instructions (almost 1s on the STOP event)...
Do not hesitate to give me a feedback 👍
Hello !
PREVIOUS LIMITATIONS Here comes the second step of the "RTS tracking" solution. In the 1st implementation (posted on march 10th), the RfLink plugin is now able to "guess" the shutter position from the explicit commands sent from the RfLink Bridge (using the built in RfLink RTS system). But it does NOT work if you also gives order to your shutter using a physical remote controller.
NEW BEHAVIOR We can now track orders from other remotes (physical) and sync them on the position tracking system : a rollershutter can be managed from multiple input sources
HOW IT WORKS I have added the concept of "echo". This means : when an message is listened through the bridge on a specific Thing, we can apply transformations on the message to generate a new one and simulate it has been received. This allows a kind of "link" between things :
- the RTS remote tracks the position and transmit events to move the rollershutter (required if you want to set the rollershutter in a specific position)
- a (or even many) physical remote can listen and each incoming event resent to the RTS remote so it will handle the order and simulate the rollershutter movement accordingly.
PLUGIN VERSION REQUIRED I still have some rework to do, but I will push the developments by the end of the weekend on my fork. The RfLink plugin will be automatically generated.
CONFIGURATION As before, everything can be configured from the PaperUI interface. You don't need to edit any configuration file "By Hand".
Here is a view of my setup within the PaperUI "Thing" configuration panel :
I have 3 Things :
- a RfLink USB Bridge
- a RTS virtual remote managed by the RfLink (with position tracking enabled)
- a RTS physical remote attached to the shutter.
The RTS virtual remote configuration does not change :
- Device Id (deviceId : String) point to the RfLink RTS Address registered in the RfLink Bridge (note : switch id MUST be '0' in such case, according to the RfLink protocol documentation)
-
RollerShutter duration (shutterDuration : Integer) is set to the time the rollershutter needs to move from a fully closed position to a fully opened position. It enabled the position tracking system
The Somfy physical remote configuration is specific
- Device Id (deviceId : String) matches the messages we receive while pressing a button on the remote. In my case, while pressing the down button on the remote, I have this message in the log : <<< 20;02;RTS;ID=82e8ac;SWITCH=01;CMD=DOWN; So the DeviceId = RTS-82e8ac-01
-
Echo Pattern (echoPattern : String) is a new field, describing the transformations to apply on the incoming message to generate the echo message. In our case, we want the input message from the physical remote to be "transposed" to the RTS position tracker (enabled on the RfLink Remote Thing). The pattern is very simple : KEY=NEWVALUE, with ';' as separator.
In our case, we want the input message :
<<< 20;02;RTS;ID=82e8ac;SWITCH=01;CMD=DOWN;
to be transcoded to
<<< 20;02;RTS;ID=0F0FF2;SWITCH=0;CMD=DOWN; to be handled by the RTS remote. so we need to force the ID to 0F0FF2 and SWITCH to 0. the pattern is very simple : ID=0F0FF2;SWITCH=0
And we are done with the configuration 👍
USAGE By pressing one of the physical remote Key, the remote will emit an order. this order is grabbed by the rollershutter, and moves in the expected direction. ... but the same order is now also grabbed by the RfLink Bridge, and delegate the handling to the related Thing (physical remote). This Thing processes the echo pattern and generate a new "echo" order The RfLink Bridge delegates the handling of this new echo message to the related thing (virtual RTS remote with RTS position tracking support) The Thing process the events and simulate the rollershutter movement on the tracking system.
TIPS A> Physical Things channels are useless You can disable all channels on the physical Thing, as they are useless :
- you will NOT be able to send order through the physical Thing channel (you need to generate a unique message from the Rollingcode system... so you must create a virtual remote in the RfLink RTS system)
- you will NOT be able to track position, as the physical remote can not listen to events you emit from the existing remote.
B> You can mix orders from physical & RfLink RTS remotes : it works seamlessly
C> You can have multiple physical remotes for a RTS position tracker : in case you have a remote attached to your wall and a hand remote, you can configure each of them as a Thing in OpenHab, then set the echoPattern so they generate a new echo message that matches the RTS position tracker signature.
Great approach, but unfortunately last comment is long ago, so i guess this is not continued anymore? You're not moving this to the oh3 branch, do you?
