Best way to represent a Blind / blind state in Cortex

roller garage doors ... it's some time ago since we set ours up, so it's difficult to recall the exact thinking ... but, what we implemented was :

reed switches at each end of travel ... connected to a General Logic object ...

which then deduces whether the doors are open, opening, closing, or closed ... and feeds a virtual Door object for each door, which play the part of the actual doors - connected to the room, identified as connecting to the outside, etc ...

icon-wise, we have the virtual Doors shown as doors, and the reed-switches that register whether the doors are closed or not also shown as doors ...

latter being to show whether the doors are actually fully closed or not ... and the former showing when the door is fully open ...

we also have virtual relays fed by the General Logic that register the state of the doors (open, closed, opening, closing) and do the talking over the intercom to let the house know what's happening (it being useful to know when we're not the one doing the commanding) ...

seems complicated, but the end result is pretty effective ...

BTW - when we took the end-plate off the garage-door motor-units, we found a terminal strip, which gave access to all the commands - we wired Idratek relays to each, and included them in the General Logic ... as also various buttons about the house (at my desk, by each of the windows that overlook the front-yard, etc) ... single-click opens North, double-click opens South, long-press closes both ... plus various other functionalities ...

OK - not dissimilar to how I'd done the garage roller door, only I've only gone with a single reed switch in the "Closed" position to infer the status which I've found sufficient.

Blinds though .. there's no default "Blind" object, and clearly don't want to represent this as a door ..


Edit: From a little fiddling, I've now got this setup such that I've got a Virtual SRH, and added an On/Off load connection to the relay. Through this, I've found that in the behaviour menu, you can change this so that "This relay output represents a" and select "Curtains". With this, I get a Curtain Icon in Cortex like I was after

Is there any way to show granularity here though in terms of how "Open" a blind is? ... Ie, if I've got an extra position of "Half way open" for a roller blind, how can this be represented in Cortex?

how about stacking two Curtains icons one above the other in PlanView, and using General Logic & virtual relays to drive them ... ?

NB: can choose which icon is used in an object's PlanView menu (between Behaviour & Connections) ...

For motorised control of curtains and blinds there is a dedicated object. It is the Motor Control object found within the Design Network | Logic Objects list. Various icons are available to represent the nature of the end device e.g vertical blinds, horizontal blinds, louvre blinds, curtains, skylight etc. The icon reperesents an analogue value so alongside it there will be a % value representing level of opening. However... this object is designed to handle devices which are operated by controling the direction of a motor actuator which is connected to relays on the IDRATEK system. Various relay configurations are catered for depending on how motor direction is electrically effected. The object also has input connections for limit switches. Dead reckoning is also possible to roughly guess the position of a blind based on timing. If you are not in direct control of the motor in the way that this object expects then obviously it won't directly cater for your requirement but perhaps through some lateral thinking you can use it, as a virtual object, to represent variable state - e.g. 50% next to icon perhaps via an analogue input connection to the Set device open value input

Thanks ... this kind of helps, but as you suspected, I'm not actually in direct control of the motor.

I appreciate what I'm trying to do here is fudge things a little beyond what Cortex was designed to do ... but I've basically got a wireless blind motor (because wiring isn't an option) controlled over rest API's. With this, I've got 3 commands, which I've setup in a Virtual Web API Client - and represent "Open" "Stop" and "Close" - with the blind taking about 18 seconds to open or close.

So .. the Motor control object you describe is perfect in terms of representing the blind - and being able to tell it that it takes 18 seconds, so gives an inferred % open: this is perfect, but, there doesn't appear to be any way to connect this to trigger the 3 Web API requests as far as I can tell. The only output connections I can see are possible are to relays - which in turn also don't have an out connection to trigger the API


Best I've managed, is the On/Off Load object approach I describe above ...


Is there any way at all to trigger a Virtual API based on the "Open", "Close" and "Stop" options that the Motor Control object offers?

just a thought ... but, in making connections, we sometimes find the one we want is not offered at the end we choose ... only, often, to find it is available from the other end ... haven't investigated this particular situation, but could be worth a try ...


PS: have tried here, too - Virtual API and even Motor Control Relays seem to offer no connection possibilities ...

Indeed. Have fiddled a bit more, but can't get anything suitable to work ..

I managed to connect the Motor Object state output to an Virtual API Variable, and then connect this "On change" to a macro that then fires the API request depending on the binary state of the Virtual API variable, but the variable doesn't go "True" until the Motor control object considers the blind to be fully open ... so in 1 direction it'll fire immediately (good), but in the other, won't fire the "Close" API until the blind object is fully closed (so 18 seconds later) meaning the object isn't representative. This, and it still doesn't give any way to trigger any "Stop" command.

I think I'm out of luck

seems to me it's easy to fix, by opening something or other, but only Vivian or Karam can do it ...

So where is the demand to the motor object coming from? I.e the signals asking it to open/close/stop?

I was purely intending for now to use this Motor Control object (which I've chosen the roller blind icon for in plan view) for local control. Ie, the Motor control object shows up in the Mobile UI as a Blind, which has the "Open", "Close" and "Stop" controls. Later I was going to likely connect this to the 2nd button on an SLD that controls the room lights too for non mobile-phone control (single press for "Open", double-press for "Close" or something I guess). ... I'd likely have some form of schedule for closing the blind overnight / opening in the morning, and maybe in this room, 1/2 closing when a brightness level is exceeded too.

Motor relay output connections and a 'Busy' connection have been added to the motor control object. The former depend on the state of the control relays so different relay configurations will give different behaviours, and the Busy output could be inverted to create a positive stop signal. You can find these changes in the latest development update.

Thanks Karam - appreciate the update

With this, I seem to be pretty much "there".

I've setup a Motor Control object which I've assigned the roller-blind icon to in Plan View, and set the "Motor running period" values to be 1 second more than it actually seems to take the blind to open or close. The blind itself has stop limits, so to achieve "Fully open" or "Fully closed", firing a single API's open or close command will do the job. With this, I've set the "Type of motor control" as "Pulse Relay 1 to close, Pulse Relay 2 to open" and setup connections such that the "Relay 1" trigger output triggers the "Open" API .. and "Relay 2" trigger output triggers the "Close" API.

This all works fine so far as the "Normal" use-case where the blind is simply opened in the morning and closed at night (I'm going to attach this to the outside "Dark" state shortly I think).

The final step was to allow for the odd occasion where someone might want to have the blind "Partly open / closed" .. following your suggestion, I've connected the "Busy (Output)" of the Motor control object to a General Logic gate that is an "OR" Function that Triggers its' Output based on "To False" ... the output connections here don't allow direct connection to the Web API Client .. so I've had to link it to start a Macro object that has a single step of Triggering the Web API Client to send the "Stop" REST API.

This seems to work "Okay", but there's one foible I can't fathom yet (albeit I can probably live with it) .. I see the following happen;

1. With the blind fully Open, I hit "Close" in the Motor Control - the blind starts closing
2. At any point part way closed, I hit "Stop". This seems to trigger the "Stop" command via the logic gate / macro and the blind stops
3. but then after this, the blind reverses direction for a short burst (1 or 2 seconds), then "Stops" again ..

Not sure if this is Cortex issuing the extra commands, or whether there's something in the downstream API layer causing this ... need to do a bit more digging

that problem sounds a bit like one that caused us a while ago to abandon the specific buttons we'd added to Cortex Mobile via a Menu object plus associated General Logic & virtual Relays ... we tried lots of workarounds, but eventually gave up ... it seemed to be somehow specific to iPhone ...