Доступ к облаку по API

[melky]

"sms_tag":"3ca1eed2efaa183d0f32fb68099ead8f",
"sms_code":"69353",

При записи данных, если требуется подтверждение по SMS это фиксированные данные для пользователя ?

[Евгений Кислов]

"sms_tag":"3ca1eed2efaa183d0f32fb68099ead8f",
"sms_code":"69353",

При записи данных, если требуется подтверждение по SMS это фиксированные данные для пользователя ?

Возможность подтверждения действий по SMS еще не поддержана.

[melky]

Вопрос в другом, sms_tag и sms_code будут являться постоянными для клиента или генерироваться каким-то образом и сперва необходимо будет сделать запрос на эти данные?
Просто предусматривать каким-то образом в командах или пока забить?

[Евгений Кислов]

Вопрос в другом, sms_tag и sms_code будут являться постоянными для клиента или генерироваться каким-то образом и сперва необходимо будет сделать запрос на эти данные?
Просто предусматривать каким-то образом в командах или пока забить?

Пока функционал не реализован - сложно сказать , какой будет реализация.

Я бы предположил, что sms_tag и sms_code будут уникальными.
Для получения sms_tag потребуется выполнять sms/status.
sms_code - это код подтверждения из полученной SMS.

[melky]

Хм, как все запущено что-то я логику тогда действия не пойму. Сперва мы должны отправить запрос на получение sms_tag и sms_code, а потом команду на изменение параметра, указав время жизни и синхронизацию и полученные sms_tag и sms_code ? Не слишком ли мудренно тогда?

А если так: Посылаем команду на изменение параметров без sms_tag и sms_code, а потом делаем запрос на получение sms_tag чтобы его отправить и дождаться sms_code и пока ждем время жизни тю-тю ?

Как-то все через пень колоду, используя авторизацию по API еще непонятно как накрутить сюда же SMS не находите?
Может подтверждение по SMS нужно только тогда, когда мы хотим изменить параметр послав команду через SMS на определенный номер пула и не пытаться это прилепить как-то к API ?

[Евгений Кислов]

Все ваши пожелания по API можете отправлять на owencloud@owen.ru

[melky]

Евгений Кислов да я как бы вообще не понимаю этого sms_tag и sms_code если мы работаем через API, потому что мы, посылая команду и так авторизовались, куда уж дальше то?. Другой вопрос, если это происходит с мобильного приложения с последующим ожиданием кода подтверждения по SMS или PUSH но опять же, как тут жить с временем жизни и тем, что и SMS и PUSH могут легко запаздывать?

[Евгений Кислов]

как тут жить

Уточните, что в конкретный данный момент вам мешает жить?

[melky]

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

Очень интересный момент обнаружился

{"sms_tag":null,"sms_code":null,"timeout":60,"sync ":true,"data":[{"id":5885208,"value":"0.5"}]}

- отправляемое значение в параметр ПЛК Котельная wStatus3 переводит его в 1, хотя я отправляю 0.5

А вот если отправить значение 10, то уже ошибка

Ответ получен за 205 мс. Статус: 500 (InternalServerError)
Содержимое ответа:
{"name":"Exception","message":"Некорректное значение для параметра #5885208.","code":0}

тут как-то логика ПЛК срабатывает или логика облака ?
И если послать сразу команду на два значения с ошибочным вводом, то в ответ мы получаем только Exeption по первому же параметру, а если ошибочный будет где-то в середине, не будет принят ни один параметр к записи ?

[Евгений Кислов]

тут как-то логика ПЛК срабатывает или логика облака ?

    {
      "id": 5885208,
      "code": "wStatus3",
      "format": 2,
      "dot_point": null,
      "min_val": null,
      "max_val": null,
      "is_writable": 1,
      "default": null,
      "hash": null,
      "index": -1,
      "address": "E",
      "function": 3,
      "modbus_format": 1,
      "register_byte_order": 1,
      "register_order": 1,
      "write_function": 16,
      "length_in_device": 0,
      "category_id": 849873,
      "can_operative": 1,
      "can_configuration": 1,
      "can_manageable": 1,
      "in_operative": 1,
      "in_configuration": 0,
      "in_manageable": 1,
      "in_parameters": 1,
      "in_tables": 1,
      "in_graphs": 1,
      "in_events": 1,
      "type": 0,
      "modbus_multiplier": "1.0000000",
      "precision": 0,
      "bitmask_enabled": 1,
      "bitmask_value": "4",
      "name": "Насос котла 1",
      "value": "0",
      "formatted_value": "0",
      "fault": "",
      "measurement": {
        "title": "",
        "name": "отсутствует",
        "default_precision": 3,
        "visible": 0
      },
      "value_descriptions": []
    },

Для типа BOOL (а при использовании битовой маски параметр обрабатывается как BOOL) возможны только значения 0 и 1.
И обратите внимание (на будущее) - разделителем целой и дробной части должна быть запятая, а не точка.

И если послать сразу команду на два значения с ошибочным вводом, то в ответ мы получаем только Exeption по первому же параметру, а если ошибочный будет где-то в середине, не будет принят ни один параметр к записи ?

Уточню у разработчиков и отвечу.