Fanlinc and KPL issue - if fan device is used

[drich]

I have a handful of FanLincs being controlled by KPLs (I really wish there was a better option) and for the most part they work really well. The one problem is if someone uses the fan device instead of the scene to control the fan. If they do (or if some other home automation software turns on the fan like HassIO) the fan will come on, but the KPL buttons don't light up.

I figured the easy way around this was with a group of programs, but I still can't get them working. For example, take the following programs:

If
    'Fans / Great Room Fan' Status is not off
  And 'Fans / Great Room Fan' Status is Low
  And 'Fans / Great Room Fan' Status is not Med
  And 'Fans / Great Room Fan' Status is not High
Then
    Set 'Fans / Great Room Fan Low' On
Else

If
    'Fans / Great Room Fan' Status is not off
  And 'Fans / Great Room Fan' Status is not Low
  And 'Fans / Great Room Fan' Status is Med
  And 'Fans / Great Room Fan' Status is not High
Then
    Set 'Fans / Great Room Fan Med' On
Else

# Repeat for High and Off, with Off turning all threse scenes off in the Then block as I don't use the 'D' button to indicate off 
#
# 'Fans / Great Room Fan' is the device node, 'Fans / Great Room Fan Low' (Med and High) are the scenes

This actually works -- sometimes. The first time I set the 'Fans / Great Room Fan' device to a speed, the correct scene (Low/Med/High) will be triggered. However, if I change the speed the first speed KPL button will go out, no other button lights up. The program status appears correct, the Low/Med/High/Off program will show true for whatever speed is selected. And if I look at the scenes themselves, they show the correct button status; i.e. if I go from Med to Low, they show the fan at Medium and the Low button as "On".  Given that I have nothing in the Else block for any of these, I'm not sure why the buttons are turning off (probably because the scene change is getting partially triggered), much less why they aren't turning on after the first on. I'm assuming there is some sort of race condition in here somewhere, but I'm stumped f I can find it.

This leads to a couple of questions...

1. What is going on that might be causing this behavior?
2. Is there a better way to get the buttons to respond to changes in the fan device, or are programs the only way?

[larryllix]

The KPL button LEDs can only be operated by scenes.
 

I am not sure which devices are buttons and which are the fanlinc device in your programs.

Each program only requires one trigger. The other lines do not perform any function.

If 
     'Fans / Great Room Fan' Status is Low

Then
     Set 'Fans / Great Room Fan Low' On

Else --

I would use a state variable and a program and scene for each speed (x4). Then I would use another four programs to set the variable from the KPL. Later, if desired, any program can control your fan by injecting a speed number into that variable. Also a program could convert the operation to one, or two button control if desired. Even a SwitchLinc could then control your fan speeds with a program by rotating the speed number through 0-3.

Did you know you can right click on a program and select copy to clipboard, then paste it in a post?

[drich]

1 minute ago, larryllix said:

The KPL button LEDs can only be operated by scenes.

Yep, that's why I'm trying to trigger the scenes when the device state changes.

1 minute ago, larryllix said:

I am not sure which devices are buttons and which are the fanlinc device in your programs.

See the comment in the code block: " 'Fans / Great Room Fan' is the device node, 'Fans / Great Room Fan Low' (Med and High) are the scenes". I.e. anything with "Low/Med/High/Off" in the name is a scene.

So the "if" is checking the device status, the "then" block is triggering the scene.

1 minute ago, larryllix said:

Each program only requires one trigger. The other lines do not perform any function.

If 
     'Fans / Great Room Fan' Status is Low

Then
     Set 'Fans / Great Room Fan Low' On

Else --

Is this new in 15.x?  This wasn't the case in prior releases. Using your code, the status of the program would never change to false in the past. If you look back at some of the early posts I made when I first got started with the ISY (almost 10 years ago) I was told to always write code like:

If
    'X' is On
  And 'X' is not Off

Otherwise the Else condition never triggers (not really an issue in this case since I am not using Else)

However, I just tried it with the fan programs and the state does do the right thing with just the single If statement - thanks!

 

1 minute ago, larryllix said:

I would use a state variable and a program and scene for each speed (x4). Then I would use another four programs to set the variable from the KPL. Later, if desired, any program can control your fan by injecting a speed number into that variable. Also a program could convert the operation to one, or two button control if desired. Even a SwitchLinc could then control your fan speeds with a program by rotating the speed number through 0-3.

Did you know you can right click on a program and select copy to clipboard, then paste it in a post?

Huh, I never noticed that "Copy to Clipboard" before... Easier than retyping like I did above!

