virtual device to simulate window control handled by two binary switches?

Developer's Corner General Dev Discussions
#1

I am new to virtual devices, luup and vera in general, but i am willing to learn and reasonably experienced in software development.

This is the current situation
i am controlling some windows using a fibaro 2x1,5kw switch, hooked up to switch an external DC power supply to the motors.
These window motors work through phase reversing, so open/close is controlled by switching the power supply to the corresponding contacts.
What i am currently doing is using scenes to open/close, these scenes are switching the open/close contacts on, wait 21 seconds, and switch them off again.
While that generally works pretty well, it is misrepresented in the UI and prone to user error.
So in the UI there are 2 switches for each motor, if someone where to switch both on, the motor will probably be damaged, if someone would leave one of the switches on for more than 21 seconds, the motor will probably burn out.

In order to conquer this and gain some usability, i would like to have a virtual device that ?mplements an open/close toggle or something similar, this toggle should either trigger the open/close scenes or implement the same using lua.
It’s probably not going to be easy, but if at all possible i would also like to “block” the momentary switches that are hooked to the fibaro relay, so if pressed, they trigger the relay for 21 seconds, regardless of how long they are pressed.
if the window state is closed, the momentary switch for “close” should not trigger closing them again.

Is any or all of this feasable and doable?

Any pointers on how to proceed would be greatly appreciated

I am running UI7 on a vera edge.

Thanks!

#2

As you say, this could be tricky. There are some things you can do, though.

The Fibaro FGS-221 has a built-in auto-off feature. If you set that to 21 seconds, it would solve one of your problems.

To prevent unintentional operation of the switches through the UI, you could hide them. They would still be available for scene actions. The Lua for this is:

luup.attr_set("invisible","1",123)

Change 123 for the actual device ID that you want to hide. Place this/these lines in Vera’s Startup Lua using: Apps → Develop Apps → Edit Startup Lua. Then click GO. The devices will vanish after Luup reloads and you refresh your browser page. You can get them back by removing the lines or changing them to:

luup.attr_set("invisible","",123)

Creating a new device type is not a trivial task. It would be a lot easier to use the UI of an existing one. In your case the WindowCovering device could be a good start.

You can create a virtual device to see how it looks by:

Upload the attached file using Apps → Develop apps → Luup files → Upload then selecting the file. Click Done and wait for Vera to restart.

Apps → Develop apps → Create device. Enter something appropriate for Description. Enter D_WindowCovering1.xml for Upnp Device Filename and I_WindowCovering1.xml for Upnp Implementation Filename. Do not enter anything in the other fields. Then click Create device. After Vera restarts, refresh your browser.

The simple Implementation file does not do much but you can trigger scenes from the device variables. You can add your own code to this as required. If you do, it would be sensible to change the file name and update the field on the device’s Advanced tab.

The virtual device uses the variable LoadLevelStatus to indicate the blind position. 0 = Down, 100 = Up.

local dID = 123 -- Device ID of virtual device local level = luup.variable_get("urn:upnp-org:serviceId:Dimming1", "LoadLevelStatus", dID)

#3

It looks as though the WindowCovering1 json file escaped being converted for UI7 - the icon is not displayed.

If you decide that you want to use this as a virtual device, I can let you have a modified version that does display icons.

#4

wow, that’s a pretty comprehensive reply there, kudos to you sir!

so i’ve spent the last 2 hours playing with this and it actually looks pretty promising.
I have added some LUA and some variables to make it so it initializes the variables on startup (for them to become visible in the advanced tab)
It let’s you configure your binary switches for Up/Down Open/Close of your rollers/windows as well as the total time it takes to fully open/close
what i am doing is calculating the time needed to reach a specific load level, from there it calls the actions for switching on/off the up/down buttons and resets them after the time calculated from the load target level
i know this is not an exact science, but rather a guesstimate, but it does not really matter, as long as i close the windows for a couple of seconds longer then they will ever take to fully close i can be sure that they will be closed.

Thanks for the invisible tip, now usability is much better from the UI, i can just use the WindowCovering Device and get rid of the scenes.

So as of now this works for Up/Down/Stop, Open/Close and selecting level from the dimmer bar.
The last but not least important thing that’s missing is connecting this to the actual physical switches themselves.
Because now imagine someone presses the up/down switch manually, the WindowCovering device will be out of sync unless i can somehow intercept or hook into that event.
I guess intercepting won’t be doable, so hooking into it will do, if i can somehow use the length of the activation of each of these buttons, i could sync that to the WindowCovering device to keep them in sync.

From what i read in the docs i could probably try variable_watch or job_watch, if that triggers fast enough, then there is my hook

I am using the WindowCovering1.json, i saw there was some mention of an icon, but since it displays a dimmer and some buttons anyway, i kind of rolled with it.
What are the differences as far as converting goes, what needs to be changed?

#5
From what i read in the docs i could probably try variable_watch or job_watch, if that triggers fast enough, then there is my hook

Setting a variable-watch on the switches’ Status variable would be the way to go. This is very fast. There is some example code here that will give you an idea how it works.

I am using the WindowCovering1.json, i saw there was some mention of an icon, but since it displays a dimmer and some buttons anyway, i kind of rolled with it. What are the differences as far as converting goes, what needs to be changed?

I have attached a json file that is modified to use some icons I built for another project. If you upload this to Vera, you can get your device to use it by editing the device_json field on the Advanced tab - followed by a Reload and Browser refresh.

You will also need to copy the png files in the attached ZIP to Vera’s folder /www/cmh/skins/default/img/devices/device_states. The easy way to do this is with WinSCP. I have attached instructions for getting this working.

If you don’t like the icons, it is quite easy to make your own. They are just 50 x 50 pngs.

#6

Another thought:

It sounds as though you are controlling both on and off states of the switches from your plugin code. Bare in mind that, if Vera restarts, the off action may never get sent. This is why I suggested using the FGS-211’s auto-off mechanism. It could save you letting the magic smoke out of your motors…

#7

I have never liked having a slider on my WindowControl UI. In most cases, with a virtual device, you cannot use it to set intermediate positions so it is just a distraction. If you feel the same way, I have attached a version of the json that removes it.

#8

I’ve created a virtual window cover to control blinds on a series of skylights.

The interface to the skylight controller requires a dry contact relay (one for up, another for down) so am using a dual relay for this (set to turn on only for a second).

As per the others on this thread, my interest has been to collapse what are currently two binary switches controlling the blind into a single window control device (and then hide the binary switches).

Because I can’t actually control the position of the blind (they all open fully in sequence, or vice versa), I’d like to remove the slider as per the comments above. To avoid clashing with my other (physical) window covers, that do support the slider, do I need to rename each of the implemetation files?
…

Problem now solved (bypassed) by using the custom panel plugin. created a panel that looks just like the window cover device I need. Even gives the outdoor temperature!