tmorse305

@larryllix, I created another test routine that triggers on 'not detected' just to make sure there was no difference in the way that Alexa responds. It seems to operate the same way as using detected. In the process I did discover one surprise. I can fire the 2 programs back to back and I get both voice prompts, one right after the other, no 30 second delay. It seems that Alexa is treating them as independent events with their own 30 second exclusion periods.

I've noticed that events shorter than 3 seconds on the ISY side don't show up in the Alexa app when I watch the device but do trigger the routines.

@larryllix, I played around some more with the delays to see if I could get a better understanding of what is happening. With this setup: $sMS_Test_1 = 1 Wait 5 seconds $sMS_Test_1 = 0 Wait 30 seconds $sMS_Test_1 = 1 Wait 2 minutes $sMS_Test_1 = 0 The second voice prompt occurs 60 seconds after the first one. With this setup: $sMS_Test_1 = 1 Wait 5 seconds $sMS_Test_1 = 0 Wait 25 seconds $sMS_Test_1 = 1 Wait 2 minutes $sMS_Test_1 = 0 The second voice prompt never happens. Here's my theory on what going on. It seems any change to the variable state triggers the 30 second exclusion period on Alexa. If another change comes along before the 30 second has expired, it's put in a queue and is acted on when the 30 second period has ended. Then another 30 second period begins. But the queue is only one deep, if another change comes along before the queue is cleared, it either ignores it or overwrites the queue with the updated value. Either way Alexa misses the next transition so there is no second voice prompt.

I hope you hear back from them, I have made a few requests in the past and been promised follow up but alas still waiting... On the 2nd 30 sec wait, actually it is necessary. If I delete it, I never get the second voice response. If I shorten it to a couple of seconds the 2nd voice response comes about 30 second later. With it set to 2 seconds the voice response was nearly coincident with the variable resetting to 0. I thought I had duplicated your issue until I realized what was actually happening.

@larryllix, that is bizarre. I created a test program on ISY today to play with this: If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then $sMS_Test_1 = 1 Wait 30 seconds $sMS_Test_1 = 0 Wait 30 seconds $sMS_Test_1 = 1 Wait 30 seconds $sMS_Test_1 = 0 I get two reports from Alexa repeatedly, when the variable is set to 1. I played around with the wait times to see if I could get it to ever trip on the variable setting to 0 but no luck. If I reduce the middle wait to 1 second then I can create the appearance of the trigger on the set to 0 but it's obviously just delayed from the previous set to 1. Hopefully Benoit can shed some light on this for you.

You're right, on the first trigger you don't need to hold the variable for 30 seconds as Alexa responds quickly. If you were holding the variable for 15-20 seconds it should have worked the first time. So the question is before your ISY reset did the trigger work the first time?? If it didn't that could be an important clue in trying to figure this problem out. Maybe your ISY reset did have an affect. It seems crazy that it would or could but with the crazy behavior @larryllix just reported there is something strange happening. What version of ISY are you running? I haven't upgraded from 5.2.0 yet and I'm not seeing any of these problems being reported.

I just tried my routines and they seem to be working as they always have. Just to be clear you are talking about Alexa routines triggering on the not detected value of the variable instead of the detected value?

So just to be clear, resetting your ISY solved the problem with Alexa routines not firing?

I killed the Alexa app, triggered the motion variable at 8:20. Waited until 8:25 and then opened the app. Inactive since 8:25... Looks like there is a bug in that calculation.

This must be a problem on the Alexa end of things. @BOden talked about a failed attempt to rectify it with Alexa support so that doesn't sound encouraging. It's strange it works for some but not for others. Are your screens the same as mine, at least structurally? No obvious differences? I meant to include one more previously.

From what you have described it seems like it's a problem on the Alexa side. I use multiple routines like this and they are working. Here are screen shots of one of mine. I suspect they are the same as what you're seeing but worth a shot since nothing seems to be helping. Does the device have a unique name? Any other devices close in their name? I've had problems with that in the past with Alexa getting confused with similar (but different) names. There was other gotcha that I ran into. I had a variable defined as 0=no motion and 2=motion. In the course of the ISY programs running the variable was briefly set to 1. When that happened the portal communicated "no motion" to Alexa and started the 30 second debounce so my routine never worked. Just make sure the variable changes one time and held for 30 seconds (which it sound like you are already aware of)

2.x are state variables. The 2nd number(x) is the variable number, that can be seen on the variable tab, the ID column. I'm assuming 1.x are Integer variables, but I don't use any so I couldn't double check.

I suspect that is what happened. I have had several of these events over the years and in the past pretty much every device turned on. However I had one happen just a few weeks ago and the devices affected were just a small subset. There was a thread quite a while back that implicated MS as a possible cause for these events and recommended adding a 2 sec delay to any action triggered by an MS. Do you have that implemented? The event is outside the control of ISY so the log will not show any abnormal behavior. It's a bit unnerving to watch all your garage doors open, that happened to me too. Only once, because I pulled the I/O links and found an alternate solution using programmable outputs on my alarm panel.

Hi @markv58, I am trying to use the new generic/dimmer Bright/Dim capability that you just added. I created a generic virtual node to replace the virtual switch I had been using. I am using these in conjunction with the HousePanel app. Both the switch and the dimmer come through as a switch on the Housepanel side. I ran a rest/nodes to look at the differences, see below. My knowledge is limited in this area but reading in the ISY REST development manual it looks like a dimmer should have a PID of 1, the 2nd number in the <type> below. The PID seems to be the same on both. Is this the right interpretation? Thank you.

