Bug? Can't get an Output name?

[123]

PROBLEM
You can't get an Output's name unless its Show flag is enabled. Is this a bug?
(My M1 has firmware 4.4.12)

The lowercase "sd" command (Request ASCII String Text Descriptions (sd)) asks an ElkM1 to reply with the assigned name of a Zone, Area, Output, User, etc.

If a Zone or Area has a name, it will be returned via the uppercase "SD" message (Reply with ASCII String Text Descriptions (SD)) message. However, an Output's name will not be returned unless its Show flag is set. That does not make sense but it is what I've observed.

The Show flag determines if the name should be displayed on the keypad. Tasks, Lighting and Outputs all have Show flags. My testing shows that an activated Show flag prevents you from getting the item's name via "sd".

The documentation mentions the high-bit of the first character may be set if "Show on Keypad" is true. That's interesting except I can't test this character bit if the M1 returns nothing!



Here's how to easily reproduce the problem.

Pre-requisite: M1 with XEP Ethernet interface and a networked PC equipped with RP.


(1) Using RP, give Output 1 a name ("Speaker") but don't set the Show flag.

(2) Open the command prompt on your PC and run the following command:
telnet 192.168.0.251 2101
- Change the IP address to match whatever your XEP is using.
- Press the enter key and wait.
- In 30 seconds or less you should see an XK "heartbeat" command
something like 16XK04311370103080100076.

(3) Copy the following TWO LINES:
0Bsd040010062

- You need to copy the command string and the
hidden carriage-return line-feed of the second blank line.

(4) Right click on the telnet window and select Paste.
- The command string will be issued to the M1 and it will
respond with: "1BSD04000________________00A2"
That empty space you see (they'll be 16 blank spaces) should contain Output1's name.

 

[123]

This is a bad sign ... this issue hasn't seen a nibble here nor over on the Elk bulletin board.

So I'm the only Cocooner using Elk's ASCII Protocol ... how lonely is that!

Humour me, does the "sd" command work properly for anyone?

 

[electron]

I can confirm I am seeing the same thing. However, I don't think this is a bug. The output name is also used with the ElkRM software. If a user doesn't want the device to show up on his/her ElkRM based touchscreen, why should ElkRM bother learning the names of those outputs? I am sure that the sd command was designed with ElkRM in mind.

 

[Spanky]

You need to turn on the "Show" bit on the output configuration. Also, there can be no spaces in the beginning of the name.

 

[123]

You need to turn on the "Show" bit on the output configuration. Also, there can be no spaces in the beginning of the name.

Ugh! If that's the case, and from experience it is, then the documentation needs correction.

The documentation states the high-bit of the first character may be set if the Show flag is set. This is how it indicates if the name is visible or not. I like that technique because it communicates to me whether or not my program should display the returned name.

Except that's not how it works ... if the Show flag is off there's no possibility of "checking the first character" of the returned name because nothing is returned.

If I've completely misunderstood the purpose of the high-bit, then please let me know. There appears to be no need to test this bit because if you get a name back then you know it must be visible.


PS
For my Elk M1 device driver, I poll the M1 and acquire the names of all Areas, Zones, Outputs, Lights, Thermostats, etc. The driver's UI shows the actual name of the item as opposed to "Output_5", or "Light_23". Unfortunately, I can't acquire an item's name if its Show flag is off. Displaying an item's name in RM (or on a Keypad) and acquiring its name programmatically are mutually-exclusive activities. IMHO, the Show flag shouldn't control both of them.

 

[AnotherOne]

I just hard coded my output names in my protocol driver as there's a problem such then when you set the flag to enable output messages over serial port 0 and ethernet, it also sends output changes over serial port 1. And the output changes sent over serial port 1 confuse the hell out of the lighting control system attached to serial port 1 and it looses commands.

Not the best solution, but one I can certainly live with since I'm not producing a product. And I certainly don't want them to change anything that would send more commands over serial port 1. The only things I want going over serial port 1 are commands I explicitly send or want to receive.

 

[123]

...
when you set the flag to enable output messages over serial port 0 and ethernet, it also sends output changes over serial port 1.
...
I certainly don't want them to change anything that would send more commands over serial port 1.
...

By "flag" you're talking about one of the M1's setup options that causes it to broadcast its activities, yes?

The way I understand it, message traffic is generated regardless of the Show flag's state. If you issue 32 "sd" commands, asking for the names of Outputs 1-32, the M1 will respond 32 times. The only difference is that the reply packets will lack a name if the Output's Show flag is off ... but there will still be a reply.

My point is that if the M1 is replying in all cases, it might as well provide the Output's name ... and use the 1st character's high-bit to indicate if the Output is to be displayed or not (like the way it is described in the documentation).

PS
Referring to Section 4.15 in the ASCII Protocol manual, there's no size difference between a message packet that contains an Output name and one that omits the name. A "no name" packet contains 16 whitespace characters.

 

[AnotherOne]

By "flag" you're talking about one of the M1's setup options that causes it to broadcast its activities, yes?

Yes, G37 - Transmit Output Changes.