Automated curtain with Insteon

insteonplm
insteon
Tags: #<Tag:0x00007fe066358970> #<Tag:0x00007fe066358768>
(Garrett Porter) #1

I’m going to document this here since there are so few people who seem to have done this project. I couldn’t really find any documentation on the Insteon open/close module (one other person had a thread about it it so that helped me set it up right).

My setup includes:
Hardware
-Insteon micro open close module 2444-222
-KT82TS curtain motor, I think this is Dooya brand (4 wires - hot open, hot close, neutral, ground)
-A curtain (not pictured, it’s white and needs to be ironed)

Items:

Dimmer BigWindow  "Big Window"  {insteonplm="2c.64.08:F00.00.01#dimmer"} 
Switch curtain   "Curtain" ["Switchable"]

Rules:

rule "Open Window"
when
    Item curtain received command ON
then
    BigWindow.sendCommand(0)
end

rule "Close Window"
when
    Item curtain received command OFF
then
    BigWindow.sendCommand(100)
end

Note my wires are “switched” (so open BigWindow = off state) which I will probably fix in a few days when I install everything properly in an electrical box.

The open/close Insteon module is wired to the Dooya motor then programmed to provide power to the motor for a certain amount of time. It took me a couple of tries to get the timing just right, but I’m happy with it now.

Another option that we are unlikely to use is to set the Insteon module to “50%” as it’s actually seen as a dimmer. This makes the motor run for half of the time as full open. Not useful in my setup at this point (we always want all the way open or closed) so I’ve sent the mapping to a switch for HomeKit.

Now the fun part, I made a gif for y’all to see it in action -

GIF%20image-656D08737F05-1

(Vincent Regaud) #2 
rule "Window"
when
    Item curtain received command ON
then
    if (previousState == NULL) return;
    if (receivedCommand == ON) BigWindow.sendCommand(0) else BigWindow.sendCommand(0)
end

After you switch your wires it’s even simpler…

rule "Window"
when
    Item curtain received command ON
then
    if (previousState == NULL) return;
    BigWindow.sendCommand(receivedCommand)
end

That’s because a Dimmer accepts the commands ON and OFF

(Garrett Porter) #3

Is the purpose of this line just to prevent the edge case where the curtain and switch are out of sync (startup, etc)?

    if (previousState == NULL) return;

If so, I think an even better solution would be the following two rules (to take advantage of Insteon polling)

rule "Insteon open close Status to Window"
when
    Item BigWindow received update
then
    if (receivedUpdate <= 50) curtain.postUpdate(OFF);
    if (receivedUpdate > 50) curtain.postUpdate(ON)
end

rule "Window Switch to Insteon"
when
    Item curtain received command
then
    BigWindow.sendCommand(receivedCommand)
end

First rule should keep things in sync (apart from the ~5 minutes between polling) and the second rule should translate the HomeKit switch to the dimmer.

Please correct me if I’m wrong, I’m at work and just put that together - this is currently untested.

(Vincent Regaud) #4

Unfortunately there is no intrinsic variable receivedUdpdate.

(Garrett Porter) #5

Should be easy enough to fix…

Change the first rule to:

rule "Insteon open close Status to Window"
when
    Item BigWindow received update
then
    if (BigWindow.state <= 50) curtain.postUpdate(OFF);
    if (BigWindow.state > 50) curtain.postUpdate(ON)
end

I believe the state of the Insteon dimmers is always a number - so this should work?

(Vincent Regaud) #6

Except for NULL

(Garrett Porter) #7

Does Insteon poll ever return NULL?

(Vincent Regaud) #8

No but an oh restart does. Or an item file edit

(Garrett Porter) #9

Essentially the purpose of that rule would be to set the correct state for my HomeKit switch after a restart.

It’ll take up to 5 minutes then the Insteon will poll the open/close module - causing this rule to set the proper state of “Curtain” for use. No reason really to treat NULL differently because the state is unknown until the poll happens so NULL on both the switch and dimmer should be fine.

(Rich Koshak) #10

And in this case previousState wouldn’t exist either because the rule trigger is received command. previousState only exists for Rules triggered by changed. The check should be:

if(curtain.state == NULL) return;

@crxporter, the check is important because your Item might receive an update to NULL under a number of circumstances and in many of those cases it will cause the Rule to trigger and you will get errrors in the log when that happens.

(Garrett Porter) #11

I was thinking that all possible updates are numerical between 0-100, “ON”, “OFF”, and “NULL”. So my rule checking greater or less than 50 would complete one of the two if statements but there would be no action for ON/OFF/NULL because they are not “less than” or “greater than” 50…

I am still at work so I haven’t tried this yet. I’m sure you’re right since I am still quite new at openhab. Will getting NULL when checking for numerical values in my if statement cause errors?

It would need to be this though because the insteon item is what receives updates with the polling.

rule "Insteon open close Status to Window"
when
    Item BigWindow received update
then
    if (BigWindow.state == NULL) return;
    if (BigWindow.state <= 50) curtain.postUpdate(OFF);
    if (BigWindow.state > 50) curtain.postUpdate(ON)
end
(Rich Koshak) #12

NULL is not a Number so it doesn’t implement > . That line would generate an exception. The same goes for ON/OFF but because you are using received update, you are getting the state of the Item as it is stored by the Item, which in this case is a PercentType (i.e. number between 0 and 100). So the comparison would work after sending ON or OFF to the Item.

That code looks good. Ignore the case when the Item’s state is undefined (that is what NULL means). You could turn the second two lines into a one-liner if you wanted to:

if(BigWindow.state == NULL) return;
curtain.postUpdate(if(BigWindow.state <=50) OFF else ON)