Как ответить на запрос QUERY для устройств с действительно неизвестным состоянием (willReportState = false, commandOnly ... = true недостаточно)? - PullRequest
0 голосов
/ 10 февраля 2020

Проблема

В документации не указано, как реагировать на запрос QUERY, если вы действительно не знаете состояния данного устройства. Несмотря на то, что я говорю, что willReportState является ложным для каждого устройства и включает в себя различные атрибуты commandOnly в ответе SYN C, тем не менее мне отправляется запрос QUERY. Та же проблема относится и к использованию вызовов ReportState, инициируемых запросом SYN C или QUERY.

Состояние неизвестно, так как это собственное освещение. Я могу отправлять ему команды и кэшировать значения этих команд, но вначале у меня нет средств сообщить о существующем состоянии. Я очень хорошо знаю, что могу кэшировать все исторические значения c, которые я вижу в базе данных, и извлекать их, но это не мешает управлению оборудованием из других источников без моего ведома, поэтому я никогда не узнаю по-настоящему состояние, кроме как в тот момент, когда я выполняю команду EXECUTE (о которой я затем сообщаю соответственно).

Это очень похоже на этот вопрос ( Главная страница Google - Обязательно ли состояние отчета? ), но в моем случай, когда я действительно не знаю / не могу знать состояние, поэтому любая реализация, которую я предоставляю, предоставляя состояние, является предположением / хаком.

Ответ на старый запрос

{
    "requestId": "SomeMatchingRequestId",
    "payload": {
        "devices": [{
            "id": "SomeValidDeviceId",
            "online": true,
            "status": "SUCCESS"
        }]
    }
 }

Немного улучшен, но неоптимален Ответ

Кажется, что следующее удовлетворяет запрос. Проблема заключается не только в том, что эти значения могут быть неверными в реальной жизни, после нескольких команд они также могут противоречить тому, что есть в пользовательском интерфейсе.

{
    "requestId": "SomeMatchingRequestId",
    "payload": {
        "devices": [{
            "id": "SomeValidDeviceId",
            "online": true,
            "on": 0, /* Adding a default value */
            "brightness": 0, /* Adding a default value */
            "color": { "spectrumRGB": 0 }, /* Adding a default value */
            "status": "SUCCESS"
        }]
    }
}

Устройство как сообщается

Обратите внимание на атрибуты, один из которых недокументирован, но я добавил их на основе шаблона именования.

var device = new SyncResponseDevice
{
    Id = deviceName,
    Type = Types.Light.ToString(),
    Traits = new List<string>
    {
        Traits.Brightness,
        Traits.ColorSetting,
        Traits.OnOff,
    },
    Name = new SyncResponseDeviceName { Name = zoneName },
    WillReportState = false,
    Attributes = new Dictionary<string, object>
    {
        {"commandOnlyBrightness", true},
        {"commandOnlyOnOff", true},
        {"commandOnlyColorSetting", true},
        {"colorModel", colorModel.ToString().ToLower()}
    }
};

Ответы [ 2 ]

1 голос
/ 10 февраля 2020

Если вы заявляете, что поддерживаете только команды, но по-прежнему отправляете данные о состоянии, это может привести к странному состоянию, при котором вы все равно должны знать это состояние в любое время. Если вы постоянно не знаете, может быть лучше никогда не отправлять данные о состоянии.

Кроме того, вместо того, чтобы отправлять «УСПЕХ» в вашем ответе на QUERY, вы можете отправить статус «ОШИБКА» с «errorCode» чего-то вроде «notSupported», что было бы более точным ответом.

0 голосов
/ 28 февраля 2020

Мы были опубликованы / сертифицированы. К сожалению, этот процесс противоречил тому, что предложил Ник. Я подозреваю, что ответ Ника является лучшим для реализации, но чтобы получить сертификат, вот что мы должны были сделать ...

  1. Каждое устройство ДОЛЖНО быть помечено как willReportState=true в тесты Test Suite, даже если вы не можете сообщить о подлинном состоянии, в противном случае оно будет отклонено.

  2. ReportState ДОЛЖНО быть реализовано в отношении конкретного ответа на EXECUTE запросы , В нашем случае мы могли бы реализовать это, поскольку вы запускаете асинхронный вызов ReportState с точно таким же состоянием, которое указано в команде. В реальной жизни возможно, что состояние могло измениться независимо, но выполнение вышеизложенного удовлетворяет тестам.

  3. Из того, что я могу сказать, нет необходимости реализовывать ReportState в ответ на QUERY и SYNC звонки для того, чтобы пройти сертификацию, хотя, вероятно, рекомендуется, если вы можете. В нашем случае мы вынуждены отвечать с поддельным состоянием / состоянием по умолчанию.

  4. Вы можете отвечать на QUERY и SYNC ответом либо с ошибкой, предложенной Ником. или поддельное / состояние по умолчанию. Либо «работайте», но у конечных пользователей не будет видимых побочных эффектов, но, вероятно, лучше всего использовать подход Ника.

  5. Упоминание о том, что Ник предложил предоставить исключение, будет проигнорировано. : (

  6. Удачи вам в прохождении тестов в Test Suite даже при безупречной реализации. Он основан на искусственном голосе, исходящем из ваших динамиков, который правильно интерпретируется устройством Google Home. Возможно, это связано с тем, что моим устройством является UK Engli sh против США. У меня было около 90% успеха для этого, но там, где у меня было около 20 тестов для запуска, это означало, что пакет был неудачным снова и снова. Это заняло больше часа повторения тестов для его прохождения. Я использовал громкоговорители монитора студийного уровня на громкой громкости рядом с устройством Google Home, и это, похоже, не помогло. У меня были такие вещи, как «Установить яркость {устройство} на 75%» быть выбранным как «Вы хотите, чтобы я установил устройство, это правильно?». Хорошее горе. Почему этот тест включает в себя любой звук, который смущает меня. Почему бы просто не отправить сообщение обработчику команд напрямую? В любом случае, удачи!

Я надеюсь, что, подняв это как проблему, команда Google Home рассмотрит описанную выше ситуацию и, в свою очередь, Процесс сертификации тоже обновлен. В этот момент этот ответ, надеюсь, станет излишним.

...