apostolakisl

So the problem is with ISY, not Alexa. If the light doesn't turn on when you turn the scene on from the ISY admin console it isn't going to turn on when Alexa triggers it either. I have also had this (edit, by this I mean it keeps doing the pop up) happen after adding a device and ended up having to power cycle ISY. A bug in one of the more recent firmwares I guess. I have now seen at least a couple other people report this. I would start with rebooting your ISY (eisy/polisy/whatever model). Then see if the scene works. My bet, however, is it will not. Perhaps the "replace with" command did not function correctly. You can always try a "restore device", but I usually just completely delete the device, add it back, and configure it back into all the scenes.

If Alexa is controlling the scene, then Alexa won't know if you swapped out a device in the scene. Alexa doesn't see the individual devices in a scene. Alexa triggers ISY to issue a "scene on" and from there it is all Insteon configuration as to what responds to the scene. What happens if you trigger the scene from the ISY admin console? If that works, then I can't understand how Alexa isn't unless Alexa isn't triggering a scene but rather a device. When you open the ISY portal and go to Amazon echo: Is the "ISY category" for whatever it is listed as a "scene" or "device"?

I'm going to assume that you have a scene and that in the portal you set the scene to be controlled by Alexa (not individual devices). Since Alexa still is controlling the scene, it sounds to me like the new switch isn't in the scene. If you did a "replace with", then it should be in the same scenes as before. If you deleted the old device and added the new switch, then perhaps you never put it into the scene.

I was going to say the same thing about the caps. For fun I replaced capacitors on some old 2476D's I had and sure enough, they came back to life. For the most part though, it doesn't make a lot of sense repairing them. Just in case it is a link table issue, it would be easy enough to factory reset it, delete the device from ISY, then add the device back to ISY and re-create all the scenes and stuff. Before you delete it from ISY, take some screen shots of the scenes and stuff so you can quickly put it back as it was. I have had mis-behaving switches in the past where this fixed them. EDIT: Just to be clear, ISY can have bad/wrong links tables and simply factoring resetting the device and restoring it will just put the same bad links on it. If you delete it and start from scratch, this won't be a problem. I have had this happen a handful of times over the years.

If for whatever reason your ISY is stuck in this state, you will just have to power cycle it, even though it says don't do that. There are legit reasons for this message, but they shouldn't persist. So if hours go by and this still happens, you will need a power cycle.

Don't use status of the kpl button in your second program. Use "control", so it will say if KPL... is switched off. In that case, the only action that runs the program is someone physically pushing the button on the kpl to shut it off. Furthermore, if the only thing you use that kpl for is to shut things off, I would change the KPL toggle mode to non-toggle off. In this case, pressing the button will always send an "off" command. The KPL button backlight can still be turned on by a program or by responding to a scene, but pressing it will only ever send an off command. Finally, you would probably be better off creating a scene rather than listing out all the devices one by one in a program. You can put the KPL button in the scene as a controller and all the other devices as responders. Then you can do away with the second program altogether.

I would start by opening your program summary page on a laptop and then, while watching the page, click on the light switches and see if any programs run. That would cover what @oberkc was proposing. If it proves that no programs are running, then I would move on to what @Guy Lavoie suggested. If that doesn't work, I would delete them from ISY completely, factory reset them, then add them back in to ISY. Be sure to note all of the scenes and programs they may have been part of prior to deleting them so that you can quickly create them again.

@mitch236 Yes. What you have there should work. Every press of the button will send a "control off" which is the one and only thing that can trigger the program (as opposed to a "status" program that triggers on every change in status) and it will only ever run "true" with that as the only item in the "if" clause. I don't recall ever using "non toggle off" before, but I would assume that this would turn the backlight off with every press. And if there is no other program or scene that turns it on, it should never be on. Maybe after a power cycle perhaps? I don't think so thought, usually they come back up as they were when power went out. Mind you, the backlight has both an "on" brightness and an "off" brightness. So you may need to adjust that to make it totally black, if that is what you want. Most people do a dim backlight for off and a bright backlight for on.

There are different ways to handle this depending on how you want things to work and what sort of hardware you have. First off, posting programs on the forum is best done by right clicking the program and selecting "copy to clipboard", then pasting it here as text. To your issue. It appears your gate is triggered by powering on a relay for a few seconds. I assume the gate opens, has some sort of built-in delay and then closes on its own. First off, do not use "status" of the KPL, use "control" command which gives you "is control switched on". Configure the KPL as a non-toggle on. You do this from the main screen of the admin console. Also, you don't need the "stop program" line. It isn't doing anything. Now, every time you click the KPL button, it will send a "control on" Insteon command. This will trigger the program and turn the relay on for 3 seconds (or whatever you put in the program). The backlight on the button will end up being on all the time, which may be fine for you or maybe not. If you want the backlight to change depending on something, you would have to be more specific on what you are looking for. I suppose if you wanted the backlight to default to off, you could set it to non-toggle off and change your program from "switched on" to "switched off". To control the KPL light independently, you would need to put the KPL button into a scene. Then you can turn the scene on/off from another program or as a responder to another device in the scene. Turning the kpl button on/off in this fashion will NOT trigger the program. The only thing that will trigger the program is actually physically pushing the KPL button. This is how the logic of "control" works and how it differs from "status".

Initially I thought this was an elk node issue because that is where it was immediately obvious in my daily usage. But it is lots of nodes. Stuff randomly won't populate when accessing through the portal. Accessing locally via port 8080 works correctly. ISY is functionally populating based on the fact that programs run correctly, it is just that the portal isn't feeding the data to UD Mobile or to the admin console when using the portal as the means of accessing ISY

@Javi Where do we stand on this? I can't log in using anything but port 8080 unless I am OK having about 20% of my stuff not populate.

