Да, этот прибор ни разу не опрашивался.Цитата:
Сообщение от melky
Вид для печати
Да, этот прибор ни разу не опрашивался.Цитата:
Сообщение от melky
А можно в Демо добавить реальный прибор с опросом? А то тут из-за того, что он Овен часть переменных null и пришлось правки в код вносить, так как в Modbus они далеко не null...
Любой прибор с протоколом ОВЕН или какой-то конкретный?Цитата:
Сообщение от melky
Да любой в принципе, тот же 8А подойдет, сейчас вот код чуть изменил, а он пропал из Демо :)
Если правильно понимаю, прибор с протоколом Овен можно подключить в облако только при помощи шлюзов, которых у меня нет. Так что тренироваться придется на "кошечках" потом, типа на пользователях. А так хоть основу сделаю...
А ПЛК100 если ему включить в конфигурации протокол Овен по ТСР будет работать с облаком?
Ок, я передам ваше пожелание коллегам.Цитата:
Сообщение от melky
Нет, ПЛК1xx работают с облаком только по Modbus.Цитата:
Сообщение от melky
Вот очередное недоумение. Если параметры котлов у прибора Котельная (ПЛК160_1.2.2) не записываются через облако, так понимаю, что фактически это передача данных со стороны ПЛК в облако. То почему у всех параметров стоит признак is_writable = true ?
Типа не верь глазам своим? :) и надо еще какой-то параметр сложить с этим, чтобы точно узнать, можно переменную менять или нельзя?
Записываются - попробуйте, например, параметр Давление подачи изменить.Цитата:
Если параметры котлов у прибора Котельная (ПЛК160_1.2.2) не записываются через облако
Именно поэтому они отображаются на вкладке Запись параметров и поэтому у них is_writable = true.
Вот именно Давление подачи через WEB и пробовал, как было 1.54 так и меняет опять на 1.54
Сейчас еще раз попробовал, да, запись проходит, потом меняется на 1.54
Значение сбрасывается на то, что видимо отправляет ПЛК. Получается, чтобы убедиться, что запись прошла мне надо период опроса в 0 выставить вместо моих 2-х минут, и то, отловить смогу только визуально.
Ладно, на других переменных потренируюсь, которые не сбрасываются в значение из ПЛК
В ПЛК в слэйве общая область памяти - т.е. туда происходит запись и со стороны облака, и со стороны программы.Цитата:
Сообщение от melky
Поэтому вы и видите такую картину.
Так реализован проект этого ПЛК - облако здесь не при чем.
Да, я понимаю, что облако тут не при чем. Это нормально для любого ПЛК, если так написана программа. Просто думал, раз переменные для записи true, то их можно менять и они будут сохранять свои значения.
Фактически на запрос 120 с чем-то переменных у меня уходит чуть менее 2-х секунд, с учетом чтения всех девайсов device/index и скопом всех переменных через их id - last-data + время на обработку всех переменных.
Но запись в БД выставлена раз в минуту, по этому отследить изменение переменной можно только визуально по текущим данным
В идеале, как выше писал, иметь возможность считывать все через last-data но с видом запроса {"device_ids" : [ id1, id2]} и ответ сделать примерно как у last-data но включить в него id устройства, и настраиваемые поля из устройства, типа (is_online, is_alarm) маской и строковой вид более расширенный. Сейчас online, offline, alarm, unreadalarm - слишком коротко и не совсем информативно, например если есть аварии должно быть что-то вроде online-alarm или offline-unreadalarmЦитата:
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 мс
Ну и далее скопом все переменные.
Был бы всего один штатный запрос-ответ, в котором бы было видно и состояние устройства. Иначе приходится делать два запроса
Вложение 63907а почитать документацию?Цитата:
Сообщение от melky
capzap проверки это другая сторона вопроса, я могу выставлением параметра в Scada выполнить опрос опять всех тегов сразу после передачи команды. Опять же, запись в БД по умолчанию у меня раз в минуту, посмотреть изменение на графике только после истечении времени.
А для тестов, видимо просто нужно будет найти параметр, который можно записывать, но сам он в обратку не поменяется... Ну либо последить за текущими или настроить какой-нибудь триггер на изменение канала... Это уже дело десятое...
По данной штуке объясните. Например если будет язык английский en_EN то в "measurement":Цитата:
measure - отображаемая единица изменения. Доступны следующие целочисленные варианты:
36 - A (сила тока: А)
19 - atm (давление: атм)
28 - bar (давление: Бар)
4 - deg (температура: °C)
13 - Gcal (тепловая энергия: Гкал)
8 - Gcal/h (тепловая мощность: Гкал/ч)
26 - GJ (тепловая энергия: ГДж)
33 - GJ/h (тепловая мощность: ГДж/ч)
{
"title":"float", здесь в title будет соответственно A, atm, bar, deg и т.д а если ru_RU то соответственно А, атм, Бар, °C - или как? Почему было не сделать так же цифровой настройкой, которая доступна в редактировании переменной и такой же параметр mesure ?
Да, вы понимаете правильно.Цитата:
Сообщение от melky
Реальный пример:
Код:"measurement": {
"title": "А",
"name": "сила тока",
"default_precision": 3,
"visible": 1
},
Только вот в списке я не увидел "float" а в демо Котельная он присутствует в одной из переменной :)
Извиняюсь, в документации по API
"measurement":
{
"title":"float",
"name":"floating point",
"precision":4,
"visible":0
}
То есть можно задавать руками, кроме выбора ?
В документации совершенно синтетический пример - не обращайте внимание на его частные особенности.
У реальных приборов такого title быть не может.
Произвольно title задать нельзя - в web-интерфейсе он выбирается из выпадающего списка доступных единиц измерения.
Понятно, просто подумал что можно добавлять свои единицы, если они отсутствуют в списке. Тем более по документации там есть разрывы в номерах.
В устройстве Метеостанция 5 этаж в параметре Концентрация CO2 указан measure ppm в документации на API в списках такой не значится, какой у него код ? и почему в русском варианте он остался ppm ?
Каких еще параметров не хватает в документации а они есть ?
Вот актуальный список:Цитата:
Сообщение от melky
Все единицы измерения в OwenCloud (11.2022):
Спасибо, добавлю к списку... Определять только непонятно как. Попробовал язык английский запросить en-EN а получил все на русском все равно :)
"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 по первому же параметру, а если ошибочный будет где-то в середине, не будет принят ни один параметр к записи ?
Ну вот странно срабатывает логика, если wStatus3 либо 0 либо 1 а я записываю 0.5 и Облако/ПЛК принимает значение и переводит параметр из 0 в 1
Как раз разделитель дробной у вас . (точка) а не , (запятая) иначе Exception сразу. Так же как и при парсинге, надо парсить что будет . в разделителе дробной.
У меня был где-то код, где при парсинге пофигу на . или , но на запись это никак не влияет, я обязан с точкой передать
Занимательная арифметика, если отправить 0,4 то с 1 в 0 параметр переключится :)
Групповую запись пока не реализовывал, у меня это только через строковой ввод можно сделать, используя параметры. Думаю потом буду прикручивать, если кому-то будет интересно конечно.
Если в запросе записи хотя бы для одного записываемого параметра задано некорректное значение - то вообще ни один из параметров запроса не будет записан.Цитата:
И если послать сразу команду на два значения с ошибочным вводом, то в ответ мы получаем только Exeption по первому же параметру, а если ошибочный будет где-то в середине, не будет принят ни один параметр к записи ?
Если в запросе записи более одного записываемого параметра с некорректным значением - то в ответе будет приведен Id только первого из таких параметров.
Евгений Кислов спасибо, примерно так и предполагал, что сперва обрабатывается запрос на корректность.
Ссылка не тему с драйвером https://owen.ru/forum/showthread.php?t=37061
Развитие в планах, но скорее всего после НГ. При необходимости могу делать тестовые ключи на больший срок...
Два шлюза ПМ210 передают данные в облако, ПЛК210 читает данные по АПИ, все хорошо. Меняю тариф на Профи и ПЛК перестает получать данные, токен перевыпускал, через GET запрос все читается, а контроллер данные не получает. Помогите пожалуйста.
затык в блоке CloudOwenReadTP
Пост я отредактировал и не рекомендую вам проект с паролями от личного кабинета куда-то выкладывать.Цитата:
Сообщение от Николай Суриков
Проект объемный - пожалуйста, оставьте в нем только то, что касается вашей проблемы с облаком, и после этого обеспечьте доступ по AeroAdmin.
Возник затык. При создании шаблона и чтении Параметров создаются переменные. Но они при чтении last-data с пустым массивом данных, то есть параметр "values" : []
Отсюда вопрос, так задумано пустышки в приборе делать или переменная может ничего не иметь а потом бах и выдать значение ?
В общем надо понять как обрабатывать данную ситуацию, просто исключать из опроса подобные переменные в принципе или все же ловить неожиданно появляющиеся в них переменные ?
Что именно вы шаблоном называете? Шаблон записи? Тогда о каком конкретно чтении речь?Цитата:
При создании шаблона и чтении Параметров
Где именно создаются? Приложите скриншот, пожалуйста.Цитата:
создаются переменные.
Шаблон это мой xml, который создается на основе запроса https://api.owencloud.ru/v1/device/_id_устройства
В данных запросах присутствуют объявленные переменные и их id, я создаю список (массив) id переменных, и при запросе уже через /v1/parameters/last-data получаю пустые массивы данных на часть объявленных переменных
Содержимое ответа:
[{"id":1ххххххх,"values":[]},{"id":1ххххххх,"values":[]},{"id":1хххххххх,"values":[]},{"id":1ххххххх,"values":[]},{"id":1хххххх,"values":[]}
Вот и интересует, почему в параметрах прибора переменная есть, объявлена, но при запросе через last-data переменная пустая ?
А какие реальные значения у этих переменных в момент отправки вашего запроса?Цитата:
Сообщение от melky