anyone tried the new t2 command?

[polarbear44]

have been waiting a while for the new firmware upgrade, specifically to make use of the HAI thermostat support.
Tonite I was experimenting with the new version, using the latest M1 protocol document.
So far I have been unable to get anything to succeed.

For kicks, I sent the following text command to the M1.

2At2012144278D000000000000000000000000000096 <cr><lf> which should set the outdoor temperature display on thermostat 1 to -5C

I expect to see a T2 response with an ackknowledgement, but so far

the sent message just goes out into space. The thermostat doesnt change in any way. no response from the M1 ever comes back.

Spanky, can you shed some light on what could be wrong with this command? Perhaps I have misinterpreted the description in the protocol manual.

Any suggestions would be greatly appreciated.

 

[polarbear44]

Just noticed something from the Elk protocol manual


2A – ELK Packet Length in ASCII hex, 42 length
t2 – ELK Command “t2†– PC to Omnistat command via M1.
D[36]… – 36 ASCII Hex bytes comprising 18 binary bytes of Omnistat data,
including Checksum.
“0†right padded.
RA – Start/Remote Address, Bit 7 = 1
DA – Data Length/Message Type
Data – 0 to 15 binary data bytes, converted to 0 to 30 ASCII Hex bytes
CKSUM – Omnistat 2 checksum is last byte of Omnistat 2 data before
padding.
00 – Future use
CC – ELK Checksum
CRLF

In my previous post, bit 7 is zero, but the manual entry for t2 says "Bit 7 = 1"
This could be the reason it is not working, but it is opposite to the HAI protocol. According to their manual, only thermostat responses have bit 7 set. Further, in the Elk manual for the T2 response, it says that bit7=0 which is again opposite to the HAI documented setting.

This indicates that the commands are more than simple wrappers around the omnistat protocol, or maybe a misprint.
I'll check some theories when I get a chance again

This is either a printing error, or an inconsistency

 

[hollisin]

Where do I get the "protocol manual"
Thanks JackI

Just noticed something from the Elk protocol manual


2A – ELK Packet Length in ASCII hex, 42 length
t2 – ELK Command “t2†– PC to Omnistat command via M1.
D[36]… – 36 ASCII Hex bytes comprising 18 binary bytes of Omnistat data,
including Checksum.
“0†right padded.
RA – Start/Remote Address, Bit 7 = 1
DA – Data Length/Message Type
Data – 0 to 15 binary data bytes, converted to 0 to 30 ASCII Hex bytes
CKSUM – Omnistat 2 checksum is last byte of Omnistat 2 data before
padding.
00 – Future use
CC – ELK Checksum
CRLF

In my previous post, bit 7 is zero, but the manual entry for t2 says "Bit 7 = 1"
This could be the reason it is not working, but it is opposite to the HAI protocol. According to their manual, only thermostat responses have bit 7 set. Further, in the Elk manual for the T2 response, it says that bit7=0 which is again opposite to the HAI documented setting.

This indicates that the commands are more than simple wrappers around the omnistat protocol, or maybe a misprint.
I'll check some theories when I get a chance again

This is either a printing error, or an inconsistency

 

[polarbear44]

the Elk protocol manual is available for download from elkproducts.com. The most recent version I saw was from Nov 2008. Site will have the latest version.

The HAI protocol manual is available from www.homeauto.com. it used to be available directly for download. Now it seems you need to register as a developer to get it. Just a formality, and no cost.

 

[polarbear44]

Just tried it with bit 7 set like the elk manual said
same result... nothing

maybe the checksum isnt the right kind. Manual just says to add the bytes. Even an error would be useful.

considering disconnecting it from the elk so i can talk to it directly.

 

[az1324]

Seems like your omnistat serial command is correct, although appears it would actually set the temp reading to -20.5 deg C.

 

[polarbear44]

You are right that the temperature setting was not correct. 27 hex = 39 Dec omni temp units = -20.5 C

I have tried several variations of other commands, and I cannot seem to get anything to happen. The Elk just quietly swallows the commands, and nothing at all happens. No responses. <sound of crickets>

