tmorse305

What light comes on when you press the set button, the LEDs or the light the switch is controlling? In any event it sounds like there is power at the switch. Try a factory reset. Wall Switches & Keypads Disconnect your Wall Switch or Keypad from power by pulling the set button out Press and hold the set button Continue holding the set button until the beep stops If your device does not beep, hold the set button for ten seconds Release the set button. You should hear two beeps confirming that your Wall Switch or Keypad has been reset

The LEDs you are referring to are on the dimmers correct? Are the 2 dimmers in a 3way circuit? In other words the 2 dimmers are supposed to control the same light? If that's true then the dimmer that is dead maybe controlling the load and while the other is working but unable to operate the light. Are these Insteon dimmers? If so make sure the small button is pushed in and not sticking out. Maybe the circuit breaker is tripped?

PLM's have a poor power supply design that all but guarantees premature failure. Right now there is no other option but the PLM. I would hang on to the failed unit. You cannot buy a replacement right now, out of stock. They have been for sometime. The broken unit can be repaired.

@markv58, You're probably right... thanks, totally missed that in the change over.

@markv58, I was just checking the others and I would say 'sort of'. There are data changes on some but if I query I get a failure. The IP of the Polyglot did change, My whole network went from 192.168.1.x to 192.168.4.x

Thanks @markv58Sorry that wasn't clearer, I have already updated it in two places, within the Polyglot setting and within the virtual NS. The log looks ok, no obvious errors

@markv58, I having trouble getting the nodeserver to communicate with my ISY. Earlier today I had to change the IP address of my ISY. That of course ripples trouble in all directions... I have updated the IP address in the Polyglot settings and the parameter within the node server. I have have restarted the nodeserver and the Polyglot and the ISY but still no luck. From the ISY side the nodeserver reports to be online but when I try to operate and virtual switch ISY comes back with an error, "request failed" I get the same response if I try the button on the controller node, "query", "update profile", etc Any suggestions, Thank you

I think you will need to extend your wait time from 25 second to 55 before you can attempt to trigger again. The 2 variable changes both create 30 second exclusions based on what I saw with the experimental routine I shared with you in the other thread. If you trigger again after the 25 seconds delay the vocal might not happen. This is what I found $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.

This now explains why my routines work but not yours. I only use 1 and 0. I got burned a long time ago when I had the variable being assigned other values. Sorry I didn't realize sooner that you were doing that.

@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.