"sms_tag":"3ca1eed2efaa183d0f32fb68099ead8f",
"sms_code":"69353",
При записи данных, если требуется подтверждение по SMS это фиксированные данные для пользователя ?
Вид для печати
"sms_tag":"3ca1eed2efaa183d0f32fb68099ead8f",
"sms_code":"69353",
При записи данных, если требуется подтверждение по SMS это фиксированные данные для пользователя ?
Возможность подтверждения действий по SMS еще не поддержана.Цитата:
Сообщение от melky
Вопрос в другом, sms_tag и sms_code будут являться постоянными для клиента или генерироваться каким-то образом и сперва необходимо будет сделать запрос на эти данные?
Просто предусматривать каким-то образом в командах или пока забить?
Пока функционал не реализован - сложно сказать , какой будет реализация.Цитата:
Сообщение от melky
Я бы предположил, что sms_tag и sms_code будут уникальными.
Для получения sms_tag потребуется выполнять sms/status.
sms_code - это код подтверждения из полученной SMS.
Хм, как все запущено :) что-то я логику тогда действия не пойму. Сперва мы должны отправить запрос на получение 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
Евгений Кислов да я как бы вообще не понимаю этого sms_tag и sms_code если мы работаем через API, потому что мы, посылая команду и так авторизовались, куда уж дальше то?. Другой вопрос, если это происходит с мобильного приложения с последующим ожиданием кода подтверждения по SMS или PUSH но опять же, как тут жить с временем жизни и тем, что и SMS и PUSH могут легко запаздывать?
Уточните, что в конкретный данный момент вам мешает жить?Цитата:
как тут жить
Евгений Кислов особо пока ничего, хотел получить понимание для этих параметров, насколько они нужны, нужно ли их вообще добавлять в команду и как это потом разруливать.
Очень интересный момент обнаружился
- отправляемое значение в параметр ПЛК Котельная wStatus3 переводит его в 1, хотя я отправляю 0.5Цитата:
{"sms_tag":null,"sms_code":null,"timeout":60,"sync ":true,"data":[{"id":5885208,"value":"0.5"}]}
А вот если отправить значение 10, то уже ошибка
тут как-то логика ПЛК срабатывает или логика облака ?Цитата:
Ответ получен за 205 мс. Статус: 500 (InternalServerError)
Содержимое ответа:
{"name":"Exception","message":"Некорректное значение для параметра #5885208.","code":0}
И если послать сразу команду на два значения с ошибочным вводом, то в ответ мы получаем только Exeption по первому же параметру, а если ошибочный будет где-то в середине, не будет принят ни один параметр к записи ?
Цитата:
тут как-то логика ПЛК срабатывает или логика облака ?
Для типа BOOL (а при использовании битовой маски параметр обрабатывается как BOOL) возможны только значения 0 и 1.Код:{
"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": []
},
И обратите внимание (на будущее) - разделителем целой и дробной части должна быть запятая, а не точка.
Уточню у разработчиков и отвечу.Цитата:
И если послать сразу команду на два значения с ошибочным вводом, то в ответ мы получаем только Exeption по первому же параметру, а если ошибочный будет где-то в середине, не будет принят ни один параметр к записи ?