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

[melky]

Евгений Кислов спасибо. Пошел копать дальше...

[melky]

parameters - code я правильно понимаю, что code не уникальное свойство в рамках двух одинаковых приборов, а в рамках одного прибора он уникален или тоже их может быть два одинаковых ?

register_byte_order и register_order с учетом передачи по API уже конечного значения, например я решил записать значение в параметр, так ли мне нужно знать об этих параметрах, чтобы переставлять или я посылаю на запись скажем 10.25 а облако глядя на эти параметры само все переставит как надо?

dot_point - положение десятичной точки
min_val - минимальное значение
max_val - максимальное значение

В примерах не нашел по ним ничего, везде null - как должны выглядеть эти поля ?

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

1. В рамках прибора code тоже уникален.

2. При записи через API register_byte_order и register_order не должны обрабатываться, так как записываемое значение передается в строковом виде.

[melky]

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

modbus_format - формат в приборе (modbus) - повторяет параметр format ?

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

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

Да, вы понимаете правильно.

modbus_format - формат в приборе (modbus) - повторяет параметр format ?

Нет, modbus_format - это тип параметра Modbus. Возможные типы см. в описании device_format:

0 - float
1 - uint16
2 - int16
3 - uint32
4 - int32
5 - bool
6 - double
7 - int64
8 - uint64

А просто format - это тип параметра протокола ОВЕН.

dot_point - положение десятичной точки
min_val - минимальное значение
max_val - максимальное значение

В примерах не нашел по ним ничего, везде null - как должны выглядеть эти поля ?

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

Upd. - вот примеры по min_val и max_val, прибор СИ30:

"code": "LoCK",
"format": 2,
"dot_point": null,
"min_val": "0",
"max_val": "3",

10-11-2022 12-17-33.png

[capzap]

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

owen.png
если у Вас нет аккаунта в облаке, зачем Вам это всё? Задумали свой сервер создать, чтоб шлюзы на него стучались, так они по модбас работают плюсом коннект с парольной защитой. А API можно создавать и по упрощенной схеме для своего сервера

[melky]

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

Ну как бы эти поля позволяют контролировать значения посылаемых команд и выводить соответствующие сообщения "значение слишком велико, должно быть не более стольки то" и так далее

Вот говорю же, дубляж полный... Можно ведь было использовать одно поле format и в зависимости от типа протокола Овен, Modbus определять его... Там еще с десяток таких параметров наберется, которые либо дублирую друг друга по сути или которые можно было засунуть в битовую маску, типа in_configuration, in_manageable и так далее

[melky]

если у Вас нет аккаунта в облаке, зачем Вам это всё? Задумали свой сервер создать, чтоб шлюзы на него стучались, так они по модбас работают плюсом коннект с парольной защитой. А API можно создавать и по упрощенной схеме для своего сервера

capzap аккаунт я сегодня создал для тестирования чуть позже, пока ничего не прикрутил, есть ПЛК100 и возможно он с поддержкой облака или в принципе он прицепится, я пока не знаю. По поводу code параметра, ну в RapidScada они тоже есть для организации тегов в том числе и так же уникальны для одного устройства. Важно при подачи команды из web или через другие механизмы.
Так я и пытаюсь понять, какие из параметров мне будут нужны для организации тегов в Scada и как они работают.

Вообще затея была разобраться с json немного, с работой по API и было два пути, облако Овен и еще одно, начал просто с Овен
Учитывая, что Облако может являться OPC UA сервером, то данный драйвер мне лично как бы и не нужен если разобраться, тоже потом проверю.

[capzap]

в ответах от облака в общем случае всем нужна value и возможно name, остальные параметры ни кто не обрабатывает, Вы столько дней тратите в пустую а еще не продвинулись в справке дальше девайса, мозг не взорвет когда обнаружите что code может принимать и не только строковое значение

[melky]

capzap code передается в виде строки, мне этого достаточно, главное понимать, что он уникален в пределах устройства, что соответствует и Scada системе

Часть других параметров мне важна для формирования тегов в Scada, для отображения в логах и так далее.

Да, я пока продвинулся только до авторизации и чтения приборов, сейчас занимаюсь чтением параметров, а еще пилить и пилить - настройки, передачу команд и так далее....

Да, я не собираюсь заниматься авторизацией и добавлением приборов, подтверждением почты, сменой пароля и так далее. Меня интересует только все связанное с устройствами и параметрами, остальное дело администратора(пользователя) на web.