My simple Variable Off

Reading Lamps Variable Off - [ID 0092][Parent 0094]

If

'Sitting Room / Sitting Room Lamps' Status is Off

Then

$sReading_Lamps = 0

Else

- No Actions - (To add one, press 'Action')

1 minute ago, bgrubb1 said:

I tried to make this work months ago and never got the alexa spoken to work

There is a PG3X node server called "Virtual Button" that accomplished it for me

And this is triggered with a ISY Switch?

@PB11 You are talking about a different thing here. This is ISY telling Alexa to do something, not Alexa telling ISY to do something.

And yes, I have tried deleting variables, and I have added additional variables and exposed them to Alexa. But Alexa, as can be seen from the screenshot, says the device is not responding or sometimes it says the server isn't responding (whose server I don't know). Of course ISY is working with Alexa in the other direction, I can tell Alexa to do something with ISY and indeed ISY does whatever.

And I am not using switches or a program at all to change the variable state. I am manually changing the variable, so I know it is changing.

Edited December 29, 2025Dec 29 by apostolakisl

The best I can recommend is to be sure Alexa is not showing more than 1 item with your variable. Then as said give it a day or 2 and if it still not working try to get help from UDI to see if everything looks good in the portal, then you will have to move on to Amazon to try and get it working.

Larry

Many optical fiber cables connecting under the ocean. These days the big players ( Amazon, Google, Microsoft, apple ) have their own ocean cables to connect their data centers around the world.

The signal still needs to be amplified as it crosses long distances. This is done by short sections of special fiber spliced into the normal fiber which can reamplify the signal ( power is still needed to excite these fibers, they act like a laser) and then another special fiber section that reshapes the light pulse. The signal does not see any electronics as it crosses the long distances, just a continuous fiber path.

The latest fibers thar are being worked on are what is called hollow core fiber. It has air gapes in the center of the fiber to decrease the latency of the signal transmission to that of a direct laser link ( satellite to satellite). Fiber and cables are just being deployed by Microsoft.

18 hours ago, PB11 said:

Ppl have told me how share your programs to this forum other than cut and paste but i can't recall.

Can anyone enlighten me?

@PB11 in the AC, right click on the program you want to copy and go tot he bottom, copy to clipboard. Then paste into the body of your post

@apostolakisl

Ok, not sure if this is what you are describing, this was the issue I started this topic about, but the second portion of my setup is the Alexa routines which are triggered by a spoken name which i have assigned to the state variable.

I simply ask Alexa to turn on "Reading Lamps" (state variable name) which sets the variable to 1, and "reading lamps" off sets the variable off.

17 hours ago, apostolakisl said:

@PB11 You are talking about a different thing here. This is ISY telling Alexa to do something, not Alexa telling ISY to do something.

@apostolakisl This portion occurs with the spoken word associated in the isy portal alexa device list. I think i misunderstood this was the portion not working for you as when i started this topic i was simply trying to get alexa variables visible to Alexa ecosystem

For my setup, my spoken word changes the status of the isy state variable, which then triggers alexa scenes via my Alexa routines , but i think could also trigger isy scenes.

To get my head around this I had to watch the status of my variables as I voiced commands to Alexa. ie, Alexa, reading lamps on = variable closed

But this may be all for not, as it sounds like you may be having issues with the portal setup as others have pointed to.

Wish i could be of more help.

1 hour ago, PB11 said:

@apostolakisl

Ok, not sure if this is what you are describing, this was the issue I started this topic about, but the second portion of my setup is the Alexa routines which are triggered by a spoken name which i have assigned to the state variable.

I simply ask Alexa to turn on "Reading Lamps" (state variable name) which sets the variable to 1, and "reading lamps" off sets the variable off.

@apostolakisl This portion occurs with the spoken word associated in the isy portal alexa device list. I think i misunderstood this was the portion not working for you as when i started this topic i was simply trying to get alexa variables visible to Alexa ecosystem

For my setup, my spoken word changes the status of the isy state variable, which then triggers alexa scenes via my Alexa routines , but i think could also trigger isy scenes.