Has anyone gotten any omnistat commands to work using the new firmware?

I cannot believe I have been waiting since October for this update. A bit of a letdown.

 

[123]

polarbear44,

I'm rooting for you. The Omnistat is on my wish list.

The problem may stem from a documentation error (I found a few in the past) and hopefully not a firmware glitch. Either way, this issue will eventually be seen by Spanky and be resolved.

To ensure that the problem lies with the M1, confirm you can control the Omnistat from a PC (using Hyperterminal) using the appropriate Omnistat serial command.

 

[polarbear44]

123 Thanks for the encouragement, and suggestions

I tried the command directly to the stat (an RC90) using realterm , and it worked just fine. The thermostat showed outside temperature of -20.5C and alternated between inside and outside temperatures about every 2 seconds.
I received an acknowledgement from the thermostat of 0x81 0x00, 0x81 (received OK)
So it looks like the M1 is the culprit. It either doesnt work properly, or I havent formatted the M1 command correctly.
It is entirely possible that my understanding of the command as documented in the M1 protocol manual is incorrect.

Perhaps they could add an example, as they do most of the other commands.

Interestingly, before the October release of Omnistat support in the serial module (but not in M1 until mid February), I was intending to use a "dual interface". According to the HAI omnistat manual, up to 4 rs232 connections can be be parallel connected. I split the serial line off the stat to 2 db9 connectors, with one going to the m1xsp, and the other going to COM1 on my computer.

Using realterm on the PC, I could see the responses from the stat to the M1. It looks like the M1 polls the stat for Group1 data every 5 seconds or so. I can't see the M1 request, because the xmit and rcv pins are parallelled with the serial port on the PC.

I tried sending the "set register" command in between M1 commands, but was never able to receive a response. As soon as I unplugged the M1XSP from the stat, commands worked fine.
I suspect that the command timing is critical because the stat does not buffer received data, and will not receive while processing a command. The interleaving of M1 commands and PC based commands would be very difficult to do consistently anyways, which is why I got excited when they announced support for it in the M1 command set.

Not only do I want to display outside temp on the stat, I also want to monitor when the furnace/AC is active, and capture the Total time active this week and last week. The "days until filter change" would also be useful to capture as well.


I sure hope Spanky will chime in here with the magic chant that makes it all work....

Thanks again

 

[dlamb]

polarbear44,

Your ELK ASCII command looks to be formatted correctly. Does your ELK-M1XSP have a firmware version of 70.0.2?

 

[polarbear44]

70.0.2 is installed

 

[Spanky]

You have to be running M1 Version 5.1.14 not 4.5.14.

As I dance around the campfire with magic beads.

 

[WayneW]

You have to be running M1 Version 5.1.14 not 4.5.14.

Is this the only difference between the 4.x and 5.x firmwares so far? Are there more changes coming to the protocol (like for music support) that will require 5.x?

Rev. 1.74 – 11/06/2008 – Added Omnistat 2 documentation, added SD commands 18 & 19, EE
command, CA command. VN version number. Version 5.1.12 or later

 

[Spanky]

Issue fixes are in both versions 4.5.x and 5.1.x. Major feature additions have to go into 5.1.14 or later due to space availability. The main difference between 4.x.x and 5.x.x is that 4.x.x supports the GE brand RF receiver and has 48 RF zones while the 5.x.x supports the Elk RF receiver for GE transmitters and has 144 RF zone capability. 5.1.x does not have to reproduce the GE control data bus to talk the the GE receiver thus saving a great deal of code space that is used for future enhancements. 5.1.x is loaded from the factory into the M1. Unless you already have the GE brand RF receiver, there is not much use to load the 4.5.x software into the M1.

 

[WayneW]

6. Added new ASCII commands “CA†and “CD†for future control of specific brands whole house audio using rules.

Are the CA/CD commands in the 4.5.x family or only in the 5.1.x family? The release notes imply they are in both versions.

Shouldn't the two versions have separate release notes to clarify what was done in what?