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

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

Ну индексы я добавлю, не проблема. А почему пустые массивы переменных? просто прибор ни разу не опрашивался?

Да, этот прибор ни разу не опрашивался.

[melky]

А можно в Демо добавить реальный прибор с опросом? А то тут из-за того, что он Овен часть переменных null и пришлось правки в код вносить, так как в Modbus они далеко не null...

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

А можно в Демо добавить реальный прибор с опросом? А то тут из-за того, что он Овен часть переменных null и пришлось правки в код вносить, так как в Modbus они далеко не null...

Любой прибор с протоколом ОВЕН или какой-то конкретный?

[melky]

Да любой в принципе, тот же 8А подойдет, сейчас вот код чуть изменил, а он пропал из Демо
Если правильно понимаю, прибор с протоколом Овен можно подключить в облако только при помощи шлюзов, которых у меня нет. Так что тренироваться придется на "кошечках" потом, типа на пользователях. А так хоть основу сделаю...

А ПЛК100 если ему включить в конфигурации протокол Овен по ТСР будет работать с облаком?

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

Да любой в принципе, тот же 8А подойдет, сейчас вот код чуть изменил, а он пропал из Демо

Ок, я передам ваше пожелание коллегам.

А ПЛК100 если ему включить в конфигурации протокол Овен по ТСР будет работать с облаком?

Нет, ПЛК1xx работают с облаком только по Modbus.

[melky]

Вот очередное недоумение. Если параметры котлов у прибора Котельная (ПЛК160_1.2.2) не записываются через облако, так понимаю, что фактически это передача данных со стороны ПЛК в облако. То почему у всех параметров стоит признак is_writable = true ?

Типа не верь глазам своим? и надо еще какой-то параметр сложить с этим, чтобы точно узнать, можно переменную менять или нельзя?

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

Если параметры котлов у прибора Котельная (ПЛК160_1.2.2) не записываются через облако

Записываются - попробуйте, например, параметр Давление подачи изменить.
Именно поэтому они отображаются на вкладке Запись параметров и поэтому у них is_writable = true.

[melky]

Вот именно Давление подачи через WEB и пробовал, как было 1.54 так и меняет опять на 1.54
Сейчас еще раз попробовал, да, запись проходит, потом меняется на 1.54

Значение сбрасывается на то, что видимо отправляет ПЛК. Получается, чтобы убедиться, что запись прошла мне надо период опроса в 0 выставить вместо моих 2-х минут, и то, отловить смогу только визуально.
Ладно, на других переменных потренируюсь, которые не сбрасываются в значение из ПЛК

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

Вот именно Давление подачи через WEB и пробовал, как было 1.54 так и меняет опять на 1.54
Сейчас еще раз попробовал, да, запись проходит, потом меняется на 1.54

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

[melky]

Да, я понимаю, что облако тут не при чем. Это нормально для любого ПЛК, если так написана программа. Просто думал, раз переменные для записи true, то их можно менять и они будут сохранять свои значения.
Фактически на запрос 120 с чем-то переменных у меня уходит чуть менее 2-х секунд, с учетом чтения всех девайсов device/index и скопом всех переменных через их id - last-data + время на обработку всех переменных.

Но запись в БД выставлена раз в минуту, по этому отследить изменение переменной можно только визуально по текущим данным

2022-11-17 14:12:00 Сеанс связи с устройством [5] OwenCloud
Отправка запроса:
https://api.owencloud.ru/v1/device/index
Ответ получен за 373 мс. Статус: 200 (OK)
Содержимое ответа:
[{"id":171772,"name":"Котельная (ПЛК160_1.2.2)","identifier":"E4:1E:0A:00:0D:FA"," type":"ПЛК через M
...
Отправка запроса:
https://api.owencloud.ru/v1/parameters/last-data
Ответ получен за 832 мс. Статус: 200 (OK)
Содержимое ответа:
[{"id":5885193,"values":[{"d":1668683517,"v":"1","e":"","f":"1"}]},{"id":5885178,"values":[{"d":1668
...
Получено за 1824 мс

В идеале, как выше писал, иметь возможность считывать все через last-data но с видом запроса {"device_ids" : [ id1, id2]} и ответ сделать примерно как у last-data но включить в него id устройства, и настраиваемые поля из устройства, типа (is_online, is_alarm) маской и строковой вид более расширенный. Сейчас online, offline, alarm, unreadalarm - слишком коротко и не совсем информативно, например если есть аварии должно быть что-то вроде online-alarm или offline-unreadalarm
Ну и далее скопом все переменные.

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