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

[melky]

Собственно пытаюсь сделать драйвер для RapidScada для OwenCloud и есть некоторые вопросы, чтобы понять в какую сторону копать, чтобы потом сильно не переделывать.

1. Токен ? - Токен получаем всегда через авторизацию как в Демо варианте и потом используем, или Токен может быть постоянным для пользователя?
К сожалению нет личного кабинета для Облака, есть правда ПЛК100 после ремонта, не знаю, он может быть подключен к облаку? Покупать шлюзы нет никакого желания как бы, да и просто на это пока денег нет...

2. Что будет происходить если будут добавляться приборы или даже компании с приборами (так понял для интеграторов есть такая возможность)

3. Облако имеет OPC UA Клиент, или Сервер чтобы организовать пересылку данных от одного устройства другому при помощи драйвера? И главное доступ к этим механизмам через API ?

[melky]

Информация о приборах, фильтр вида device_ids какое тело запроса должно быть ?

{"device_ids":"тут что и как?"}

[melky]

{"filter":"100"} - и какое тут число в фильтре должно быть? ставлю число любого id и получаю пустоту []

[melky]

И если не жалко, поделитесь классами для device/index и device/id, а то ручками тяжко создавать, много там всего, а кто-то может уже сделал

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

[melky]

filter - число, в таком случае будут выведены только приборы, пользовательское описание которых подходит под этот фильтр. // СТРОКА - исправьте в документации

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

{"device_ids":[171772, 43549]}

company_id - в демо нет такого, чтобы проверить

p.s. такое ощущение, что я разговариваю сам с собой....

[capzap]

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

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

[melky]

capzap я всего лишь прошу поделиться готовыми классами сериализации, чтобы не тратить время на это самому. Разрабы могли бы и поделиться готовыми... Я их и сам то сделаю, не проблема, просто это время.

Что касается остального, достаточно было бы быть внимательнее, при составлении документации и качеству примеров. Например POST /v1/device/125 HTTP/1.1 - а пример ответа с id = 4 а не 125 и так далее по
тексту.

от своих слов не отказываюсь потому что столько мусора напихали в параметрах всяких, и часть можно сократить. На счет json пока не знаю, только начал с ним разбираться, есть ли у него функционал не записывать строки с параметрами false, "", 0 и так далее как это есть в одном из вариантов xml... что очень сильно сокращает файлы при сериализации...

Еще пример
"register_byte_order": 1,
"register_order": 1,
Можно просто сделать "Order":"01" - первое для байтов, второе для регистров. И мало того, закинуть это не в параметр переменной а в параметр устройства.
Посчитайте сколько произойдет экономии

[capzap]

capzap я всего лишь прошу поделиться готовыми классами сериализации, чтобы не тратить время на это самому. Разрабы могли бы и поделиться готовыми... Я их и сам то сделаю, не проблема, просто это время.

Что касается остального, достаточно было бы быть внимательнее, при составлении документации и качеству примеров. Например POST /v1/device/125 HTTP/1.1 - а пример ответа с id = 4 а не 125 и так далее по
тексту.

от своих слов не отказываюсь потому что столько мусора напихали в параметрах всяких, и часть можно сократить. На счет json пока не знаю, только начал с ним разбираться, есть ли у него функционал не записывать строки с параметрами false, "", 0 и так далее как это есть в одном из вариантов xml... что очень сильно сокращает файлы при сериализации...

Еще пример
"register_byte_order": 1,
"register_order": 1,
Можно просто сделать "Order":"01" - первое для байтов, второе для регистров. И мало того, закинуть это не в параметр переменной а в параметр устройства.
Посчитайте сколько произойдет экономии

ну идиоту идиотово

[melky]

Смотрю вы прямо бог программирования
В последнее время становится тяжко смотреть в сторону ОЛ, из-за постоянных "Ошибка сериализации" даже в версии 2 никак избавиться не могут. И тут еще в документации на облако, ошибка на ошибке... А все разработчики наверное или в отпуске или разбежались из Овен. Просмотров темы много, и ни одного ответа со стороны Овен. теория доказательства блин какая-то....

[capzap]

Смотрю вы прямо бог программирования
В последнее время становится тяжко смотреть в сторону ОЛ, из-за постоянных "Ошибка сериализации" даже в версии 2 никак избавиться не могут. И тут еще в документации на облако, ошибка на ошибке... А все разработчики наверное или в отпуске или разбежались из Овен. Просмотров темы много, и ни одного ответа со стороны Овен. теория доказательства блин какая-то....

еще раз повторю, хамлу ни кто помагать не спешит

Посчитайте сколько произойдет экономии

есть такой параметр в сетях MTU поэтому особой разницы нет 20 байт или 40 передать. Так как Вы стремитесь сэкономить, то комментарии поясняющие назначения передавать не желательно, как тогда понять что передали если параметр будет максимально ужат

одном из вариантов xml

нет такого, xml един и соответствует стандарту, тот кто собрал файл может и разобрать его по своим правилам, помимо этого есть DTD но передавая его мы потратим драгоценные на Ваш взгляд килобайты. С json все так же свою сборку можете как угодно сокращать, потому что знаете как распарсивать, а чужой файл разбираете по чужим правилам

Например POST /v1/device/125 HTTP/1.1 - а пример ответа с id = 4 а не 125

фишка в том, что ни кто не сможет повторить этого потому что как минимум нет токена работать с этими приборами, соответственно важны не сами примеры а расшифровка того что приходит и отправляется