To get my head around this I had to watch the status of my variables as I voiced commands to Alexa. ie, Alexa, reading lamps on = variable closed

But this may be all for not, as it sounds like you may be having issues with the portal setup as others have pointed to.

Wish i could be of more help.

I think you are doing both ways (Alexa voice to isy, isy back to Alexa via a variable triggering a routine. I am pretty sure a voice command can directly trigger a scene though, so not sure you would need to have Alexa use a routine on that at all. I have a number of voice commands that directly trigger Insteon devices without need for a routine.

I opened a ticket with UD since my variable changes are not being seen by Alexa and thus my routines are not running.

I finally got this working. Benoit at UD gave me all kinds of suggestions, none of which worked. He said all looked fine on his end. I called Amazon customer support and actually got a person. After 90 minutes on the phone they got it to work.

However, I have noticed it is not fast to respond. I have it on contact closure and sometimes it takes 20 seconds or more to respond. Fastest I have seen is maybe 3 or 4 seconds.

I did experiment with triggering Alexa routines with a variable change in isy. It worked but indeed, there was a variable delay that would occur, sometimes 10 seconds or more.

I do it to announce a leak from leak sensor. Need to change to use leak sensor state. It’s just feels odd that only way to add these devices to Alexa includes a spoken. Did I miss something?

Edited yesterday at 01:21 AM1 day by hart2hart

1 hour ago, hart2hart said:

I do it to announce a leak from leak sensor. Need to change to use leak sensor state. It’s just feels odd that only way to add these devices to Alexa includes a spoken. Did I miss something?

As far as I can tell, the only way to use the portal for ISY to signal Alexa is to use either the motion sensor or contact closure variable setup. The "spoken" in these cases I think is irrelevant since Alexa only responds to the state of these variables, it doesn't control them in any way.

Anyway, after all my screwing around to get the variables working with Alexa, I am going to stick with using the webhooks. The webhooks always work in a second or two. I am using them for a few things including opening and closing my Levelor blinds. If you push the button to close/open the blinds and then 20 seconds later they finally do it, well that stinks. My wife would certainly complain and this would just be something to try to explain to guests, well if you want the blinds closed push the button and then sometime in the next 30 seconds they will do it.

Edited yesterday at 02:38 AM1 day by apostolakisl

So I did some playing around. I used a variable exposed to Alexa as a contact closure and an Insteon light also exposed to Alexa. I set up two routines where toggling the variable between 1 and 0 turns the light on/off.

Changing the variable gives you a very quick response, perhaps a second. HOWEVER, the contact closure appears to get locked out for 30 seconds or so. So toggling back and forth in less than 30 seconds will present delays.

Should you change the variable before 30 seconds expires the routine won't trigger until the 30 second lockout window has passed. If you change it during the lockout, and then change it back before the 30 second expires, nothing will happen at all.

I can see where this time-delay would be desirable, but it makes no sense to me to make it the default. Alexa lets me use the webhooks repeatedly pretty much as fast as I can send them to it.

Edited 23 hours ago23 hr by apostolakisl

So qc

3 minutes ago, apostolakisl said:

So I did some playing around. I used a variable exposed to Alexa as a contact closure and an Insteon light also exposed to Alexa. I set up two routines where toggling the variable between 1 and 0 turns the light on/off.

Changing the variable gives you a very quick response, perhaps a second. HOWEVER, the contact closure appears to get locked out for 30 seconds or so. So toggling back and forth in less than 30 seconds will present delays.

Should you change the variable before 30 seconds expires the routine won't trigger until the 30 second lockout window has passed. If you change it during the lockout, and then change it back before the 30 second expires, nothing will happen at all.

I can see where this time-delay would be desirable, but it makes no sense to me to make it the default. Alexa lets me use the webhooks repeatedly pretty much as fast as I can send them to it.

Thanks. So that I’m clear the variable signaling method was much faster?

6 minutes ago, hart2hart said:

So qc

Thanks. So that I’m clear the variable signaling method was much faster?

Not sure what you mean. Faster than using webhook?

Both network resource/webhook and setting a variable/contact closure work about the same on the initial trigger. Roughly 1 second. The webhook is dependent on the hosting server response time plus internet latency (to Germany). Similarly, using the variable method is going to have some latency based on ISY portal latency as well as internet latency to wherever ISY portal is hosted. Both would presumably be equally exposed to the same Alexa server latency.

But when you use the variable/contact closure method, you are dead in the water for the next 30 seconds.

The webhook method is ready to go right away for the next trigger.

Also, unlike a toggled variable, with webhooks, you can keep triggering the same routine repeatedly without a toggle event. For example, say you had a routine that triggered a bell to ring. You could keep sending the webhook that triggers the ring over and over. Compared to a contact closure, you need to go 1, then reset to 0, then 1 again, then reset to 0, etc. And because of the 30 second delay, you would be limited to ringing the bell once per minute. variable 1=ring, wait 30 seconds, reset variable to 0, wait 30 seconds, variable 1=ring again.

Obviously there is a limit to how fast you can get a webhook and an Alexa routine to respond, but you could probably repeat once a second. You also have to consider the response time of the routine target. If it is an Insteon light for example it has to get from Alexa server, through the ISY portal, to your ISY, through the ISY and then through the Insteon com.

Edited 22 hours ago22 hr by apostolakisl

9 minutes ago, apostolakisl said:

Not sure what you mean. Faster than using webhook?

Both network resource/webhook and setting a variable/contact closure work about the same on the initial trigger. Roughly 1 second. The webhook is dependent on the hosting server response time plus internet latency (to Germany). Similarly, using the variable method is going to have some latency based on ISY portal latency as well as internet latency to wherever ISY portal is hosted. Both would presumably be equally exposed to the same Alexa server latency.

But when you use the variable/contact closure method, you are dead in the water for the next 30 seconds.

The webhook method is ready to go right away for the next trigger.

Also, unlike a toggled variable, with webhooks, you can keep triggering the same routine repeatedly without a toggle event. For example, say you had a routine that triggered a bell to ring. You could keep sending the webhook that triggers the ring over and over. Compared to a contact closure, you need to go 1, then reset to 0, then 1 again, then reset to 0, etc. And because of the 30 second delay, you would be limited to ringing the bell once per minute. variable 1=ring, wait 30 seconds, reset variable to 0, wait 30 seconds, variable 1=ring again.

Obviously there is a limit to how fast you can get a webhook and an Alexa routine to respond, but you could probably repeat once a second. You also have to consider the response time of the routine target. If it is an Insteon light for example it has to get from Alexa server, through the ISY portal, to your ISY, through the ISY and then through the Insteon com.

Again thanks. I thought you might be saying an eISY variable exposed to Alexa as a contact closure was at one second compared to an actual Insteon device exposed to Alexa. I believe you meant a variable triggering a webhook was one second. Do I have it now?

21 minutes ago, hart2hart said:

Again thanks. I thought you might be saying an eISY variable exposed to Alexa as a contact closure was at one second compared to an actual Insteon device exposed to Alexa. I believe you meant a variable triggering a webhook was one second. Do I have it now?

Webhook URL is setup in a network resource which can only be activated by a program. Variables need not be involved.

Variable/contact closure => Trigger a routine (about 1 second)

Webhook/network resource => Trigger a routine (about 1 second)

Insteon Light exposed to ISY can not trigger a routine and isn't part of my discussions here.

30 minutes ago, apostolakisl said:

Webhook URL is setup in a network resource which can only be activated by a program. Variables need not be involved.

Variable/contact closure => Trigger a routine (about 1 second)

Webhook/network resource => Trigger a routine (about 1 second)

Insteon Light exposed to ISY can not trigger a routine and isn't part of my discussions here.

Thanks.

Benoit tells me that the contact closure (and I assume motion sensor) methods of triggering a routine in Alexa have a UD built-in "debounce" that blocks changes in the variable from being propagated to Alexa. He didn't say it was 30 seconds, but if it isn't 30 exactly, it is real close to that. UD is concerned about API request limits set by Alexa.

I don't know if the API issue is per Alexa account or if it is for all API requests from all UD portal users. If it is the former, I would prefer that UD just gives you a warning not to overdue it and if you do, it is on you.