I have a webcore piston that sets the volume levels on my various Echo Dots around the house based on the Hubitat mode... I had the same issue of having the speakers still set to volume 10 from playing music for housework in the afternoon, and then asking the Dot to change the thermostat cuz it's too cold at night... only to have it scream OKAYYY in the middle of the night.
I'd imagine you could do similar in RM or something, with a set volume command or something.
Is your dinner time music set for the same time every day? If so, just look into adding that volume set command to it.
That's the difference, unfortunately. Changing the volume of any of the Echo devices is easy. Changing the volume of a separate "works with Alexa" speaker is where the difficulty lies. I don't need to just do the equivalent of "Alexa, set volume to 7". I need to do "Alexa, set volume of soundbar to 7".
I think I have a workaround thanks to some undocumented local API functionality on the soundbar, but will need further testing to confirm.
I’ve been looking at this and it looks great. The one thing I’m not finding - is it possible to control directly from another Groovy app or do you have to setup routines and trigger those?
@tonesto7 I'm seeing something new today, probably just in the last hour. I've known there are some rate limits, although I've never seen any exact definition of what triggers it. But now, I'm hearing "Amazon force unit selection" repeated twice. The logs show:
Several tests give erratic results, but it is more likely if I try to speak a message on two or more devices. Sometimes the intended message or the error message never sounds. Something new from Amazon?
I'm not sure what they have been doing. They've been making changes to the WebAPI lately.
I almost think they are working towards blocking this whole exploit.
I seen a lot of rate limiting happening the last couple days
I have no idea what it means or if it has anything to do with it but it does appear they've changed something.
I changed my rule to use the dots as a "music device" instead of "speech device". That appeared to get rid of the strange message. I only checked it once as I had to run out but we'll see when I get home today.
Sorry if this has already been answered. I just installed Echo Speaks, but I'm not seeing an option for selecting a "button" for an event trigger. It's not an item on the selection list. Any thoughts? I'm running app version v3.4.0.0, socket v3.2.0.1, and server v2.3.1.
The latest update I applied to ES now locks my hub up (repeatable) anwhere between 6-8 minutes. I guess this timeframe corresponds to the amount of time it takes to use up any free hub "resources" after a reboot.
I opened a ticket with support & they confirmed it was ES that is in Bobby's words "eating your hub alive".
The WEIRD thing is I DID disable all ES related stuff; the App + 3 children, and eventually all the ES devices themselves. I took yet another reboot after that to get the "resources" to release, because despite disabling all, "ES devices were still locking your database a few hours ago."
Since this last reboot, ES remains disabled and my system is its "usual" self again...
I will be enabling ES again in due course, more than likely this evening, as a final test.
As mentioned, ES was running fine until this last update.
I like ES, love it in fact. Love my wife more! So I had to pick
I suspected as much. But I sure as shite am missing ES already, and don't know what I will be doing to get speech back if the issue persists. Here is crossing my fingers and toes that when I re-enable tonight, all stays stable...
Is there anything that I can do about this error? It happens randomly and I am not sure why or if it is related to the other errors that are being reported. BTW, This error occurs when Echo Speaks is not speaking so it is not triggered by use.
Thanks I saw those. I have been trying to figure out what the problem is. Each of my errors are associated with an individual Echo device and each and every one on my system triggers that same error. Hopefully @tonesto7 can track the problem down.
