Aeotec zWave Doorbell

[Broyd]

Audacity is a good free one. You'll have to also get the LAME files to do mp3 files, but it isn't hard.

http://www.audacityteam.org/

Thanks Dan,

 

Audacity is the BEST choice here. It will let you work with an existing .mp3 file or record a new one.

Opening the file with audacity causes Audacity to analyze the internal characteristics of the .mp3 file such as mono/stereo, bit rate etc. AND THEN generate a length of silence at the cursor position in any length in increments of milliseconds.  

[robl]

Thanks everyone for the great feedback and help. Audacity is what I was looking for, and has been a great help in creating custom messages for the doorbell.

 

As many of you pointed out, the latencies involved in calling zwave devices are unpredictable. So my thought of adding an average 0.2 secs latency per hop didn't turn out well. It seems every 2nd or 3rd run, one of the speakers takes 5-10 seconds to play the sound and for ISY to return. And in 10% of the cases, it takes a long time and nothing happens. One possible path forward is to get more of these devices and hope that it extends the z-wave network, improving performance.

 

ISY conditionals really give me fits sometimes. I wanted to set variables associated with the sound#, volume, and speaker. And to skip setting volumes if it is -1. And to do all speakers if speaker=0 or all but "that" speaker if speaker is a negative number.

 

I got it working with a nested chain of ISY programs .... but latency went through the roof .... I could open the garage door, trigger the program start, go in get something, come back, sit down, and then I'd hear the sound. Not happy.

 

So instead I put the complex logic in my rPi, and call the rPi with the 3 parameters. Overhead is very small, and I found it very enlightening to see the times returned around each GET call to ISY. Here's my log in case it helps anyone else trying to do this understand what's happening under the hood. Latency is vastly improved this route when volume=-1. I had also thought to fork off the GET calls to ISY, but I'm unsure if it's threaded, or if it will simply block or get confused since it just has 1 zwave antennae.

 

I suppose ideally I'd have 5 zwave transmitters and could get them all going in parallel, but then they use the same frequency and would likely blot out each other.

 

Anyway, thanks for all the help. Interesting times!

 

----

 

 

Remote: running cmd 'sendsound' with arg1='1', arg2='-5', arg3='10'
Check volume of speaker 'kitchen' (ZW023_1) returned '10' in 0.1 seconds.
Check volume of speaker 'master' (ZW024_1) returned '5' in 0.2 seconds.
Change volume of speaker 'master' (ZW024_1) to 10 took 0.2 seconds.
Check volume of speaker 'girls' (ZW025_1) returned '10' in 0.2 seconds.
Check volume of speaker 'basement' (ZW026_1) returned '10' in 0.4 seconds.
Checking and changing all volumes took 1.1 seconds.
Sent sound '1' to speaker 'kitchen' (ZW023_1) in 0.2 seconds.
Sent sound '1' to speaker 'master' (ZW024_1) in 0.3 seconds.
Sent sound '1' to speaker 'girls' (ZW025_1) in 5.1 seconds.
Sent sound '1' to speaker 'basement' (ZW026_1) in 0.7 seconds.
note: this is the most important duration - set volumes and play all finished in 7.5 seconds.
Delaying 2 seconds to be sure full message has played.
Reset volume of speaker 'master' (ZW024_1) to 5 took 0.1 seconds.
Resetting all volumes took 0.1 seconds.
note: it took 8.5 seconds to call all speaker sound urls.

[robl]

As noted before, with 4 doorbells, and the desire to send them all the same signal, I was curious about trying it in parallel vs. serial.

 

Results are good! Having ISY ping my rPi to launch the action, then rPi to fork off 4 children to REST back to ISY was ~ 2x faster than the rPi send the signals one at a time. As hoped, it looks like the ISY allows other zWave actions to occur when waiting for one of it's commands. It also highlighted a lot of variability ... sometimes a speaker would go off in 0.3 seconds. (great!) Other times it could take up to 7 seconds. (terrible!) Has anyone tried to optimize variability in zWave networks? I may try to get another speaker and place it 6 feet from the ISY to let the zWave network extend through it.

 

Btw, responsiveness for the speaker programs on ISY went to heck once I tried to add a bunch of features:

 

- Set variable to the sound you want played

- Set variable to the speaker you want (1-4) or 0 for all or (-1 to -4) to skip all but that speaker. [optional]

- Set variable to volume if you want to crank it up for this message. [very slow, and optional]

 

This required a bunch of cascading programs in ISY and pretty soon my speakers were taking > 10 seconds to fire, even if zWave was getting it out in 0.3 seconds. My wife would walk into the garage, triggering the open door message, do her stuff, come back into the house, go into the kitchen to do something and then we'd hear "garage door opened". Not good.

 

So ... second pass of setting these 3 variables and then calling a single network command (that used the variables in the GET path ala REST) to the rPi worked much, much better. There is a slight latency jumping to the rPi, but it seems the ISY is seriously performance impaired for all sorts of things. (like counting # windows open or doing complex programs) I wish ISY ran it all on a rPi with a more open platform ....

 

Anyway, if any of you are using multiple doorbells for messages, using an rPi to trigger them all in parallel seems to work great!