Using state variables is a thought... I went down that route with my Whole House Fan since it doesn't have native fan support, it instead depends on a Network Resource I put together a few years back. (Airscape 1.7 WHF). I'm not sure that addresses the issue where the device itself is triggered though, that's the whole reason I started working on this program in the first place. I'm having a hard time getting the rest of the household to run the scenes when they can see the devices in MobilLinc, and other systems like HassIO see the fan nodes natively.

[drich]

Well this is interesting... I just tried the same group of four programs on a different Fanlinc/KPL combination, and it works perfectly. There's something up with this particular KPL, but even doing a restore doesn't seem to fix it. It works fine locally but even running the scenes from MobilLinc only triggers whatever button is turned on first - I.e.

• If I trigger the Low scene, the low button (C) will come on.
• If I then trigger Med, the fan goes to medium speed, the Low button (C) turns off but the Med button (B) doesn't turn on
• At this point, only the Low button will light from triggering any of the scenes, Med (B) and High (A) stay dim no matter what speed the fan is running at.
• If I press any of the buttons on the KPL it triggers the correct scene. And it resets which button lights up -- after I use a button whichever scene I trigger from MobiLinc will light the correct button, but then the other two buttons won't light up.

I've checked both of the KPLs are identical - all buttons set to toggle and the scenes control the grouping, I haven't used the "Buttons Grouping" button in the UI. They are both of the same generating, both showing v.40 in the ISY Admin app.

[larryllix]

41 minutes ago, drich said:

<snippage>

Is this new in 15.x?  This wasn't the case in prior releases. Using your code, the status of the program would never change to false in the past. If you look back at some of the early posts I made when I first got started with the ISY (almost 10 years ago) I was told to always write code like:

If
    'X' is On
  And 'X' is not Off

Otherwise the Else condition never triggers (not really an issue in this case since I am not using Else)

However, I just tried it with the fan programs and the state does do the right thing with just the single If statement - thanks!

<snippage>

That was a good technique if you had any code in the Else section. You do not show any.
That worked for Control/Switched constructs. Using Status already preforms True or False and runs Then or Else. When you use Control/Switched the only time the If is being evaluated is when a device is being switched. No other control/switched lines will ever be true at the same time. This makes some strange looking/functioning logic.

The multiple conditions puzzled me why it should make any difference but using status here is what I think happened.
The KPL is switched to Low
Your low program detects this as true and al the other ANDed conditions see NOT xxx as true
Then runs - the program changes the fanlinc setting
ISY wakes up the program again as the status has changed
All the conditions are true again and runs the program again....setting the fanlinc again
ISY wakes up the program again as the status has changed in all the lines
All the conditions are True again and Then runs again...etting the fanlinc again.
etc...etc.... etc.....
 

I am surprised we haven't seen complaints about your ISY hanging or running very slowly here.
I am surprised we haven't heard about the ALL ON phenomenon here, as you were  likely blasting this fanlinc, and KPL LEDs, with high speed long blasts of signals.

If you decide to try the variable route I would only use control/switched constructs.

Glad this worked out for you!! 

[oberkc]

8 hours ago, drich said:

Is this new in 15.x?  This wasn't the case in prior releases. Using your code, the status of the program would never change to false in the past. If you look back at some of the early posts I made when I first got started with the ISY (almost 10 years ago) I was told to always write code like:

I do not think anything has change in the new 5.x software here.  a "status" condition would trigger upon any CHANGE in status, whether from ON>>>OFF  or OFF>>>ON and would trigger both THEN and ELSE actions.  I believe this is true in software v4x and v5x.

"Control" conditions, however, would require the "not" condition in order to cover both ON and OFF commands.  All the confusion I have noticed over the years is in regards to the "control" conditions.

[larryllix]

I do not think anything has change in the new 5.x software here.  a "status" condition would trigger upon any CHANGE in status, whether from ON>>>OFF  or OFF>>>ON and would trigger both THEN and ELSE actions.  I believe this is true in software v4x and v5x.
"Control" conditions, however, would require the "not" condition in order to cover both ON and OFF commands.  All the confusion I have noticed over the years is in regards to the "control" conditions.

Expanding that somewhat...

'Control switched on' and,
'Control switched off'
are two different devices, each with two states.
Status is one device with two states.

Sent using Tapatalk

[drich]

2 hours ago, larryllix said:

Expanding that somewhat...

'Control switched on' and,
'Control switched off'
are two different devices, each with two states.
Status is one device with two states.

Thanks, that clears it up! I need to go through my code and see if I have any other lingering checks that have both conditions on a status instead of a control.

Now if I can just figure out what is up with that one KPL.... I need to go through and add the programs to two more KPL to see if they behave properly as well.

[gzahar]

What firmware version are you using?  If not 5.0.15A, see 678 below.

5.0.15A Beta is now available, it contains the following fixes in addition to the changes below

