apostolakisl

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.

I did this very thing with great success for 10 years. I buried a 120vac wire between the two buildings and put an outlet on the side of the other building where I plugged in an old Insteon hub. The Insteon hub has a very strong radio interface. The powerline carried the signal to the hub and the hub converted it to radio that my insteon devices in building 2 connected to. It worked flawlessly, almost better than in the primary building. My buildings were over 100 feet apart as well. You could potentially only run the buried wire part of the way, just getting it close enough for the radio on the Insteon device to get a good signal in building 2. You can always test things out by just running an extension cord to various locations.

I didn't really check, but is the issue with the nodes connecting to ISY or the nodes connecting to the various 3rd part things they connect to? If the disconnect is to the third party items, I am surprised that they don't reconnect on their own since I can reboot the third party devices or reboot my router and as long as Polisy stays up, the nodes reconnect.

I have seen the same issue with my polisy. After power outages, I have to go through and restart my individual polyglot nodes to get them to connect. From the console, they all report "connected", but they aren't. I have not seen issues connecting to the portal.

I get that, but I find it surprising that UD would not have managed their supply times better knowing all that, unless the manufacturer had supply chain issues, but then I would expect that I wouldn't be able to get it on Amazon. Perhaps there is some unique hardware component the UD wanted that went on backorder.

Curious that it is available overnight on Amazon and UD is backordered.

Steps: 1) In ISY's main page, find the old switch and remove it from any folders it might be in and place it in the root folder. Just the switch itself, not any scenes. 2) Join the new switch to ISY - put ISY in linking mode by hitting the swirly arrow icon and then - press and hold the tab on the new switch for a few seconds until it beeps - the new switch should pop up on the admin console, tell it to go ahead and join ISY and erase any info on it already. You can name the switch if you like, or just leave it with the address. Whatever you do, just make note of the name. 3) Right click on the old switch and select "replace with" and then select your new switch. 4) ISY will automatically go through and write all the info to all the switches involved with that switch. It make take a bit (seconds up to maybe a minute) depending on how many scenes it was in. 5) Restart your admin console 6) The new switch will now have the name of the one it replaced. You can drag and drop it into any folder it might have been in before.

You do have the advantage here that you are wiring just swapping out one device for another where they are basically identical. So there should not be any confusion. Just be certain that you have shut the breaker off, as mentioned. Insteon devices don't like if you wire them hot and get sparks. As an extra precaution, I always pull the hard disconnect on the device while wiring it in.

You would have to have a pretty old device to have the bad tact switches in them. Smarthome replaced every switch in my house under warranty for that like 15 years ago. I haven't had any of the replacements do that. The switches have a date code on them on a sticker that is visible if you take the switchplate cover off. It will be a year and week. I forget what order, but it would be something like 3422 meaning the 34th week of 2022. Ot maybe it would be 2234. As you know, the 2476ST isn't made anymore, but it isn't necessary. Use programs in ISY to do your timing rather than having the switch natively do it. A 2477S is a relay switch (on/off only, no dimming) designed for controlling things that shouldn't have dimming at all (motors/fluorescent lights). 2477S is also a dual band, so it uses radio and power line communication which makes it much more reliable.

Might do it this way depending on your needs. This mod to the program above causes the counter to trigger on you setting the variable to whatever time period you want to wait. Shouldn't need two programs (depending on how you are setting the variable for countdown) as this program won't re-trigger unless you change the value of that variable mid count, in which case I assume you would want it to start over. In summary, the below program runs as soon as you set the variable $chosenvartowait to any positive number. It will then count every second until it reaches that number. Obviously, change your wait time to minutes or hours or whatever if you want to count those instead. Also note, I moved the wait 1 second line up above the add 1 to the variable line. I think it would terminate 1 second too soon otherwise. And I moved the reset of the counter variable to the first line ensuring if you change the variable mid count it will reset it. ID - [ID 0058][Parent 0093] If If $chosenvartowait > 0 (need to setup this variable as a state variable) Then $countervar = 0 Repeat While $countervar < $chosenvartowait Wait 1 second $countervar += 1 Repeat 1 times Set whatever you want to happen Else - No Actions - (To add one, press 'Action')

I don't know of any way to do that directly. The best I can think of is to use "repeat while" as guy mentioned and then set a program to count. Something like ID - [ID 0058][Parent 0093] If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then (optional line here to disable triggering program) Repeat While $countervar < $chosenvartowait $countervar += 1 Wait 1 second Repeat 1 times Set whatever you want to happen $countervar = 0 (optional line here to re-enable triggering program) Else - No Actions - (To add one, press 'Action') You just have to make sure whatever you put in your "if" section doesn't re-trigger and cancel the wait midstream leaving the countervar at some counted up value. You may make this two programs and have this program be disabled and have the first program run this program and set this program to disable then re-enable the first program.

did you try a reboot of the whole thing? I usually use putty to login (admin/admin) then enter the command "sudo reboot" Or if you want to really make sure, I believe the command is "sudo shutdown", let the unit shutdown and then pull power for 30 seconds.

If linking mode isn't working, then you either have a faulty switch or a seriously bad communication issue. You can try manually adding as per Paul, but I suspect that won't work. And if it does work, then it means something is wrong with the switch since it isn't declaring itself in linking mode. I assume you are holding the set button in long enough until the switch beeps indicating it entered linking mode.