My Christmas wishlist

[tmbrown97]

I like the other suggestions, but I absolutely want the computer sound interface above all else. I don't care how it's done, I don't care if it is a bolt on, I don't care how much it costs, I don't care if I have to replace my whole Elk M1G to get it, I don't even care if it is made of green eggs and ham...

I WILL BUY IT.!!!!

Well, for now there's always the workaround a few of us are looking at. I should get the parts in this week to finish up - I'm using an Elk124 8-channel recordable module hooked to 8 of the voltage lead outputs off the main panel, and running this into the same speakers that the elk is hooked to (using the capacitors, etc) - so they can both be hooked up at the same time. Now, this only gets me 8 custom sounds, but that should be plenty for what I really need (doorbell, phone ringing, and a few custom door opening chimes). Does that count under the "bolt on" category?

 

[Spanky]

Great input! All your inputs are well taken and we are working to cramp your wishes in.

Lots of new things are in the works!

 

[Lagerhead]

I promise you will never, ever, ever cram all the words people want in there and all you are doing is taking up valuable ROM space.

Agreed. But the fact that the M1G has a speaking function at all sort-of begs the question. Consider that few of us will ever use *all* of the words in the vocabulary, so, maybe make individual words replaceable from ElkRP. As one possible solution.

I think there will always be ELK installers/customers who prefer to perform automation functions using an M1 exclusively.

Exactly. The M1 is reliable and robust; it makes sense to use it extensively.

 

[Spanky]

How about downloading your own .wav files into speech memory?

Spunky, my new name! I like it!

 

[Lagerhead]

How about downloading your own .wav files into speech memory?

Great! But can we have the "Elk Girl" speak the new words?

Spunky, my new name! I like it!

Sorry about that.

Dave

 

[tmbrown97]

Great! But can we have the "Elk Girl" speak the new words?

Yeah - there's no way I'm recording those in my own voice ... I'd have to play with the newest Text To Speach programs to see about getting good clean recordings to .wav files... but yeah, ultimately, the ability to program our own would be ideal. Spanky - is that something that could be added via firmware, or would that require an upgraded panel?

 

[comet48]

How about
1. greater than or equal to
2. less than or equal to
3. a+b, a-b where a and b are variables
4. ELSE
5. THEN DELAY xxxxx

Ron

 

[Spanky]

The new text to speech engines for the PC are really good with male or female voices.

As we move forward...

It would make sense to have all the voices messages in .wav files made from a text to speech engine. Anyone could then make new voices by using the same text to speech engine and sending the .wav file down to the embedded control.

Other options could be for the control to send out command strings to a PC or server running a text to speech program. The PC would build and say the speech message according to a lookup table. The phrases could easily be edited in the PC.

Additional Rule capability is definitely on the list.
An ELSE statement in Rules has been discussed many times, but one needs to understand how the Rules Engine works. A Rule is only fired when an event happens or something changes. The M1 does not constantly evaluate the Rules list. When a door is opened, a message is sent to the Rules engine to then evalute if a Rule contains the door opening event. Therefore, since the M1 does not constantly evaluate the Rules list, an ELSE statement is not achievable. An ELSE statement could be added after the AND statements in the case of the AND statements failing.
ie:
Whenever A Minute passes
And it is Dark Outside
Then Turn on a light
ELSE
Then Turn off a light

As daddy's eye glimmers!!!!

 

[comet48]

That's exactly how I'd like to use the ELSE.

I've had the Elk installed for a couple of months, and want to congratulate you guys on both a great product and absolutely terrific support.

The one area, apart from rules expansion, I'd love to see a change is in the HVAC support. Currently, everything is based upon an interface to installed thermostats. This has some real negatives - lots of extra wiring, and lots of extra cost. Just a few thermostats and you've spent as much as the Elk. How about an RS485 connection directly to a HVAC controller, and support for virtual thermostats - then we can use just the Elk M1 connected to the HVAC controller, Elk temp sensors and ElkRM or other Home automation sofrware.

 

[euphline]

Other options could be for the control to send out command strings to a PC or server running a text to speech program. The PC would build and say the speech message according to a lookup table. The phrases could easily be edited in the PC.

