Northwoods Ranger

Hey, thanks for the heads up! I can confirm that she is back this morning and like you, I never touched a thing. It would be good to understand just how broken this functionality is in order to determine its future use in new development. I'm just having problems with this functionality randomly failing for days at a time and then magically restored without knowing the "why". Regards,

And here we go again, Alexa notifications are no longer working for me while Pushover alerts seem just fine. For me, Alexa spoken notifications are triggered by toggling a variable. The programs involved haven't changed in over a year but work/don't work for days at a time. Running the routines from my phone and from the Alexa app produces the expected result. Hopefully resolved (again) soon... Regards

One other thing to keep in mind when running down perceived Alexa failures is the inherent/imposed throttling of all the devices involved by their built-in reset time, including the throttling that Amazon imposes on notifications. In my case I have a driveway monitor that includes an alarm with a built in low-voltage relay that is connected to an Insteon I/O Linc 2450 controller. The I/O Link is what initiates program execution and that in turn sends out my notifications. Currently those include Alexa spoken notifications at the house and Pushover push notifications to my phone. A couple of observations. One, each device employed has a defined “reset” period where it will wait for this period to expire before being able to do its thing again. In my case, across all of the devices involved, this is fractions of a second up to a 4 second wait. The issue comes in where there are multiple trips of the driveway sensor received in quick succession. The built in “reset” time will generally still be counting down it’s reset period while the sensor is trying to convey it’s next closely spaced trip. The other thing I wanted to mention is that once you have this entire process optimized as best you can, you still end up having to deal with Amazon’s API limitations. Amazon limits the number of spoken notifications that can be sent in a specific time period. Exceed that, and all indications are that some sort of throttling is applied. The only reference I could find was the following: “Amazon limits the number of notifications that Alexa skills can send to customers in a 24-hour period through the Proactive Events API. Amazon may adjust this limit based on customer feedback. Notification API: Trigger events can only create notifications up to five times in a five-minute period. After that, Amazon will put you in a time-out.” In the end, where a multiple trip scenario is playing out, Pushover will always register closer to the actual number of alarm trips than the Alexa spoken notifications. Largely I suspect due to the time it takes to process the Alexa notification and then the imposed throttling described above. Just some things to consider when creating your own notification scheme…

This happened to me and I think the original issue was resolved. If it still not working for you it may have been something else. Spoken notifications came back for me without touching anything, but it did take a couple of days before it happened.

Yes, having the same issue here. Found this looking to see if anyone else was having a problem with Alexa. Restarted everything on my end and the problem persists... Regards, Jim

Upgrading to 5.8.3 fixed it for me. Thanks all...

Just throwing this out there for consideration… Instead of using a specific time of day that varies by season, if the goal is to drop or raise window shades, how about doing that with respect to how much light is being exposed to the area you want to cover with the shades? This prevents dropping the shades on a cloudy/rainy day and doesn’t require any complicated calculations regarding Solar Noon. The downside is that you would need a WirelessTags nodeserver and the requisite sensors in place where you want to measure light. I use this method for turning lights off and on in the family room at specified times during the day. Measure the amount of light in LUX reported by the wireless tag and take appropriate action based on that value. In the evening, it doesn’t take much before you get a feel for what LUX value is too low and its time to turn on the lights. Additionally, in the morning, I turn the lights on at a fixed time and then run a program to monitor LUX values. Once bright enough, turn the lights off. I suspect the same could be used for lowering or raising window shades…

This kind of falls into the category of “anything else”. I use Wireless Tags primarily for temperature and humidity sensing but also do exactly what you are looking for. One of their tags (Tag Pro ALS) also has the ability to measure Lux, so therefore can report back to the ISY ambient light at any location the tag is placed. I run a couple of programs that monitor this Lux value and turn on or off lights in the house as appropriate. You would need the Wireless Tags equipment as well as a Polyglot/Polisy setup to make it work so this may be more involved than what you are looking to do.