Tuya Smart Siren Zigbee driver -> playSound = causing device to freeze on C8

On my C8 v2.3.5.152
using Tuya Smart Siren Zigbee driver for Hubitat
def version() { "1.2.2" }
def timeStamp() {"2023/07/19 9:30 PM"}

by @kkossev

I'm using this same Tuya Siren Device which I've used a lot on my other installs (C7s)
Untitled

I'm running the exact custom action I have on my C7 which is

When running this action, the device doesn't work and it actually freezes.. I have to reboot the device to get it to work again. This is a similar issue that I've reported in the past, which was supposed to be resolved in previous versions of the driver (right?)

Anyway, checking the logs, I'm getting this:

...playSound 4 (4=4 Key Chime) index=3, duration=10, volume=unknown(-1)

Notice the 3rd parameter VOLUME UNKNOWN?

Now, running the same action on my older c7 with the same type of siren (not the exact same unit) I get this from the logs:

...playSound 4 (4=4 Key Chime) index=3, duration=5, volume=medium(1)

and it works flawlessly

Is there a different way the action and parameters are implemented in C8?
Or is this an issue with the siren device itself having different implementation?
but both devices have the following details:

  • manufacturer: _TZE200_t1blo2bj
  • model: TS0601

Issue prevails even when calling the playSound function from the Driver

Although strangely enough, if I don't enter any parameters in the volumeLevel field then the darn thing works (it executes @ default volume)

I'm stumped.

here's short video demo

UPDATE 1: I got another siren that works with C7, and tested it w/ the C8, same issues.
I also got another C8 to test w/ both sirens, same issues.. I also tested the prev siren i've been testing earlier, and tested it with my older C7 and it worked.

So i can concur that the siren devices aren't the issues, but something to do with the Driver and the new C8 Hub :frowning:

1 Like

Hi Tj,

The reason for the device freezing is definitely a bug in the driver.
I see it thanks to your screenshot here :


Because of a failed 'volume' parameter conversion from string to integer, the value sent to the device is 0xFFFFFFFFF, which causes it to freeze.

What puzzles me is why there is a difference between C-7 and C-8 hubs? The behavior should be one and the same, i.e., the bug must also show up on your C-7 hubs.

The 'PlaySound' custom command takes 3 parameters. What are the parameter types - string or number? The command should work with both types, but ...

Can you check if there is a difference in the playSound parameters type between your C-7 and C-8 hubs RM5.1 rules?

Ah that is strange indeed.

I can confirm that the C7 and C8 RM settings share exactly the same playSound settings and values, and that I always use NUMBER as parameter type.. and when i started hitting these issues, i tried using string and decimal just to take a chance but obviously those didn't work either.

So I stuck with NUMBER type for the playSound parameters.

Would there be a quick fix for this anytime soon?

I will try this weekend…
BTW, are you using the standard PlaySound action, or a custom PlaySound action in your RM rule?

This is part of the problem… I may need to change the custom action that sets the melody, the volume and the duration in one single (and quick!) command to have a new name … ‘PlaySoundEx’ as example.

Umm.. I dont know what the standard PlaySound is. I'm simply using

RM -> Run Custom Actions -> Actuator - PlaySound

OK, clear.

1 Like

@tj1 please test this new driver version : ver. 2.1.5 "2023/09/03 7:18 PM"

Update your existing driver code from here (new URL!) :

https://raw.githubusercontent.com/kkossev/Hubitat/development/Drivers/Tuya%20Smart%20Siren%20Zigbee/Tuya_Smart_Siren_Zigbee_lib_included.groovy

This dev. branch version of the "Tuya Smart Siren Zigbee" has a lot of changes, as it is based on the common code that I used in my other drivers in the last months. The "playSound" bug should be fixed, but it may be a good idea to test whatever other functions you are using.

If it works OK for you, next step will be to update the 'production' version and put it in HPM. The file name of the driver and the GitHub URL are changed.

I just tested it, unfortunately it didnt work

I was triggering the playSound from the device page (didn't make RM rule for now)

still the exact same results as original driver, where:

  1. Volume parameter unknown
  2. this error freezes the siren (i had to reboot it to get it back to responsive state)
  3. leaving the volume parameter blank is working

Other functions on the driver page seems to work fine though.

You are right, I was able to reproduce the issue on my C-8 hub. At the same time, the same code works without a problem on my dev. C-7 hub! This is the first time I have seen a difference between C-7 and C-8 driver code execution.

I am stunned... It will surely take some time to find out the reason and provide a fix.

Glad to contribute and yes I am also baffled with this. Unless C-8 has a different implementation we dont know about, or it's just an outright bug in its firmware where the 2nd parameter (volume) is lost or something, i don't know what else it could be.

I do hope you figure it out and solve it soon but the hubitat guys may need to chime in on this one.

Good luck and lemme know how else I could help.

BTW, I kinda have to finish this install soon, and if the thing works as long as I leave the volume (parameter 2) undefined, then I'm cool with it for now. However, it seems to only work with the device property page and controls. I played around with the RM Rules and I can't seem to find a way to NOT define the 2nd parameter.. I tried entering blank string, the word null, the word null in number type, 0 (zero), etc.. nothing seems to work, the 2nd parameter gets passed, and triggers the issue.

any ideas?

regards

I found the bug in the driver code this morning , will send you a fix later tonight.

1 Like

@tj1 updated the driver to ver. 2.1.5 "2023/09/03 8:45 PM"
The bug was in the function that translates the Hubitat standard Volume attribute (range 0..100) to Tuya-specific volume value (0, 1, or 2). And the C-8 and C-7 hubs really handle this bug in a different way (wrongly trying to obtain the value of a static map value), but it a bug in the code anyway, so I will not dig further.

Alright, confirmed working man, thanks very much! whew

1 Like