BUG in RM?


#1

I was adding one of my last devices being moved to HE a ST Arrival Fob V4 which I'm having some issues with (see separate topic).

I created a rule for this device that triggers on sensor arrival and leave. On Sensor Arrival I had the sensor to say on Google home and pushover that I had arrived. However as the sensor is triggering multiple times even though I never left the home and the Google home was getting everyone mad I went to disable the Google announces. To my surprise they kept coming.
I thought well maybe I didn't save. I went back again and I have this:


So even though Google home is disabled it still shows as enabled and old command are still broadcasting


#2

Take a look at the events page for your arrival sensor. If it tripped 100 messages in a row, that means that 100 TTS messages are queued up to play on your GH. That's why implementing rule PB to false and then true after a time period is so important with TTS broadcasts. Same thing happens with contact sensors. Some are so sensitive you get 4 or 5 broadcasts every time you open a door.


#3

Is not this case.
It's nothing in queu. This happens every single time the arrival changes to arrive and only once.


#4

The one event sends dozens of TTS messages to your Google Home? Do you have any logs to post? Is this a Rule Machine Rule or some other app?


#5

Look at the app events for your rule. It will show you what it's doing.


#6

@bravenel
What do you mean? The apps events only has two event types.
It only shows when it is true or false or when the sensor triggers the rule.
It does not show any actions of the rule.

By the way this are the exact same events that show on the past logs


#7

But it shows all events that RM does, so you can see that it ran the rule twice in your screenshot. You didn't show the times, but this would allow you to see if there were multiple presence events driving it or not. Also, turn on Logs. RM logs each event that hits it and "ST Tag is now True" means it ran and did it's action. It doesn't do actions multiple times. Most likely you have a TTS issue of some sort.


#8

I will enable RM debug logs
Do not believe that it's an issue with TTS. If it is it's specific to this rule as all other rules that use TTS are working fine.


#9

Easy enough to test. I have almost identical rules, but TTS to Sonos instead of GH. They've been working fine for a very long time... I'll match your "Do not believe it's an issue with TTS" with Do not believe it's an issue with RM.


#10

I believe you :joy::rofl:
But than either is an issue/bug with the Chromecast beta or with RM...
But it's strange that's only happening with this specific rule. I will try to replicate it as well.


#11

You mean the uniQ bug? :wink:


#12

Don't think so all my TTS are running ok. They are sparse well enough.


#13

@bravenel
However even if there is a bug with TTS there is one with RM as well.

If you notice my screen shots above you will see that the speak message function is disabled. However in the previous screen it is showing as if it was STILL enabled. I believe this is what's causing the issue.

This are the logs:

app:3412019-03-05 22:37:57.012infoST Tag is now True
dev:552019-03-05 22:37:56.297infoSending Message: xxxxx Acabou de Entrar Priority: 0 to Device: xxxxx_Galaxy_S8
app:3412019-03-05 22:37:56.270 info --> SmartThings Presence Sensor V4 present [true]

I will create a video and send through PM as there is some private data.


#14

I suggest you simply remove that rule and recreate it. See if that fixes it. Did you hit Done all the way out of the rule after turning off Speak?

Yes, there is a UI bug when you deselect Speak this message.


#15

Ok so that's the bug...
It basically does nothing when you deselect/disable the speak command....

I will just delete it then.


#16

Or, re-enable speak, then remove the speech device, then disable speak. There is a bug that it's not checking that selector.


#17

That sorted it.
Will this be addressed on the next release?
As it is expected that when you disable a selector that you disable everything with in.


#18

Yep, just put the fix in.