Doing this by HTTP would be consistent with how many IVR applications work.

-jbn

 

[bwally]

i think the most important change for now is the ability to change the port number in the M1XEP to something other than 80

internet access has become just too important and

1) too many weaker or less important devices/services hog port 80
2) too many service providers are blocking port 80
3) it will make the device basically future proof

a good example of #1 is the original release of WHS did not allow changing the port from 80 either (fixed now due to consumer demand).

 

[upstatemike]

The new text to speech engines for the PC are really good with male or female voices.

As we move forward...

It would make sense to have all the voices messages in .wav files made from a text to speech engine. Anyone could then make new voices by using the same text to speech engine and sending the .wav file down to the embedded control.

Other options could be for the control to send out command strings to a PC or server running a text to speech program. The PC would build and say the speech message according to a lookup table. The phrases could easily be edited in the PC.

Additional Rule capability is definitely on the list.
An ELSE statement in Rules has been discussed many times, but one needs to understand how the Rules Engine works. A Rule is only fired when an event happens or something changes. The M1 does not constantly evaluate the Rules list. When a door is opened, a message is sent to the Rules engine to then evalute if a Rule contains the door opening event. Therefore, since the M1 does not constantly evaluate the Rules list, an ELSE statement is not achievable. An ELSE statement could be added after the AND statements in the case of the AND statements failing.
ie:
Whenever A Minute passes
And it is Dark Outside
Then Turn on a light
ELSE
Then Turn off a light

As daddy's eye glimmers!!!!

The problem with using WAV files is that it is still hard to speak variable values. It seems to me it would be much easier to use ASCII out strings to a PC that is running a utility like ZSpeak to speak a phrase in real time. Then all you need to do on the M1 side is have a methed to embed variable values in the string such as: ASCII OUT "The kitchen temperature is $tstat1temp degrees and the setpoint is $tstat1set degrees". When sending the text string the M1 would simply have to substitute the actual value of the $ variables in the string and the PC can speak the phrase in the chosen computer voice.

There would need to be something running on the PC side to accept the string and kick off the ZSpeak TTS engine or whatever is used but this is actually an advantage because once in place the same mechanism could be used to kick off batch files, play wave files, etc. based on trigger characters in the ASCII string.

With respect to else, one approach might be to provide nested If-Thens and only have else available at nested levels as in:

WHENEVER A minute passes
..THEN IF it is Dark Outside
..OR it is after 8:00 PM
..OR it is before 6:00 AM
....THEN Turn on a light
....ELSE Turn off the light

 

[Photon]

The next option I'd like to buy for my M1G is an expanded owner's manual. I'm not aware of any such thing, though, and I think someone is missing out on sales by not putting one together. This need not be written to the "Elk for Dummies" level nor should it be targeted to the professional security platform installer, but rather should be aimed at people who are competent with PCs and similar electronic toys but have little or no security system experience. Actually, I'd probably buy a manual intended for either of the above if it was written by someone who both knows how to write and knows the system.

Were it not for Spanky, Martin, BraveSirRobbin, and, of course Dan (Electron), not to mention a host of others who selflessly patrol this board and share with us the benefit of their expertise and years of experience, I rather doubt I'd have settled on a system so sophisticated as the Elk.

Now would one (or more) of you please fire up your word processor and prepare to publish! It would be so nice to have the tips, tricks, and techniques all in one place. Lets put the emphasis on Elk's rules engine. Maybe I'd find all the answers at an AO class, but that solution isn't an option at the moment. I wanna buy the book!

Regards. . . . John

 

[comet48]

One more thing for Xmas - how about support the ACK on the upb protocol. i.e. If a command to a UPB switch does not work, resend it! It's part of the protocol, but you don't implement it.

 

[cliffs]

This has been asked for in the past. Add a OR command to Whenever in the rules,
of course both of the OR inputs would have to be a trigger event.

This would in many cases lighten the load on the processor and eliminate duplicating
rules for different inputs. This should be easy to do and not require any major rewriting
of the code.

Cliff s