No sense is doing that if you can make chimes work as designed.
In case anyone else is having an issue getting the powerSource attribute to kick in, simply unplug and then replug-in the device. Then, viola - it appears.
I am kicking myself that it took me this long to remember that trick from my ZAC38 installs, but c'est la vie.
In other news, it looks like Zooz just released an interesting new product (Zen78) -- they seem to be back to putting new releases down at the end of pg 2 of their catalog lately ![]()
I agree, but till that happensâŚ..
I wonder if you rename the chime file to something else what would happen
I'll "chime in" here to say that I'd def like a "chime" that plays the sound once and a "siren" that plays it until stopped.
Ideally, the device would manage the looping so it doesn't best up the z-wave network.
I can't tell if you are restating the obvious or asking for something it does t have.
https://www.support.getzooz.com/kb/article/2095-zse50-siren-chime-advanced-settings/
Well. I got the device and went on vacation before the driver and updated firmware.
It didn't have those abilities then and it's sounds like others want them features, too.
Did you look at the link?
This would work. I've done this before in some scenarios but you run into an interesting situation where if a siren is set off when you run that off command, you null out the siren. So it does work, but it has pitfalls. I suppose you could work all that into some rule logic if you really wanted to but it's not THAT important to me.
Just noticed I am getting a whole slew of errors with the new driver. Here is just a few:
dev:33352025-09-24 05:13:16.506 AM
error
java.lang.NullPointerException: Cannot get property '0' on null object on line 250 (method parse)
dev:33352025-09-24 05:13:14.907 AM
error
java.lang.NullPointerException: Cannot get property '0' on null object on line 250 (method parse)
dev:33352025-09-24 05:13:12.733 AM
error
java.lang.NullPointerException: Cannot get property '1' on null object on line 250 (method parse)
dev:33352025-09-23 09:07:35.191 PM
error
java.lang.NullPointerException: Cannot get property '0' on null object on line 250 (method parse)
dev:33352025-09-23 09:07:33.396 PM
error
java.lang.NullPointerException: Cannot get property '18' on null object on line 250 (method parse)
dev:33352025-09-23 09:07:33.315 PM
error
java.lang.NullPointerException: Cannot get property '18' on null object on line 250 (method parse)
dev:33352025-09-23 09:06:08.755 PM
error
java.lang.NullPointerException: Cannot get property '0' on null object on line 250 (method parse)
dev:33352025-09-23 09:06:06.380 PM
error
java.lang.NullPointerException: Cannot get property '10' on null object on line 250 (method parse)
I think I'm missing something here. In the sound list there is siren. when I set off siren it runs for the amount of time set in the settings, or till I stop. In the settings I have to set the number of the sound file for the siren.
I don't see a specific chime sound, just doorbell. When I trigger doorbell1 it only chimes or ding-dongs once.
I don't have most of the original sound files on the device anymore as I didn't need most of them. Replaced with my own. Kept just a few, doorbell1 and siren for example.
For me personally, i'm just using chime as a description of what i'm attempting to do. The chime function exists as something you can "call". In this case, i called an AI sound i made that just says "Front Door" when the front door opens.
The ZSE50 is can act as a speaker or a siren, which hubitat seems to treat differently. This new driver was what added the ability to use it as a siren, when means you can tell HSM to sound the "siren" command when an event occurs, which it seems that is configured by setting the sound file number in the configuration of the device itself. Then when i want the chime to function, i tell it to play whatever sound number corresponds to the event.
Hopefully that makes sense and wasn't just a bunch of word vomit.
I understand perfectly. I guess where the difference comes in, I'm not using RM. So in my own apps I just issue 'device.playSound(##). Which plays speech or doorbell or whatever. If I do 'device.siren()' then the siren goes off and keeps going till I stop or the timer runs out. The Siren being the sound file I set in preferences.
I guess I don't understand why RM would not be doing the same thing.
EDIT: Reread your post and am even more confused. I thought the issue was the sound or file you played was running continuously which was the problem????
Sorry i'm jumping all over alot.
When i utilize that rule as I posted there from rule machine, and i have the Siren configuration said to loop, running the chime command and calling sound 28 causes it to play on repeat until a stop is initiated. Now, if i tell it to only play the siren once, the chime only plays once BUT then it also causes the siren to only play once. So, the way that it works currently, if you want a consistent siren but you also want to be able to play a sound for other occassions, you cannot do it without creating further logic or like jtp said, flip the configuration every time one of those actions is performed.
So what you're saying is if the 'Siren Playback Mode' is set to loop it affects all the other sounds? Yeah, I can see where that is a problem. I never changed that setting so thus never saw the issue.
If I am correct on this that setting really should be called something else. To me it would infer it only applies to siren, but what do I know.
Bingo. You got it! and I agree, it's misleading.
Its only misleading due to the way I assume the driver was built (I have not actually seen the built in driver yet).
Those settings for the device apply to all sounds played AFAIK. There is no different way to initiate a "chime" vs a "siren" to the device itself, the driver would send the same command for both. You can either specify the tone number to play or send 255 to tell it to just play its default. This is per zwave specs of the class the device uses.
I have a couple of ideas on how to work around these limitations with a driver. All this feedback on how people are using the device is helping to shape my ideas.
For now I would try doing as someone suggested as above, set the settings for how you want the "siren" to work. If you want to do a single chime then send a delayed off command to make it stop when you desire.
So you don't think you have the control needed with the current parameters?
https://www.support.getzooz.com/kb/article/2095-zse50-siren-chime-advanced-settings/
That is awesome news - thank you!
I think I've said this in earlier zse50 discussions, but if some kind of "setLED" (or equivalent) could be added to the driver, that would be super sweet. But perhaps Zooz hasn't made such a thing easy or possible yet.
I'm really hoping to leverage this device for LED notifications as much (if not more) than any audible sirens/chimes.
Not really sure what you are referring to? You can customize it with the settings, yes, but that applies to all tones played. If you want one tone to loop forever and another to only play once then those settings do not allow that. You would have to change the settings between each playback.
I played with that a little in ST and I think I had to set certain device settings to get it to light only the LED with no sounds. So to do LED only, on the fly, settings might need to be adjusted on the fly also. Another way to do it without muting the sounds might be to create a 1s dead air mp3 file and play that to get the LED only. Another item we will have to play around with in a custom driver.
Do you have to change it between or set it at playback?