I don't know if there is any commonality here, but I too have recently started having lights randomly turn on. Started maybe a month ago. Checking programs, there are no programs showing as having run at those times. The involved lights are Insteon. I haven't changed my Insteon network in quite some time and the devices involved have had no changes in many years. It has happened maybe 4 times in the past month or so.

The url is manually entered into iox launcher, not a wb browser. Open the launcher and click add, then enter the url.

You can add an isy to iox using http://your isyip:8080. This of course only works on the same lan as isy.

@bpwwer I am still having issues with every time blue iris server restarts or otherwise goes down and then comes back online, the node server looses its connection and I have to manually restart it. I am not clear on if this has a programmatic solution or how to manage it.

Yes, transatlantic fiber is how Germany is connected to the US. I agree, the bulk of the latency is almost certainly rooted in server response not distance. An interesting related fact is that the speed of light in fiber is slower than through a vacuum (or air). This can add a few milliseconds of latency for long haul transmissions when comparing terrestrial fiber to laser or rf. SpaceX is marketing using their satellites to laser relay satellite to satellite across the globe for extremely time sensitive transmissions. Most notably traders doing arbitrage between. say, New York and Hong Kong. Apparently they are willing to pay $millions per month for the service. Even though it has to go through maybe 10 or 15 hops and doesn't take a straight line, it still beats the terrestrial fiber.

Funny that I push an Insteon button on a wall 10 feet from a ceiling fan and the fan turns on, but the signal first goes to Germany, then to an Amazon server (wherever that is), then to the fan company server (wherever that is), and then back to my house. And it works every time. How many thousands of miles do you suppose? Edit. And if I used UD mobile logged in via portal, you would add a new first step where it goes to UD server and then back to my house ISY.

Using a mini-remote in 8 button non-toggle mode is pretty easy since you just need create 4 scenes (assuming off, low, med, high) then add the button you want to control each speed to each of those scenes as a controller (and of course put the fan in as a responder at that speed). The simplicity of the mini remote is that it doesn't back light the buttons so you don't need to set anything as a responder. The issue here is that you will have 4 other buttons that are also all non-toggle buttons and you might not find it easy to use those to control other things. Pressing the button will simply send an "on" command with each press. So if you want to control a light, you would need to make 2 scenes to be able to turn it on and off. One scene with button A for example to turn it on (set the light as a responder with on-level as "on") and a second scene to turn it off with button B as the controller (set the light as a responder but set the on level to "off").

I have had perfect success using a webhook setup and an Alexa plugin. I don't recall that it has ever failed. There is a skill for Alexa and then you create webhooks on here: https://trigger.esp8266-server.de/ You use a network resource to send the webhook. EDIT: I just went to that website and, if I don't log in, the creator says it is broken, but it isn't, at least for me. I use it everyday and I even added more webhooks to it just a month or two ago. Not sure if it is possible to currently add it to your Alexa or not, but for me with it already there it works great and I am able to keep adding more. I have about 20 as is. EDIT 2: It looks like Alexa still has the skill for you to add. You do have to use the primary amazon account and once you add your webhooks, you tell Alexa to discover devices and then the webhook shows up as a device that you can use to trigger whatever you want on an Alexa routine. At that point, you basically just send the url to the internet from a network resource or just put it into a web browser and usually in less than 1 second it is doing its thing.

To further this, it is not just Elk. It is seemingly random nodes across the entire system. Insteon nodes, PG3x nodes, Nodes from IoGuy Nodelink. I see no pattern to it. @Javi Example: Admin console on local connection: Admin console as viewed via portal login at the exact same time from different PC:

Exactly. @Javi This has been going on for at least a couple weeks. It is consistently the same nodes that don't work while other nodes that seemingly should be identical work fine. The first place I noticed it is a perfect example. I have shortcuts setup for my garage door and my wife's garage door. Both are Elk zones (zone 22 and 34). On different expansion boards, but I don't think that is a reason. When the doors are closed or open I have to change the color of the icon from red to green. So I quickly noticed that the icon was neither, but rather the default blue. Every now and then, it would populate, say "closed or open" and set the color, but typically, just blue. My wife's door, always populates. It will populate on occasion. It seems like the way to have that happen is to have the admin console open or have UD mobile open, and then change the status of the node. It will populate, but it doesn't stay populated for long. Certainly won't stay populated if you close your session and open again. Here it is: And then there is also the 0 and 1 for Elk status instead of armed/disarmed/etc which, as far as I an tell, is a different issue with the newer firmwares.

I can confirm same on ud mobile. I switched to local settings and now it populates everything.

So I have isolated the problem to logging in via the portal user/password. Anything that uses the portal (UD Mobile and admin console not using port 8080). For example. This screenshot is from logging in using port 8080 admin/password @bmercier And simultaneously on another computer using the portal login.

Recently, perhaps with a recent update, elk module no longer reports any of my keypads, except maybe a parameter shows up and then goes away, and a handful of zones show no status. I see no pattern to the zones not showing. If I open elk rp2 all status is there. If I query, it might temporarily report voltage. I restarted the node which didn't help. I really don't want to delete and re add the node because of all the reorganizing I did with folders and names for the various things that would all need to be redone.

If the power flickering/going out/coming on, may have resulted in the switches shutting down and then booting up without the proper power environment leading to incorrectly set RAM(I assume Insteon switches have RAM). As we all know, power supplies have capacitors that keep our electronics running for a few seconds even when power is removed. But as the capacitors charge decays, the voltage and current supplied is sub-optimal. So power coming on for a second after shutting down and then going out for a second would allow the boot to continue but with incorrect power during that sensitive time of booting. That would be my guess as to why the flickering power resulted in misbehaving switches and a proper boot fixed it.