со своим токеном Вы чужие приборы не опросите, поэтому не знать не возможноЦитата:
я же не знаю, чего и кто там в облако добавит
Вид для печати
со своим токеном Вы чужие приборы не опросите, поэтому не знать не возможноЦитата:
я же не знаю, чего и кто там в облако добавит
capzap да я в том смысле, что драйвером смогут пользоваться другие. Я же не для себя лично его пишу, а для Scada системы в принципе. Ну как написали разработчики SimpLite для своей системы, так и я пишу для RapidScada...
Ну а если уже делать, то так, чтобы оно настраивалось... Для себя лично по неумению делать графический интерфейс я вообще шаблоны в xml руками создавал :)
Вот опять вы про токен, у пользователя он что, постоянен, просто нужна авторизация в начале? или он так же меняется, как и у демо пользователя каждый запрос?
если это всё не для себя, то почему тогда не воспользоваться разделом 13 https://ftp.owen.ru/OwenCloud/01_Docs/rp_owencloud.pdf
"id": 1099134,
"values": [
{
"d": 1668085434,
"v": "26.0",
"e": "",
"f": "26.0 °C"
}
]
Если можно, объясните запись выделенную жирным?
Это обозначение символа градуса Цельсия.Цитата:
Сообщение от melky
Вложение 63765
Про ограничения на число параметров для last-data - уточню у разработчиков.
Выше писал, что основная задача была разобраться с json и вообще чтением через API, на выбор было облако Овен и еще одного производителя устройств, я просто начал с Овен :) вот и все. Ну а если делать, то делать по возможности красиво :)Цитата:
если это всё не для себя, то почему тогда не воспользоваться разделом 13 https://ftp.owen.ru/OwenCloud/01_Docs/rp_owencloud.pdf
Ну и не у всех систем есть возможность использовать OPC, либо просто не умеют, либо необходимо покупать лицензии, при этом есть лицензии на теги по Modbus или просто умеет, либо MQTT или OPC UA.
Тут то как раз можно сварганить шлюз, установив только Сервер и Коммуникатор RapidScada, ограничив БД скажем парой дней. А может кому-то нужно в PostGre пихать данные... В общем вариантов масса
Евгений Кислов если разработчикам не сложно доработать parameters/last-data чтобы вводить не {"ids":[268191, 270292]} а {"device_ids":[1111, 2222]} и получать такой же ответ сразу всей пачкой переменных из указанных девайсов было бы быстрее
"operative_period": 5,
"configuration_period": 900,
"manageable_period": 5,
В девайсе есть такие параметры, можете более подробно их объяснить? Например operative_period в рамках того, что бесплатному аккаунту доступно обновление 60с, а платным не менее 30с
документацию на облако прочтите раздел 5.3.2 Настройка типов параметра прибораЦитата:
Сообщение от melky
capzap И? где в документации ответ на основную часть вопроса? Просто вижу, что у demo пользователя operative_period значение = 5 - что 5? секунд?, как это связано с тем, что пользователю доступен минимум только 60с, а у платных нет ниже 30с ?
operative_period - период опроса оперативных данных в секундах
и смотрим тарифы, где там 5 или 15 секунд? а, для юриков есть даже 10 секунд.
Ну и для понимания терминологии, что такое "Управляемый параметр" ?
• Управляющие – параметры, записываемые в прибор: запись параметров, запись по шаблону, конфигурации. -- То есть фактически это Оперативный параметр RW (чтения и запись) ?
все три вида читают значение, для этого и есть время периодичности. Разница между управляемым и конфигурационным в "волшебной" кнопке все конфигурации
Конфигурационный не волнует, по сравнению у них время большое на чтение, и 900 секунд и 600 и так далее. Разница между Оперативным и Управляемым какая?
Разве Оперативный нельзя писать? Я просто пытаюсь параллели провести. Оперативный - например значение давления. Управляемый - уставка этого давления, но тогда этот Управляемый может быть и Конфигурационным и читаться редко.
Мне понять в рамках Облака разницу надо. У меня есть Input. Output, Input/Output типы каналов - если сравнивать с этим например, что есть Управляемый и Конфигурационный тогда ?
То есть Input это Оперативный (только чтение)
Output у меня не считывается, это только команды
Ограничений нет.Цитата:
Сообщение от melky
Параметры, которые принадлежат только группе Оперативный - не будут отображаться в веб-интерфейсе на вкладке Запись параметров.Цитата:
Разница между Оперативным и Управляемым какая? Разве Оперативный нельзя писать?
Я предполагаю, что их запись через API тоже будет недоступна (должен вернуться 'code' => 'parameter_not_writable').
через API использовать получится только оперативный и управляемый. Конфигурационный будет как управляемый, его фишка что через браузер можно взять параметры из истории сравнивая их между собойЦитата:
Сообщение от melky
Какой параметр определяет, какой из параметров формата используется? format или modbus_format ?
Это можно понять c помощью запроса device-management/types-info (см. group_type).Цитата:
Сообщение от melky
да е мое, запрос на запросе :)
device_format - формат хранения. Может принимать следующие булевы значения:
0 - float, 1 - uint16, 2 - int16, 3 - uint32, 4 - int32, 5 - bool, 6 - double, 7 - int64, 8 - uint64
Здесь номера это номера битов? или ошибка и тут так же enum?
Ошибка, здесь тоже enum.Цитата:
Сообщение от melky
device-management/types-info по данному запросу я получаю всякую муть, что есть в системе, шаблоны приборов, которых нет у пользователя Демо.
"ПЛК через Modbus TCP"
"Произвольный прибор Modbus" в запросе device/index
Это предопределенные выражения? Если прибор Овен что может быть в надписи? или type может выглядеть как "ПЛК в гараже у Васи" ???
посмотрел, не имеет смысла, проще добавить ручную настройку... Почему было не сделать один общий список enum, чтобы не было совпадений и в зависимости от типов приборов и т.д. выставлялись требуемые значения? не понятно... хорошо еще нет параметра "owen_format", "opc_format" в общем на каждый чих..
"group_type": "container" - какой перечислитель форматов используется в данном случае? format или modbus_format ?
Используется в "Программируемый контроллер" и "OPC UA"
А Modbus аж целых два "modbus_template" и "modbus_various" - зачем? и если придумали зачем, то отличия относительно форматов ?
"id": 171772,
"name": "Котельная (ПЛК160_1.2.2)",
"identifier": "E4:1E:0A:00:0D:FA",
"type": "ПЛК через Modbus TCP",
"time_zone": "GMT+3:00",
"is_favourite": false,
"categories": [
Собственно почему тут было не указать протокол и формат, раз разделили? сразу в устройстве
1. Должен использоваться modbus_format.Цитата:
Сообщение от melky
2. modbus_template - это уже готовые шаблоны, а modbus_various - произвольный слэйв, для которого пользователь сам настраивает список параметров.
В обоих случаях используется modbus_format.
Спасибо, прикрутил уже чтение и определение этих переменных, благо они только при инициализации будут работать, потом уже не особо будут нужны.
В протоколе Owen форматы signed/unsigned это int16/uint16 или int32/uint32 ?
И форматы времени datetime, date, time в каком виде, UNIX формат который расширенный на 100 лет ? или иное?
В протоколе ОВЕН целочисленное значение может занимать 1, 2 или 4 байта.Цитата:
Сообщение от melky
В облаке, вероятно, всегда выделяется 4 байта.
В протоколе ОВЕН свои форматы для хранения значений даты и времени, см. п. 5.1.3:Цитата:
И форматы времени datetime, date, time в каком виде, UNIX формат который расширенный на 100 лет ? или иное?
https://owen.ru/uploads/121/oficialn...n_15.01.07.pdf
Но в облаке, насколько я понимаю, они конвертируются в Unixtime, и доступны уже только в таком виде.
Не, мне как раз то, что в облаке интересует. Я же работать буду через облако.
Вот сижу прикручиваю типы переменных, на минус топоры не смотреть, не докрутил еще :)
Удалил лишнее - объясните - "format": 2 для owen это UInt32, "modbus_format": 1 для Modbus это Uint16 - почему значение 25.0 при том, что dot_point = null ????Цитата:
{
"id": 1099134,
"code": "wTempCloud",
"format": 2,
"dot_point": null,
"is_writable": 0,
"modbus_format": 1,
"modbus_multiplier": "1.0000000",
"name": "Температура",
"value": "25.0",
"formatted_value": "25.0",
"fault": "",
"measurement": {
"title": "°C",
"name": "температура",
"default_precision": 1,
"visible": 1
}
Потому что "default_precision": 1
- precision - точность отображения (число знаков после десятичной точки, уже применено для value). Если не задана (null) будет применена точность по-умолчанию, взятая из measurement.default_precisionЦитата:
Сообщение от melky
а, спасибо. Сейчас поколдую еще и с этим...
"default_precision": 1 игнорируется, если precision = 0 или иное?
Вот реально, зачем СТОЛЬКО различных переменных для простых вещей?
API предназначено для работы с облаком сторонними приложениями, если вы всегда передаете значение параметров в строковом виде стороннему приложению и с учетом точности, количества знаков после запятой и т.п. и т.д Ну так и укажите единственную переменную format правильно для стороннего приложения.
А то формат UInt16 или Int16 а передаете блин значение с каким-то количеством после запятой....
учитывая, что в запросах v1 светится, то будет и v2 :), надеюсь в версии 2 искорените дублирующие переменных и соберете в кучу непонятное разделение форматов и так далее...
Блин, да е моё, если не задана (null) то будет взято оттуда !!!!! жесть....... рука-литсо.....
"id": 14966589,
"code": "Ain.H",
"format": 0,
"value": null,
Вот реально хочется кому-то руки оторвать, Если у вас параметр для чего-то другого, а не значение, раз вы value = null делаете, ну так добавьте в параметр format тогда не 0 - float для прибора Овен, а скажем 10 - нет значения для данного параметра... Ну или что-то в этом духе... А так переменная как бы есть, но ее как бы и нет...
Я так понимаю для приборов Овен все по другому и last-data теперь уже до фонаря :) супер API :)
Или это поведение отключенного и ни разу не опрашиваемого прибора????Цитата:
[
{
"id": 14966247,
"values": []
},
{
"id": 14966241,
"values": []
},
{
"id": 14966253,
"values": []
},
{
"id": 14966589,
"values": []
},
{
"id": 14966685,
"values": []
}
]
| 6 | Ain.H | Верхняя граница диапазона измерения активного датчика - вход 1
| 7 | rEAd | Измеренная величина - вход 1
| 8 | in.SL | Наклон характеристики датчика - вход 1
| 9 | Ain.L | Нижняя граница диапазона измерения активного датчика - вход 1
| 10 | ItrL | Период опроса датчика - вход 1
| 11 | in.FG | Полоса цифрового фильтра - вход 1
| 12 | in.Fd | Постоянная времени цифрового фильтра - вход 1
| 13 | Cj-.C | Режим работы автоматической коррекции по температуре свободных концов ТП вход 1
| 14 | in.SH | Сдвиг характеристики датчика - вход 1
| 15 | dP | Смещение десятичной точки - вход 1
| 16 | in-t | Тип входного датчика или сигнала - вход 1
| 17 | Ain.H | Верхняя граница диапазона измерения активного датчика - вход 2
| 18 | rEAd | Измеренная величина - вход 2
| 19 | in.SL | Наклон характеристики датчика - вход 2
| 20 | Ain.L | Нижняя граница диапазона измерения активного датчика - вход 2
| 21 | ItrL | Период опроса датчика - вход 2
Кто-то говорил что не может быть одного кода - а тут на каждом входе повторяется. С чем связано ?
"Тут" - это где?
Евгений Кислов добавленный в Демо прибор Овен "type": "Модуль ввода аналоговый МВ110-224.8А" - кто-то сегодня его добавил, вчера не было. Так вот коды на входах имеют повторение. Интересно, если при добавлении в WEB будет выдана ошибка на повторяющийся код то как так получилось, что здесь они одинаковы ? Потому что это прибор Овен и как-то по другому работает? как?
Прибор в offline, массивы last-data пустые. value в большинстве своем null если считывать через индекс прибора, хотя в одном месте строковая переменная имеет "" вместо null как другие.
См. скриншот - коды уникальные за счет индексов каналов:Цитата:
Сообщение от melky
Вложение 63894
То, что вы выложили выше - это именно то, что вы видите в ответе от облака или это уже выхлоп вашего парсера?
{
"id": 14966589,
"code": "Ain.H"
Даже если запросить сторонними сервисами, то код Овен без указание индекса, как у вас на скриншоте самого облака, значит код добавляется индексом
Совершенно верно, это ответ облака на device/312177
так же на запрос last-data у этого прибора приходят пустые массивы переменных, в сообщении #73
А если зайти через Web то у имен тоже есть индексы, но при запросе json индексов в именах нет
Значит, для индексированных параметров протокола ОВЕН через API коды отдаются без индексов - я не считаю такое решение удачным, но такова реализация.Цитата:
Сообщение от melky
Ну индексы я добавлю, не проблема. А почему пустые массивы переменных? просто прибор ни разу не опрашивался?