larryllix Posted November 19, 2020 Posted November 19, 2020 (edited) @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!! Edited November 19, 2020 by larryllix
bmercier Posted November 19, 2020 Posted November 19, 2020 4 minutes ago, larryllix said: @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!! There has been no changes to motion sensors for several months. There are 2 things that may have changed which would reverse the logic. 1. Check your Portal echo config, and double check your device is categorized as a motion sensor (and not contact sensor). A contact sensor works in the opposite direction of a motion sensor. If it was a contact sensor, it would report the opposite. 2. Did you change firmware versions recently? There might be a bug. Check the output of /rest/nodes/<your isy device>. When there is no motion, the value of the ST property should be 0. If all looks good, I would encourage you to report to Amazon. Benoit
larryllix Posted November 19, 2020 Author Posted November 19, 2020 (edited) 24 minutes ago, bmercier said: There has been no changes to motion sensors for several months. There are 2 things that may have changed which would reverse the logic. 1. Check your Portal echo config, and double check your device is categorized as a motion sensor (and not contact sensor). A contact sensor works in the opposite direction of a motion sensor. If it was a contact sensor, it would report the opposite. 2. Did you change firmware versions recently? There might be a bug. Check the output of /rest/nodes/<your isy device>. When there is no motion, the value of the ST property should be 0. If all looks good, I would encourage you to report to Amazon. Benoit 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) { } ----------------------------------------------------------------------------------------------------------------------- Edited November 19, 2020 by larryllix
bmercier Posted November 19, 2020 Posted November 19, 2020 14 minutes ago, larryllix said: 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) { } ----------------------------------------------------------------------------------------------------------------------- Oh, so your motion sensors are variables. This is the URL to get your state variable status: /rest/vars/get/2 From what I see, If your variable is set to 1, motion should be detected, else, no movement. Benoit
larryllix Posted November 19, 2020 Author Posted November 19, 2020 (edited) 8 minutes ago, bmercier said: Oh, so your motion sensors are variables. This is the URL to get your state variable status: /rest/vars/get/2 From what I see, If your variable is set to 1, motion should be detected, else, no movement. Benoit 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! Edited November 19, 2020 by larryllix
larryllix Posted November 20, 2020 Author Posted November 20, 2020 @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.
tmorse305 Posted November 20, 2020 Posted November 20, 2020 20 minutes ago, larryllix said: 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 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. 1
larryllix Posted November 20, 2020 Author Posted November 20, 2020 9 minutes ago, tmorse305 said: 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. 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. 1
larryllix Posted November 20, 2020 Author Posted November 20, 2020 (edited) @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. Edited November 20, 2020 by larryllix
bmercier Posted November 20, 2020 Posted November 20, 2020 8 minutes ago, larryllix said: @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. Let me clarify what ISY Portal does. First of all, the previous value of the variable does not matter at all. Portal never keeps the previous value anyway. The logic is this; When receiving a variable value in the subscription: If the new value = the configured value for motion: An event is sent to Amazon telling that motion is detected. If the new value is not equal to the configured value for motion: An event is sent to Amazon telling that motion is NOT detected. This means that if the value is changed to various values outside the configured motion value, the not detected event may be sent multiple times. How does Alexa reacts to that? I'm not fully sure. If the state is the same as the previous state, I think it should be doing nothing. If a routine is configured to be triggered when there is no motion, then perhaps it could be triggered multiple times. Another case I need to mention: Whenever a request to "get a system status" is sent to ISY, the values of the nodes and variables are sent to all the subscribers... such as ISY Portal. This means that it's entirely possible to receive a variable value = the configured value, and later receive it again without actually changing the variable. This means the motion detected event could be sent twice. How does Alexa reacts to that? Same as above, not sure. Benoit 1
tmorse305 Posted November 20, 2020 Posted November 20, 2020 (edited) 32 minutes ago, larryllix said: 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 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. Edited November 20, 2020 by tmorse305
larryllix Posted November 21, 2020 Author Posted November 21, 2020 10 hours ago, bmercier said: Let me clarify what ISY Portal does. First of all, the previous value of the variable does not matter at all. Portal never keeps the previous value anyway. The logic is this; When receiving a variable value in the subscription: If the new value = the configured value for motion: An event is sent to Amazon telling that motion is detected. If the new value is not equal to the configured value for motion: An event is sent to Amazon telling that motion is NOT detected. This means that if the value is changed to various values outside the configured motion value, the not detected event may be sent multiple times. How does Alexa reacts to that? I'm not fully sure. If the state is the same as the previous state, I think it should be doing nothing. If a routine is configured to be triggered when there is no motion, then perhaps it could be triggered multiple times. 10 hours ago, tmorse305 said: 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. 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.
Recommended Posts