Unwanted triggers of EChoSpeaks actions

davethomaspilot · June 1, 2021, 8:43pm

An EchoSpeaks action is triggering when not expected. The trigger for the action is when a scene (bedtime) is activated:

I have a Hubitat group "All" and an associated, EchoSpeaks action. The EchoSpeaks action that is expected occurs, but when I turn the group off, I not only get the expected EchoSpeak action, but also the action that should only occur when the bedtime scene is activated.

How would I track down what's going on? Like turning on a log print that indicates what triggered the EchoSpeaks action?

I have already changed preferences in the EchoSpeaks device to show debug logs and show detailed logs in addition to info logs and warning logs. But, I don't see anything that indicates what triggers the undesired EchoSpeaks action.

davethomaspilot · June 1, 2021, 9:56pm

When I used the Debug Preferences in the app (versus changing log preferences in the EchoSpeaks device), I get useful entries in the log.

Should be able to figure out soon.

davethomaspilot · June 2, 2021, 7:17pm

Can't figure out the cause of the unwanted EchoSpeaks actions.

I have a scene activation switch "bedtime" and an EchoSpeaks action "Bed Time". The EchoSpeaks action trigger is set to activate only when the switch "bedtime" is turned on;

I have a grouped name "all". When I turn off "all", a desired EchoSpeak action occurs, but the "Bed Time" EchoSpeaks action is also triggered.

Here are the logs when I turn off all:

