larryllix

I am in Ontario also and alexa reports "Sorry, something went wrong" with every command right now. My guess is they are actually responding to my suggestions how to fix the ISY Portal responses that trigger Routines and have made a bigger mess of it. UPDATE: My mistake. I swapped two CAO Wireless Tags names today and Alexa didn't like it. I disabled the Tag skill and then re-enabled again and alexa stopped complaining. All is well again.

Mine suddenly started reporting "a problem" but seems to operate fine still. It doesn't matter what your scene/program/or variable is called. It is what the spoken word is. If you have more that one spoken with the word "kitchen" in it, it will get confused occasionally. At least Alexa will ask. Google will just operate things on a guess when it doesn't hear clearly.

IIRC: Chamberlain has a MyQ box upgrade device you can just add on to the old units. I have two different vintage Chamberlain GDOs and they both destroyed my Insteon comms until I installed FilterLincs. The newer one (MyQ and battery motor) was the worst but tipped me off to what my signal problem was and caused me to track it down.

Yes. You should allow your DHCP server in your router assign IP addresses. This will avoid the "I can't access my ISY" a year from now when you may get an address clash locking you out of both devices.

I had a router that wouldn't allow any access to a device outside of it's assign IP address block. IOW: You could not access any device with 10.0.0.xx address in a router set to 192.168.0.1 - 192.168.0.255. I think it would assume it was on the WAN and routers don't allow LAN addresses through the router firewall onto the WAN.

I haven't been able to follow what you are trying to do but.... the init_to version of the variable is write only to the user...so far. IIRC that has been requested previously but more requests and case uses examples always helps. Search in the future features thread. Use Michel's tag to alert him BTW: I use a prefix like this $cTRUE , $cFALSE for fixed Integer variables that never change.

OK putting the two logics together I may have identified my problem. 1. $SayVar = 2 This is a request for a sequenced state variable trigger --> but sends No Motion semaphore to alexa app. 2. $SayVar = 1 this is my sequence arbitrator initiating the pseudo MS to send the Motion On semaphore to alexa, happens immediately 3. $SayVar = 0 this is my sequence arbitrator program clearing the trigger signal and sending Motion Off semaphore to alexa app. If 1. causes a signal of No Motion to be sent to alexa (var=2), and that causes a lockout of alexa vocals for 30 seconds, it could explain 2. not functioning, immediately after. After much testing to prove this 30 second Routine lockout this was not the way it was working at that (previous) time. Now it would seem that either signal action, MS On, or MS Off, must have a 30 second day before any new signal action is sent or the Routine will not be triggered. More confirmation testing of this is needed. Tomorrow. Thanks guys! I think we are getting this down.

@bmercier and @tmorse305 I have since split my alexa Routine trigger timings, Var = 1 (causes vocal trigger if var was 0 originally) Wait 5 seconds, Var = 0 (causes vocal trigger if var was Not 0 originally) Wait 25 seconds for a workaround of this problem. This should only inject a 5 second delay, until the problem is resolved, when it should trigger the vocals immediately again.

It doesn't seem possible that the alexa Routine trigger could know the previous value of the variable converted to a status point, but it does. It would appear that the alexa system does the math and ISY Portal dictates the conditions.

Please see my findings here

@bmercier I have since discovered a bug in the ISY Portal pseudoMS routines. This is very weird but you will have deeper understanding of how this could happen. I have many $SayXXXXXX variables, that ISY Portal converts to pseudoMSes, all based on var = 1 = motion detected. These all show correctly in the amazon alexa app for each and every MS device, in all cases. However, 1. Changing a $SayXXXXX var from 0 to 1, causes the alexa MS to show "Motion Detected" and trigger the attached alexa Routine 2. ...after which, changing a $SayXXXXX var from 1 to 0, causes the alexa MS to show "Motion NOT Detected" and NOT trigger the attached alexa Routine 3. Changing a $SayXXXXX var from -2,-1,2,3,4, or 5 to 1, causes the alexa MS to show "Motion Detected" BUT NOT trigger the attached alexa Routine 4. ...after which, Changing same $SayXXXXX var from 1 to 0, causes the alexa MS to show "Motion Not Detected" BUT trigger the attached alexa Routine It would appear that not only alexa knows the status of the pseudoMS but also knows how it was caused and does not respond appropriately in the latter two cases above. I have now received a response from alexa support and they recognise they may have some Routine coding problems with no expected repair date yet.

Good observation! That makes my device observation in the app weak then. I went through my programs and there is nothing else that set the variables and I was triggering it by hand tweaking the variables with my sequencing program resetting it at the 30 second mark. The second trigger comes about 60-90 seconds after the first trigger. Perhaps tomorrow I better disable my software and then hand manipulate the variables to prove it wasn't my ISY since the app indicator is lagging.

AS a duplicate of the other thread started. Follow the instructions and enter the code into your admin console, save it and then copy and paste it here so people can see it. The pseudo code you posted is not runnable not being the way the code will look exactly. It appears to have parenthesis missing and some syntax errors.

a new quirk has just popped up here. Any time I trigger a spoken using Motion Off it triggers twice. I have watched the pseudoMS in the Alexa app to verify it is not coming from my iSY. It triggers immediately on 1 and then about 60 seconds again, later. You may be getting that also and confusing things. I added that to my support ticket today as that is new. I know they are playing with the Routine software...no doubt. There is a delayed trigger with the off detection but that has been verified there is a 0 setting for all my routines. Sent using Tapatalk