Fixes:

0000675 - Z-Wave Garage door open/close commands not available

0000676 - Consistent use of operator names in program conditions XML (X10 "is not" program fails to load)

0000677 - Default to supporting all button presses for Z-Wave central scene controllers when actual supported is unknown

0000678 - FanLinc Low status may not cause programs to run

0000679 - Support node server thermostats in ADR

Developers:
- Starting in version 5.0.15A, the event value for the Low status of Insteon FanLinc Motor changes from 63 to 64

[drich]

4 hours ago, gzahar said:

What firmware version are you using?  If not 5.0.15A, see 678 below.

5.0.15A Beta is now available, it contains the following fixes in addition to the changes below

Fixes:

0000675 - Z-Wave Garage door open/close commands not available

0000676 - Consistent use of operator names in program conditions XML (X10 "is not" program fails to load)

0000677 - Default to supporting all button presses for Z-Wave central scene controllers when actual supported is unknown

0000678 - FanLinc Low status may not cause programs to run

0000679 - Support node server thermostats in ADR

Developers:
- Starting in version 5.0.15A, the event value for the Low status of Insteon FanLinc Motor changes from 63 to 64

Thanks, I upgraded to 5.0.15A as soon as it came out for that very reason. 

[kclenden]

On 9/2/2019 at 10:21 PM, drich said:

Well this is interesting... I just tried the same group of four programs on a different Fanlinc/KPL combination, and it works perfectly. There's something up with this particular KPL, but even doing a restore doesn't seem to fix it. It works fine locally but even running the scenes from MobilLinc only triggers whatever button is turned on first - I.e.

• If I trigger the Low scene, the low button (C) will come on.
• If I then trigger Med, the fan goes to medium speed, the Low button (C) turns off but the Med button (B) doesn't turn on
• At this point, only the Low button will light from triggering any of the scenes, Med (B) and High (A) stay dim no matter what speed the fan is running at.
• If I press any of the buttons on the KPL it triggers the correct scene. And it resets which button lights up -- after I use a button whichever scene I trigger from MobiLinc will light the correct button, but then the other two buttons won't light up.

I've checked both of the KPLs are identical - all buttons set to toggle and the scenes control the grouping, I haven't used the "Buttons Grouping" button in the UI. They are both of the same generating, both showing v.40 in the ISY Admin app.

I don't really have an explanation for the results you're reporting, but the fact that the scenes work correctly when triggered locally, but not when remotely triggered seems to imply that you don't have something configured correctly for that device's scenes in the Admin console.  In actuality, the scene that it executed when you press a button locally is completely different from the scene that is executed when the scene is controlled remotely.

When you look at the scene in the Admin Console, you'll see the scene name and then indented beneath it will be each device that is enrolled in the scene (responders and controllers).  In my case all of the responders are shown in blue text and the controllers are in red text.  If you click on a controller (i.e. red text) in the scene, you'll see the scene that is executed when you press a button locally.  If you click on a responder (i.e blue text), you'll see what the responder should do when the scene is executed remotely.  So for each scene defined in the Admin Console, all of the blue text represents what should happen when that scene is executed remotely and each red text represents what should happen when a local button is pressed.  You should check all of the blue text for your scene in question to make sure that each responder is appropriately set.

[drich]

9 hours ago, kclenden said:

I don't really have an explanation for the results you're reporting, but the fact that the scenes work correctly when triggered locally, but not when remotely triggered seems to imply that you don't have something configured correctly for that device's scenes in the Admin console.  In actuality, the scene that it executed when you press a button locally is completely different from the scene that is executed when the scene is controlled remotely.

When you look at the scene in the Admin Console, you'll see the scene name and then indented beneath it will be each device that is enrolled in the scene (responders and controllers).  In my case all of the responders are shown in blue text and the controllers are in red text.  If you click on a controller (i.e. red text) in the scene, you'll see the scene that is executed when you press a button locally.  If you click on a responder (i.e blue text), you'll see what the responder should do when the scene is executed remotely.  So for each scene defined in the Admin Console, all of the blue text represents what should happen when that scene is executed remotely and each red text represents what should happen when a local button is pressed.  You should check all of the blue text for your scene in question to make sure that each responder is appropriately set.

Yep, I went through all the settings when I first started seeing this issue and can't find anything off. The weird thing is that the scene works fine remotely the first time I run it, no matter which of the three scenes I pick (High/Med/Low). But at that point until I activate a scene locally, that's the only button that will light up on the KPL. In 10+ years of working with Insteon and the ISY this is the first time I've seen anything like this.

I'm probably going to just delete the scenes tonight, reset the button grouping, and recreate them. I need to add one more KPL for a new fan anyway, so I may as well rebuild this one at the same time.