Stay command not recognized

[goruck]

The stay command is not longer recognized as being valid.

[goruck]

Can not reproduce. Could have been an Alexa side ASR issue.

[rogueturnip]

I might have something for you to look at.

Occasionally the panel will send out a 0x05 status message but the next octet contains a 93 or 1. If you log this and then the keypad data the other keypads respond to this. So if you happen to transmit at the same time as the other keypads are responding you won't get a successful message across. This happens for other button presses too.

On normal 0x05 messages the keypad just keeps sending FFFF so you can send key strokes fine. It appears that if the second octet can't be decoded then you have to pause on a send because you might have another keypad responding.

[goruck]

Hey, thanks for the info.

First of all, I am reopening the issue since I'm able to repro it 100% using Alexa on FireTV but not on Echo, Dot, or Tap. This seems to be an Alexa ASR issue that's unique to FireTV. I'll contact Amazon on this.

Now, regarding your excellent observation!

You are right about these commands from the panel for keypad queries and potential collisions with writes from ALL to the panel. In the V1 code I handled this in the panel_io thread, detecting that condition and reissuing the write. However, I found that the panel issued other keypad query commands as well which complicated the logic and made me nervous that I was missing other corner cases. However, I found that when the keypads respond to panel queries they do so with a very short message (< 20 bits). So in the V2 code I added the following in the panel_io thread to detect the condition and repeat the write:

if (bit_cnt < 20) {
  fprintf(stderr, "panel_io: bit count < 20 (%i)! Repeating panel writes and ignoring reads.\n", bit_cnt);
  } else {
    res = pushElement1(word, MAX_BITS); // store panel-> keypad data
    if (res != MAX_BITS) {
      fprintf(stderr, "panel_io: fifo write error\n"); // record error and continue
    }

    res = pushElement1(wordkr, MAX_BITS); // store keypad-> panel data
    if (res != MAX_BITS) {
      fprintf(stderr, "panel_io: fifo write error\n");
    }

    res = popElement2(wordkw, MAX_BITS); // get a keypad command to send to panel
    if (res != MAX_BITS) { // fifo is empty so output idle instead of repeating previous
      strncpy(wordkw, IDLE, MAX_BITS);
    }
}

This has proven very robust and I have not seen a case where ALL fails to write to the panel.

[rogueturnip]

Thanks for pointing that out. That is a nice clean simple way to handle it. The approach we were taking was to capture all the query type messages and respond as if we were a keypad. I have a couple of keypad configured and can disconnect them to find out if the response is slot dependent. For 0x11 it is but still decoding the other ones. Didn't expect to see query type message in the 0x05.

If you respond to the 0x11 message the slot you respond as starts showing up as a registered keypad in the other keypads when you do a *8 IC 903.

Hoping in the next couple of days to have some decoded messages passed across into nodejs and then AWS IoT into DynamoDB.

[goruck]

The root cause of this issue was that the Alexa ASR (automatic Speech Recognition) returned the case of the value inconsistently across Amazon Alexa enabled devices. Amazon has since corrected this defect and now Alexa ASR returns lower case values across its devices. However, Amazon offers no guarantee what the case will be, only that it will be consistent across devices. Therefore to be safe, the Lambda code now forces a conversion to lower case on all Alexa ASR returned values before the value is used.