I talked to alexa support today. They will get back to me so it appears escalated anyway. Alexa app shows the pseudo-MS as Motion and No motion properly and as expected so it is totally inside the alexa app. Support started into the source of my MSes and I expected "Here comes the finger pointing" but then I remembered that alexa app already showed the correct state of the device, and it went well, after that. This also takes ISY Portal off the hook and dumps the problem into the alexa app totally. This has happened before where alexa routines just stopped working. Thanks for you responses and everything you have done Benoit! You have really changed the face/ears? of ISY!

I just talked to alexa support. Gotta love that one! The first one noted I was in Canada and then asked if my app URL was .ca or .com. I retorted it was an app and there was no URL.... "oh yeah but you need to call the Canadian support team". "How do I do that? I didn't even call you. I just clicked a link to call me in the alexa app" LOL!! Typical support for most companies! After being transferred to Canadian support the support front line took the information and is passing it on, with hopes of getting back today via email. BTW: You shouldn't need an additional Wait 30 seconds between trigger actions (var=0, Wait 0 seconds, nextVar = 1). Only needed for total between triggers. IOW: Only 30 seconds between speaking requests.

Thanks My ISY Portal hasn't changed for a long time and all checks OK. I am running ISY 5.3.0 but fairly sure vocals have functioned since then OK. Perhaps amazon changed IFTT functions? What is the syntax for the Rest GET? All I get is gooble-dee-gook back. eg: "http://192.168.0.161/rest/nodes/garage%20door%20one%20open" 404try { Object.defineProperty(screen, "availTop", { value: 0 }); } catch (e) {} try { Object.defineProperty(screen, "availLeft", { value: 0 }); } catch (e) {} try { Object.defineProperty(screen, "availWidth", { value: 1280 }); } catch (e) {} try { Object.defineProperty(screen, "availHeight", { value: 720 }); } catch (e) {} try { Object.defineProperty(screen, "colorDepth", { value: 24 }); } catch (e) {} try { Object.defineProperty(screen, "pixelDepth", { value: 24 }); } catch (e) {} try { Object.defineProperty(navigator, "hardwareConcurrency", { value: 8 }); } catch (e) {} try { Object.defineProperty(navigator, "appVersion", { value: "5.0 (Windows)" }); } catch (e) {} try { Object.defineProperty(navigator, "doNotTrack", { value: "unspecified" }); } catch (e) {} try { window.screenY = 713 } catch (e) { } try { window.screenTop = 713 } catch (e) { } try { window.top.window.outerHeight = window.screen.height } catch (e) { } try { window.screenX = 1273 } catch (e) { } try { window.screenLeft = 1273 } catch (e) { } try { window.top.window.outerWidth = window.screen.width } catch (e) { } -----------------------------------------------------------------------------------------------------------------------

@bmercier I have just found all my Alexa pseudo MS routines responding to "MS not detected" values instead of "MS detected" values in the state variables. This has been working for several years as "MS detected" but suddenly all 20 routines changed. I have made temporary changes in my critical Alexa routines to detect" NO MOTION" to trigger my routines until this can be stabilised. I strongly suspect this has been a change in the reporting from ISY Portal for pseudo MS devices. Can you please verify the ISY Portal pseudo-MS sending logic to Alexa has not been reversed recently (last week or two) before I open a ticket with amazon? (typically useless anyway) Thanks Benoit!!

To follow oberkc's thinking, try a wait 2 seconds between a few lines to see if it makes a difference when you test run "Then". You should have posted your program via copy to clipboard so people can see if it is enabled and other details.

Correct! They have been working on "detected" for a few years now. Suddenly they are triggering on the "Not detected" or when I release the variable to 0 again. Last two years about 20 routines set up like this: Var = 1 = ISY Portal pseudo MS = Motion = Routine trigger on Detected= say "whatever has happened" Now Var = 1 = ISY Portal pseudo MS = Motion = Routine trigger on Not Detected = say "whatever has happened" I was being fooled by the 30 second Wait timer for var = 0 but wondering why the vocal was being delayed 30 seconds and sometimes not coming through at all for the last few days.

to tag somebody you "quote" them or type an '@' followed by their name. Now you have to select the name from the auto-filled in fall down menu or it doesn;t happen. You will know by the coloured box around the text like this @BOden I have found to trigger a routine you only need a few seconds to hold the trigger flag on but Alexa will not allow faster than 30 second repeats of the action in order to eliminate DOS attacks and nuisance channel crowding. Right now I have just found all my routines triggering after the pseudo MS signal has released (no motion) and my routines stopped functioning without the 30 second delay. This makes my routine trigger arbitration program broken for the time being.

@bmercier I have just found all my Alexa pseudo MS routines responding to "MS not detected" values instead of "MS detected" values in the state variables. This has been working for several years as "MS detected" but suddenly all 20 routines changed. I have made temporary changes in my critical Alexa routines to detect" NO MOTION" to trigger my routines until this can be stabilised. I strongly suspect this has been a change in the reporting from ISY Portal for pseudo MS devices. Can you please verify the ISY portal MS sending logic to Alexa has not been reversed recently (last day or two) before I open a ticket with amazon? (typically useless) Thanks Benoit!!

I read the fix as: too short of a trigger signal On time. 30 seconds fixed it. "My configuration had some issues so I took it all back to factory (I don't know if it was related to the issue here)." You didn't flag @BOden to get his attention.

I just use one program that sets the variable to 1, Wait 30 seconds, set variable to 0. I was thinking of designing a stacking program so that variables would be set to 1 and cleared again in order so that no notification would ever be missed. It would be nice if ISY had indexed variable access or variable numbered access (arrays?) to make this easier.