@dpierre, here is one way to do it. I'm using a series of 4 programs and a scene to do this. There might be a simpler way but I evolved a solution for you from something I already had. In my case, I use Alexa to open and close the door and so had the logic created to prevent Alexa from actuating the door when it was already in the desired state. 'Alexa open the door' does nothing if the door is already open. I just added the KPL programs to what I already had to get the button operating correctly. First you need a scene with the KPL button included I have a variable defined, $sLeft_Control that is defines the door state desired, 0=Idle, 1=close, 2=open (this is how Alexa controls the door by setting this variable) The first 2 programs open and close the door based on the variable setting Left_Open - [ID 0074][Parent 0071] If 'Security Panel / Garage_Door_L' Status is Closed And $sLeft_Control is 2 Then Resource 'Garagedoor_2' Run Program 'Left_Open' (Else Path) Else Wait 2 seconds $sLeft_Control = 0 ---------------------------------- Left_Close - [ID 007C][Parent 0071] If 'Security Panel / Garage_Door_L' Status is Open And $sLeft_Control is 1 Then Resource 'Garagedoor_2' Run Program 'Left_Close' (Else Path) Else Wait 2 seconds $sLeft_Control = 0 ----------------------------------- The next program sets the variable based on the state of the KPL button A_KPL_Operate - [ID 0094][Parent 0071] If 'Garage KPL' Status is On Then $sLeft_Control = 2 Else $sLeft_Control = 1 ----------------------------------- The last program updates the state of the KPL button in case the garage door is opened/closed using some other method (button in the garage etc) Update_Left - [ID 0095][Parent 0071] If 'Security Panel / Garage_Door_L' Status is Open Then Set 'Left_Garage' On Else Set 'Left_Garage' Off

Thanks @markv58, that resolve my switch 47 issue. For my purposes, I don't need the variable association so I'm good with your approach.

Hi @markv58, I have one switch associated with ISY variable ID 47 that does not show up in the AC. I've tried a reboot of the NS and restarts on the AC but no luck. So I thought I would try to delete it then add it back. When I press the delete key next to the switch 47 entry, it deletes but than about 3 seconds later it reappears. Any suggestions? Thanks for your help.

Hi @markv58, I was trying out the virtual switch tonight for the first time (BTW the temp is working great!). I added it to a scene. I could only add it as a responder not sure why. It tracks the scene status unless I brighten from off using one of the physical switches. See attached, I brighten from off using one of the switches but you can see it is still off. Thanks for your insight.

We all owe you a beer or 2!

I am still running v1.0.15, I have 12 nodes ( all value=temperature). It has been up and running for 12 hours. Maybe the crash is related to temperaturec? I'm not using that.

v1.0.14 solved the issue. Its been running correctly for a few hours. Thank you.

Hi, Today when I checked my temps I noticed that the Since Last Update was stuck at 2 minutes. I checked the log and it looks like an error occurred, see below. A restart of the node server and Polyglot did not help. Thanks for your help. 2020-07-22 13:25:55,704 Controller polyinterface ERROR polyinterface:write: Exception in thread Controller: 2020-07-22 13:25:55,704 Controller polyinterface ERROR polyinterface:write: Exception in thread Controller: Traceback (most recent call last): Traceback (most recent call last): File "/usr/lib/python3.7/threading.py", line 917, in _bootstrap_inner File "/usr/lib/python3.7/threading.py", line 917, in _bootstrap_inner self.run() self.run() File "/usr/lib/python3.7/threading.py", line 865, in run File "/usr/lib/python3.7/threading.py", line 865, in run self._target(*self._args, **self._kwargs) self._target(*self._args, **self._kwargs) File "/home/pi/.local/lib/python3.7/site-packages/polyinterface/polyinterface.py", line 846, in _parseInput File "/home/pi/.local/lib/python3.7/site-packages/polyinterface/polyinterface.py", line 846, in _parseInput self.longPoll() self.longPoll() File "./Virtual.py", line 56, in longPoll File "./Virtual.py", line 56, in longPoll self.nodes[node].getDataFromID() self.nodes[node].getDataFromID() File "./Virtual.py", line 387, in getDataFromID File "./Virtual.py", line 387, in getDataFromID self.pullFromID(_type, self.action1id) self.pullFromID(_type, self.action1id) File "./Virtual.py", line 401, in pullFromID File "./Virtual.py", line 401, in pullFromID LOGGER.info('Init = %s Prec = %s Value = %s',_value[1], _value[2], _value[3]) LOGGER.info('Init = %s Prec = %s Value = %s',_value[1], _value[2], _value[3]) IndexError: list index out of range IndexError: list index out of range

Things are looking good on my end, thank you!

@markv58, I installed v1.0.12 but the settings for Action 1, Action 1 Var Type, and Action 1 Var ID do not survive an AC restart. However it appears to be working, in my case variable 46 is updating the node display at the long poll interval.

Thanks @Teken, I had no clue that was a button thought it was just a label! I pressed them and ISY went busy for a moment so it seemed to save. However when I restarted the AC they were gone. Curiously it did load the correct value from variable 46 in the current field. @markv58, I did restart the Node server, no obvious errors in the log that I can see. Will send it to you.