Как ответить на намерение QUERY для устройств с действительно неизвестным состоянием (willReportState = false, commandOnly = true недостаточен)?

Проблема

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

Состояние неизвестно, потому что это фирменное освещение. Я могу посылать ему команды и кэшировать значения этих команд, но вначале у меня нет средств сообщить о существующем состоянии. Я очень хорошо понимаю, что могу кэшировать все исторические значения, которые я вижу в базе данных, и извлекать их, но это не останавливает управление оборудованием из другого места без моего ведома, поэтому я никогда по-настоящему не знаю состояние, за исключением того момента, когда я Выполняю команду 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()}
    }
};

person Adam Hill    schedule 10.02.2020    source источник


Ответы (2)


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

Кроме того, вместо того, чтобы отправлять "УСПЕХ" в ответе на запрос QUERY, вы можете отправить статус "ERROR" с " errorCode " чего-то вроде" notSupported ", что было бы более точным ответом.

person Nick Felker    schedule 10.02.2020
comment
Реализация ReportState является обязательной для публикации действия, несмотря на то, что оно не применяется. Использование кода ошибки notSupported - хорошая идея, я попробую это сделать. - person Adam Hill; 11.02.2020
comment
Если ваши устройства не могут сообщить о состоянии, вам должно быть предоставлено исключение. - person Nick Felker; 11.02.2020
comment
Ответ с ошибкой сработал, по-видимому, так же хорошо, по крайней мере, в том смысле, что нет никаких доказательств того, что что-то не так. К сожалению, мы натолкнулись на кирпичную стену с сертификатом. Несмотря на то, что willReportState=false - вещь, они сказали: Мы ... получили ваш ... отчет о тестировании, но все они имеют значение false. мы не можем проверить / разрешить, если для них не установлено значение true. Это необходимо для получения сертификата. Мы предлагаем реализовать трейты для света, упомянутого в этом документе. Документ - это просто документация по признакам. - person Adam Hill; 22.02.2020
comment
Признаки реализованы в том, что команды правильно управляют оборудованием, просто пропущены в наборе тестов. Я полагаю, что мой единственный путь вперед - попытаться обмануть процесс тестирования, заявив willreportState=true, а затем предоставив несколько поддельных и предполагаемых состояний, но это кажется очень плохой идеей для поощрения, учитывая весь смысл willReportState=false. Я связал их с этой страницей и предоставил подробную информацию о нашей ситуации, но это либо было проигнорировано, либо не понято. - person Adam Hill; 22.02.2020

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

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

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

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

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

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

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

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

person Adam Hill    schedule 28.02.2020