My Elk M1g isnt talking

dBeau

Active Member
I've been playing with sending commands to my elk via the tcp connection. It's all working great and does what I'd expect. Except for one thing. If I issue an "sw" command, the word is never spoken. It doesnt matter which word I request. I've tried quite a few including the one in the example from the serial protocol document. Oddly, the "sp" command works just fine. Enough works that I am sure I know how to talk to the device, compute checksums, etc. I am wondering now if there is a misconfiguration somewhere else, or if speaking a word is not as simple as just sending a single "sp" command.
 
I'm sure you checked this already, but the Elk can speak on normal events (arming, etc...). I.E. the chime/volume/etc... settings are correct.
 
I'm sure you checked this already, but the Elk can speak on normal events (arming, etc...). I.E. the chime/volume/etc... settings are correct.

That's what's confusing to me. It does speak all of it's usual stuff just fine. Even the "speak phrase (sp)" command works as expected. The only problem I am seeing is that "speak word (sp)" doesnt. It makes me think I've done something wrong at the protocol level.

So while I was typing the above I was tossing a few more commands at it. Had I tried to speak more than just one word, I would have noticed the problem right off (and to think I've picked this up and dropped it a couple of time over the past month). The problem turned out to be that the first part of the first word gets cut out. Adding a bit of silence to the start fixes it all.

When just sending word 123 (cooling) it would say nothing. But sending it twice, most of the time I would hear "ling cooling". Some times I would only hear "cooling" and other times I would hear "cooling cooling". There seems to be a timing problem in the firmware. But it's easy enough to work around.

I guess I should have posted my question sooner :)
 
I'm sure you checked this already, but the Elk can speak on normal events (arming, etc...). I.E. the chime/volume/etc... settings are correct.

That's what's confusing to me. It does speak all of it's usual stuff just fine. Even the "speak phrase (sp)" command works as expected. The only problem I am seeing is that "speak word (sp)" doesnt. It makes me think I've done something wrong at the protocol level.

So while I was typing the above I was tossing a few more commands at it. Had I tried to speak more than just one word, I would have noticed the problem right off (and to think I've picked this up and dropped it a couple of time over the past month). The problem turned out to be that the first part of the first word gets cut out. Adding a bit of silence to the start fixes it all.

When just sending word 123 (cooling) it would say nothing. But sending it twice, most of the time I would hear "ling cooling". Some times I would only hear "cooling" and other times I would hear "cooling cooling". There seems to be a timing problem in the firmware. But it's easy enough to work around.

I guess I should have posted my question sooner :)

There was a bug in the SpeakWord command in older firmware. It is reported to be fixed in the latest...

http://www.charmedquark.com/vb_forum/showp...mp;postcount=23
 
To eliminate fully the possibility of bad or mistyped checksums, you can use the M1SDK application for testing. I tkink you have to email Elk to get it. It computes checksums and on your command will send the final string to the M1.

There is also a simple checksum calculator exe availalable on the Elk website, but it does not connect to the M1.
 
I upgraded my firmware... yada yada yada, the smoke detectors started screaming and the garage doors opened.

Talk about an exciting firmware upgrade! I dont know what I was thinking when I was thinking that it would all go smoothly. I mean, what could go wrong? For a hint, I'll offer that I dont usually think about what happens when the elk powers up. It will now become part of my testing.

After the upgrade, I went to test the "speak word" command. As soon as the audio started (without missing the initial bit, btw) the smokes went off. A while back I set up one of my outputs to trigger the smokes. It just happened to be output 10. With the older firmware this wasnt a problem. At some point, outputs 9 and 10 got owned by the listen-in interface. Apparently output 10 now triggers when the audio kicks in. I am thinking I should have read the release notes more closely.

I havent figured out the garage doors yet. I have a rule for each door that triggers an output when the door's Homelink receiver gets the signal. The rule is a "when zone becomes not secure" type. It seems to get triggered at start-up. The funny thing is that I have the doors configured to pay attention to a two-position toggle... "up" to request door up, "down" to request door down. So at power up, the door opened because the zone has become not secure (request up), but a couple of seconds later the elk notices that the zone is secure (request down) and the door closes. All of this means that should I ever need access to my garage, all I have to do is cut power to the house, wait 12 hours for the elk batteries to die and then restore power. I'll have a 10 second window of open access to the garage... hmmm... Anyway, I disabled one of the door's homelink rules and restarted the elk. This time, only one door went up. But... 10 seconds later, when the elk got around to checking the zones, the closed door opened and the open door closed.

I may have just hi-jacked my own thread. Who do I apologize to?
 
Back
Top