tmorse305

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.

Thanks @markv58, my node display is now correct. Sorry, I missed your comment about temperaturec only in v1.0.10. The potential bug you just described may be happening to me. I think I have it configured correctly but the Time Since Last update just continues to increase with no updates. Just so I'm clear about the changes you have made, the number used to configure the node in the Polyglot configuration (46 in my case) no longer associates it with variable 46? To do that I have to make the connection as I did below. Safe Travels. @Teken, what did you mean by this: "The key thing is to press on the side button so that selection is saved"

I upgraded to v1.0.9 but encountered the same problem I had with an earlier rev. The display on the ISY side still looks like the earlier revision. Here's what I tried: Update to v1.0.9 Restarted nodeserver confirmed it is running v1.0.9 Brought up the AC, did a Profile Update, closed AC Restarted the AC, still shows the earlier version of the temp node, closed AC Restarted Polyglot(RPI) Brought up the AC, did a Profile Update, closed AC Restarted the AC, still shows the earlier version of the temp node Rebooted ISY Brought up the AC, did a Profile Update, closed AC Restarted the AC, still shows the earlier version of the temp node What else can I try? Thanks for your help. (same result with v1.0.10)

You're welcome and thanks to @bmercier for continuing to enhance the Alexa interface.

Here's what the programming would look like if you use a variable with "Device with Open/Close syntax. In my case I choose Open=2 and Close=1 for the variable($sLeft_Control) assignment. This eliminates the need for the helper program and also eliminates the Routines on the Alexa side. I use a resource for the door control not an I/OLink but the idea is the same.

From https://wiki.universal-devices.com/index.php?title=ISY_Portal_Amazon_Echo_Integration_V3#Programs Programs Turn On: “Alexa, turn on the kitchen light” - runs Then Turn Off: “Alexa, turn off the kitchen light” - runs Else You can't run the IF directly from Alexa. Instead of having your Alexa routine run programs you could have it set a variable instead. Then on the ISY side your IF could include the variable as a condition. Or you can eliminate the Alexa routine all together and expose the variable as "Device with Open/Close syntax in the Portal. Then when you say "Alexa, open the <variable name> the variable will be set to the on value and vice versa.