[app:85](http://hubitat/logs#app85)2021-06-02 03:00:15.133 pm [debug](http://hubitat/installedapp/configure/85)EchoApp (v4.1.7.0) | workQ active: false work items fnd: false now: 1622660415130 nextOk: 0

[app:85](http://hubitat/logs#app85)2021-06-02 03:00:15.129 pm [trace](http://hubitat/installedapp/configure/85)EchoApp (v4.1.7.0) | running workQ

[app:85](http://hubitat/logs#app85)2021-06-02 02:59:51.724 pm [debug](http://hubitat/installedapp/configure/85)EchoApp (v4.1.7.0) | workQ active: false work items fnd: false now: 1622660391721 nextOk: 1622660400358

[app:85](http://hubitat/logs#app85)2021-06-02 02:59:51.721 pm [trace](http://hubitat/installedapp/configure/85)EchoApp (v4.1.7.0) | running workQ

[app:85](http://hubitat/logs#app85)2021-06-02 02:59:51.654 pm [trace](http://hubitat/installedapp/configure/85)EchoApp (v4.1.7.0) | running finishWorkQ

[app:85](http://hubitat/logs#app85)2021-06-02 02:59:51.378 pm [debug](http://hubitat/installedapp/configure/85)EchoApp (v4.1.7.0) | workQ active: true work items fnd: true now: 1622660391375 nextOk: 1622660400358

[app:85](http://hubitat/logs#app85)2021-06-02 02:59:51.371 pm [debug](http://hubitat/installedapp/configure/85)EchoApp (v4.1.7.0) | workQ FINAL ms delay is 9000.0

[app:85](http://hubitat/logs#app85)2021-06-02 02:59:51.369 pm [debug](http://hubitat/installedapp/configure/85)EchoApp (v4.1.7.0) | workQ ms delay is 9000.0

[app:85](http://hubitat/logs#app85)2021-06-02 02:59:51.367 pm [debug](http://hubitat/installedapp/configure/85)EchoApp (v4.1.7.0) | workQ adding sendDevObjCmd speak to device 85|echoSpeaks|G070RQ139185002G | MultiSequence : Sequential

[app:85](http://hubitat/logs#app85)2021-06-02 02:59:51.364 pm [debug](http://hubitat/installedapp/configure/85)EchoApp (v4.1.7.0) | workQ ms delay is 7000.0

[app:85](http://hubitat/logs#app85)2021-06-02 02:59:51.362 pm [debug](http://hubitat/installedapp/configure/85)EchoApp (v4.1.7.0) | workQ adding sendDevObjCmd speak to device 85|echoSpeaks|G070RQ139185002G | MultiSequence : Sequential

[app:85](http://hubitat/logs#app85)2021-06-02 02:59:51.347 pm [trace](http://hubitat/installedapp/configure/85)EchoApp (v4.1.7.0) | running workQ

[app:85](http://hubitat/logs#app85)2021-06-02 02:59:51.085 pm [debug](http://hubitat/installedapp/configure/85)addToQ (multi) | Command(1): [command:ssml, value:Have a nice night!, deviceData:[serialNumber:G070RQ139185002G, deviceType:A10A33FOX2NUBK, owner:A2USDQEK8XS6EB, account:A06170443BL3Z3EJ1IV9V], cmdType:sendSpeak]

[app:85](http://hubitat/logs#app85)2021-06-02 02:59:51.083 pm [debug](http://hubitat/installedapp/configure/85)addToQ (multi) | srcDesc: sendDevObjCmd speak to device 85|echoSpeaks|G070RQ139185002G

[app:85](http://hubitat/logs#app85)2021-06-02 02:59:51.080 pm [debug](http://hubitat/installedapp/configure/85)addToQ (multi) | callback: finishSendSpeakZ

[app:85](http://hubitat/logs#app85)2021-06-02 02:59:51.078 pm [debug](http://hubitat/installedapp/configure/85)addToQ (multi) | device: 85|echoSpeaks|G070RQ139185002G

[app:85](http://hubitat/logs#app85)2021-06-02 02:59:51.075 pm [debug](http://hubitat/installedapp/configure/85)addToQ (multi) | time: 1622660391053

[app:85](http://hubitat/logs#app85)2021-06-02 02:59:51.072 pm [debug](http://hubitat/installedapp/configure/85)addToQ (multi) | cmdMap: [cmdDt:1622660391053, cmdDesc:SpeakCommand, message:<speak><voice name="Kimberly">Have a nice night!</voice></speak>, msgLen:64, oldVolume:null, newVolume:null]

[app:85](http://hubitat/logs#app85)2021-06-02 02:59:51.069 pm [debug](http://hubitat/installedapp/configure/85)addToQ NEW COMMAND (2)

[app:85](http://hubitat/logs#app85)2021-06-02 02:59:51.057 pm [debug](http://hubitat/installedapp/configure/85)EchoApp (v4.1.7.0) | sendDevObjCmd | cmd: speak | devObj: [[deviceTypeId:A10A33FOX2NUBK, deviceSerialNumber:G070RQ139185002G, deviceOwnerCustomerId:A2USDQEK8XS6EB, deviceAccountId:A06170443BL3Z3EJ1IV9V, dni:85|echoSpeaks|G070RQ139185002G]] | msg: Have a nice night! title: Bed Time | volume: null | restoreVolume: null

[app:85](http://hubitat/logs#app85)2021-06-02 02:59:51.045 pm [debug](http://hubitat/installedapp/configure/85)addToQ (multi) | Command(1): [command:ssml, value:Turning off TV, amplifier, and satellite receiver, deviceData:[serialNumber:G070RQ139185002G, deviceType:A10A33FOX2NUBK, owner:A2USDQEK8XS6EB, account:A06170443BL3Z3EJ1IV9V], cmdType:sendSpeak]

[app:85](http://hubitat/logs#app85)2021-06-02 02:59:51.042 pm [debug](http://hubitat/installedapp/configure/85)addToQ (multi) | srcDesc: sendDevObjCmd speak to device 85|echoSpeaks|G070RQ139185002G

[app:85](http://hubitat/logs#app85)2021-06-02 02:59:51.040 pm [debug](http://hubitat/installedapp/configure/85)addToQ (multi) | callback: finishSendSpeakZ

[app:85](http://hubitat/logs#app85)2021-06-02 02:59:51.037 pm [debug](http://hubitat/installedapp/configure/85)addToQ (multi) | device: 85|echoSpeaks|G070RQ139185002G

[app:85](http://hubitat/logs#app85)2021-06-02 02:59:51.029 pm [debug](http://hubitat/installedapp/configure/85)addToQ (multi) | time: 1622660391002

[app:85](http://hubitat/logs#app85)2021-06-02 02:59:51.026 pm [debug](http://hubitat/installedapp/configure/85)addToQ (multi) | cmdMap: [cmdDt:1622660391002, cmdDesc:SpeakCommand, message:<speak><voice name="Matthew">Turning off TV, amplifier, and satellite receiver</voice></speak>, msgLen:94, oldVolume:null, newVolume:null]

[app:85](http://hubitat/logs#app85)2021-06-02 02:59:51.023 pm [debug](http://hubitat/installedapp/configure/85)addToQ NEW COMMAND (1)

[app:85](http://hubitat/logs#app85)2021-06-02 02:59:51.002 pm [debug](http://hubitat/installedapp/configure/85)EchoApp (v4.1.7.0) | sendDevObjCmd | cmd: speak | devObj: [[deviceTypeId:A10A33FOX2NUBK, deviceSerialNumber:G070RQ139185002G, deviceOwnerCustomerId:A2USDQEK8XS6EB, deviceAccountId:A06170443BL3Z3EJ1IV9V, dni:85|echoSpeaks|G070RQ139185002G]] | msg: Turning off TV, amplifier, and satellite receiver title: All | volume: null | restoreVolume: null

Another piece of info that might be relevant. If I turn off all more than once without turning it on, the EchoSpeaks action is NOT triggered. Also, the off method of some of the switches in group do not get called. The switches that don't get called are of a type for which I've implemented a custom driver.

Regardless of the unwanted EchoSpeaks action, I'd like to figure out why my off and on methods of a switch capability only get called when Hubitat thinks there is a state change. (It's not possible for Hubitat to correctly keep track of the state of these switches).

The on/off methods in the custom driver have this in them (in addition to sending a message to a socket to do the actual on/off):

on method:
sendEvent(name: "switch", value: "on", isStateChange: true)

off method
sendEvent(name: "switch", value: "off", isStateChange: true)

tony.fleisher · June 2, 2021, 7:48pm

Do you have on/off optimization enabled for the group?

tony.fleisher · June 2, 2021, 7:51pm

The logs provided show only the app and not the devices. Have you checked the events that are sent for this device? You can find the list of events and times from the device detail screen by clicking on the "Events" button at the top.

davethomaspilot · June 2, 2021, 10:12pm

No

davethomaspilot · June 2, 2021, 10:19pm

So, looking at the "bedtime" events, I see the events

Scene Activator tog

Does a scene activator switch get turned on when the devices it can control matches the scene capture state?

davethomaspilot · June 2, 2021, 10:26pm

So, I duplicated the spurious trigger several time, just a couple of minutes ago. Now, I'm not getting any unwanted triggers.

Only thing different is that I'm switching back and for between the "all" device and the "bedtime" device.

davethomaspilot · June 2, 2021, 10:59pm

Actually, I do not see an option for on/off optimization for the group, in the device menu.

davethomaspilot · June 2, 2021, 11:15pm

I'm thinking the scene activator can become set and unset based on the state of the devices controlled by the scene. Can anyone confirm or refute this?

If that's right, using this scene controller as a trigger can never be reliable.

davethomaspilot · June 2, 2021, 11:44pm

I'm back to having the issue again.

That's what's going on--

The scene activator goes from "off" to "on" when the devices it controls are in the same state as when the scene was defined.

That's not what I want. I only want the trigger when the scene is activated by Alexa (or when turning the scene on/off from a dashboard or device menu.

So, I'll avoid using the scene activator and use another group or Rules instead.

neonturbo · June 3, 2021, 2:39am

I don't quite get what you are trying to do. Maybe I am tired tonight or something?

I have never used that function of Echo Speaks. And I think that is adding a layer of complexity that is not helping.

But if I do understand what you are trying to do, I have something similar where I have a virtual switch that I expose to Alexa App (not Echo Speaks). That virtual switch then runs a rule where stuff happens.

You also can use a scene switch directly in Alexa, just like any ordinary light switch. You could name the scene "bedtime" and just say "Alexa, turn on bedtime".

davethomaspilot · June 3, 2021, 1:17pm

Yes, I think using a virtual switch as a trigger instead of a scene activator will avoid the unwanted triggers. I have other Echo Speak actions that are triggering from virtual switches (vs. scene activation switch) and haven't seen unwanted triggers.

Also, activating a scene from Alexa is not an issue. It's just using the scene activation as a trigger for EchoSpeak events that seems problematic.

I was using a scene activator since I was next going to play with setting lights at different colors and brightness levels and have an associated EchoSpeaks when different scenes were activated. But, the problem seems to be the scene activator seems to turn on when the switches it controls go to the states defined by the scene.

For example, say the scene activator sets 5 lights to off. Turning the scene on turns all 5 lights off and actions with triggers that monitor that scene activator switch execute if conditions are met-- that's what I want.

But, say all switches controlled by the scene activator are off but one. When that remaining switch is turned off by something other than scene activation, the scene activator switch state goes to on. This triggers actions configured to trigger from that scene activation switch (not what I want).

There are a lot of ways to implement the final result I want. It's just that the behavior of the scene activation switch was surprising to me, and I just wanted to ask if it was intended. Maybe it's a bug.

davethomaspilot · June 3, 2021, 1:49pm

I can confirm a scene activator switch will change states without it being turned on directly.

A scene activator will turn to off state when a device whose state was included in the scene is changed. The scene activator will go back to on, when that device goes back to its state when the scene was defined.

So, I think use of sceneActivator should never (or at least rarely) be used as a trigger event. Rather, a separate switch should be used that both activates the sceneActivator AND is used as the trigger for an action like EchoSpeaks.