Unintended ExitDelay status

[otto76]

Hey, cannot figure out why system time to time is sending ExitDelay message, even its not expected

dsc/get/partition_msg {"partition":1,"code":"1","status":"Ready"}
dsc/get/partition_msg {"partition":1,"code":"8","status":"Exit delay"}

There is no specific pattern when it happens, either regular time gaps or specific actions done before, nor dedicated messages received. I have seen weird messages, like 0x10: "Keypad lockout"; time to time, but not directly related to Exit delay.

Any ideas why this message can be pushed

Running on mega 2560 pro mini with W5500 Chip based Ethernet (Voltage is stable and in workable range, the same for DSC interface)

The piece of code in loop:

  // Checks status per partition
    for (byte partition = 0; partition < dscPartitions; partition++) {

      // Skips processing if the partition is disabled or in installer programming
      if (dsc.disabled[partition]) continue;
    
      // Publishes the partition status message
      publishStatusMessage(mqttPartitionMessageTopic, partition);        
   }

And message publisher:

void publishStatusMessage(const char* sourceTopic, byte partition, boolean retained = true) {
  byte currentDSCStatus = dsc.status[partition];  
  if ( currentDSCStatus == dscStatusMsg) 
    return;

  const size_t capacity = JSON_OBJECT_SIZE(3) + 80;   
  char buffer[capacity];        

  StaticJsonDocument<capacity> doc;
  doc["partition"] = partition +1;
  doc["code"] = String(currentDSCStatus, HEX);
  
 // Publishes the current partition message
   switch (currentDSCStatus) {
    case 0x01: doc["status"] = "Ready"; break;
    case 0x02: doc["status"] = "Stay zones open"; break;
    case 0x03: doc["status"] = "Zones open"; break;
    case 0x04: doc["status"] = "Armed stay"; break;
    case 0x05: doc["status"] = "Armed away"; break;
    case 0x07: doc["status"] = "Failed to arm"; break;
    case 0x08: doc["status"] = "Exit delay"; break;
    case 0x09: doc["status"] = "No entry delay"; break;
    ...
    default: return;
  };

  size_t n = serializeJson(doc, buffer);

  mqttClient.publish(sourceTopic,  (byte*)buffer, n, retained);    
  doc.clear();
}

[taligentx]

How does the output of the KeybusReader sketch look? Any garbled data or CRC errors? There shouldn't be spurious messages, if you're seeing things like 0x10: "Keypad lockout" without activity from keypads, I'd suspect a wiring issue or component fault.

[Dilbert66]

I've seen that type of issue with 05 commands that lose a bit possibly due to a bad connection or noisy line. That changes the message quite a bit and can give you all kinds of odd statuses. Unfortunately the 05/1b commands don't have a CRC checksum to validate a good command, this is tricky to filter out. A solution I'm testing is to always wait for 2 identical commands before accepting it as valid. This works with the 05/1b since they are constantly being sent.