apostolakisl

It was not checked. But wouldn't it be better for it to poll the status of programs (or whatever) that are currently displayed? In this case, I need to set it to poll all my programs every time for something I only need 1 percent of the time.

@Javi Suggestion: I read through the instructions linked to the advanced config via the question mark bubble, and it didn't mention that setting this up is tied to the node, not the favorite. I think that is worth putting in there. I would consider that to be something you might want to put as the first note about setting up advanced config since someone might easily see that and just stop before wasting any more time if they only want it to apply to that favorite. EDIT: One more issue, on a different favorite, I am using advanced config to display the status of a program (true idle/true false). But it doesn't seem to poll the value, it only shows it after it changes. Otherwise, blank.

OK, the same name error message appears on all the fan speeds, fyi. And the radio buttons are working great now. thx. Fixed my pool fountain buttons as well.

@JaviUsing the blank space works to make it not show the word "on", but it still shows the word "off"

@Javi One issue, when the fan is off, and the "fan off" favorite icon is turned red, the button reports "on" when the fan is off. The button name is "fan off", so it literally says "fan off on" (over two lines), or "fan off off" when the fan isn't off. It isn't the end of the world, but it is a bit screwy. My goal here is to just work like a KPL. No need for words on/off, just the color change is all that is needed, much like a KPL tells you what is going on by backlighting the one button. In short, it would be nice to set a "display node" that actually doesn't display anything, but rather just gets you access to setting the advanced status configuration. I have this same issue with some of pool controls showing confusing or useless info in the display section when all I really want is to be able to set the favorite icon color. EDIT: Also, why does it say "UD-Mobile-Name-Error" in the display status section?

Well, there was an easy fix. I just set it to track the status of the corresponding KPL button which I already have working correctly via programs and Insteon scenes. So each favorite display node is the corresponding KPL button and when the KPL button is on, the advanced config turns it red. I see also that everywhere that node appears now also turns red when on, consistent with what you said.

Not wanting a bunch of colors, just two. Here is what I want to happen: 4 button: off, low, med, high Whichever one is the current state, is red, the others are blue. If the fan is off, the variable is 0 and the "off" button is red, the other 3 are blue. If I hit the "high" button, the variable changes to 6, the "off" button turns blue, the "high" button turns red. And so on with the other two buttons. Just your basic radio button type configuration. Same way the KPL controlling the fan only lights the button that is currently active. It works if I use 4 different variables, but things are already so cluttered. But I guess you are saying that advanced configuration is tied to that node and there is only one possible advanced config per node, you can't have advanced config on the same display node behave differently for different favorites . . . end of story?

I am configuring favorites with buttons on my phone with each speed of a fan. I am tracking the fan status using a variable through a link to Alexa since there is no ISY node for this fan. - I have 4 buttons in UD Mobile, one for Low, med, high, and off - I want the button that represents the current state of the fan to be a different color - The tracking variable is set to 0,2,4,6 for the various states of the fan. The issue is that when I set a custom color for one button at one variable value, the other 3 buttons configuration changes to match. I can't use the same variable at different values to make different buttons change color at different values. This is on Android. I tried closing the app and re-opening. No change. Is this a bug or just something that is going to be this way?

This is not fully working like I had hoped. Alexa can fully control the fan and can recognize what state the fan is in from the fan controller screen. However, when using the fan status as a trigger in a routine, there is only "on" and "off". So I can't synchronize back to ISY the current state of the fan aside from "off" and "on", or in other, speed zero, and some speed that isn't zero. So I guess I am left with just telling ISY that the fan is on high when Alexa reports "on".

This fan uses a tuya controller. It has its own app and it links to Alexa for full control through Alexa. It has 6 speeds, but I am happy to simplify that to 0,2,4,6. Or in other words, off, low, med, high. I am using a keypad link to control it. I have full control of it using network resources from ISY sent to Alexa and that is working fine. But, I would like ISY to know the status of the fan if it is set from the handheld remote it came with. Alexa sees the fan speed settings when set by the remote and I was able to have Alexa set a variable to 0,2,4,6 on ISY. So, I can do it this way, but I would rather streamline this to get rid of the webhooks and have it all synchronize via the variable. Life would be easier if someone wrote a Tuya node. I believe they have a public api. Tuya.com I wish I had the time to learn how to write nodes, but I just can't take on another hobby.

I'm trying to use a variable to sync a fan. It is looking like I need to make a separate item on ud portal as a motion sensor for each speed of each fan. It looks like the "motion sensor" as a variable only sense "motion" when the variable is set to one particular value. Sure wish there was a node for my fans in ISY.

Thanks, does that mean I need to have it in twice if I want to both use it as a trigger and as something to take action on? @tazman

Trying to trigger an Alexa routine from an Insteon switch in ISY. I have a bunch of devices and some variables on ISY exposed to Alexa. They show up and I can control them from Alexa, even set variables. However, when I try to create a routine, they do not show up as options to trigger the routine (the When section). They do show up as things I can take action on in the "Alexa will" section. I can set a variable in ISY from an Alexa routine or turn on a light switch. I have lots of stuff show up in the "When" but nothing in there is from ISY. Within the "when" section , I am clicking on "smarthome" and find all the things that are linked to Alexa from other plugins, but nothing in there from the ISY plugin. In short, I can send commands to ISY nodes from Alexa using a routine, but I can not use an ISY event to trigger a routine. So, what am I missing here? @bmercier

@srjacob OK, misunderstood what you were asking. I had the native Elk module originally and converted to the Elk node server a couple years ago. The Elk node server does everything the module did plus a bit more. You will have some work to do, however. The nodes don't just convert over. If memory serves, I copied all the programs to clipboard and saved them all in a word document so I had them all written out to use as references when re-doing them.

Not sure what you are currently doing that has 30 programs that "deal with Elk", when it sounds like you do not currently have the Elk module. The Elk module lets ISY pretty much use Elk as a fancy I/O board. You can use all the input status' (the zones) in programs and you can control all the outputs from programs. You can also of course use all the armed states, alarm states, to trigger programs and can control the armed status of Elk directly from ISY programs. However, having ISY trigger Elk rules to run is not so easy. You can not trigger a rule directly from ISY. I have used "phantom" Elk outputs as triggers. If I want ISY to run a rule programmed into Elk, I have to do so by turning one of these phantom outputs on (an output that doesn't have an actual relay board, like output 100 or something) for 1 second and then rule triggers on that output turning on. If I hadn't already written boat loads of rules in my Elk, I probably would have just used ISY programs to do everything the rules are doing. But since I already had a bunch of Elk rules, I did the work around. Also, having Elk rules means I can execute them from Elk keypads using tasks, bypassing any dependence on ISY.