[Вопрос] Корректность данных получаемых функцией getPriorityTagDuration()

[Сергей Борисов]

Добрый день! Спустя длительное отсутствия, могу ответить на все ваши предложения и замечания.

1. Для вычисления состояния за текущий день ( если все же getPriorityTagDuration не дает для вас верных результатов и пока она не улучшена) можно использовать getTagIntervalCalculation, функция возвращает все интервалы, их начало и окончание, и просуммировать все интервалы для каждого тега.

   
   После тестирования работы метода getTagIntervalCalculation() для тега "NC_PROGRAM_RUN" (Работа по программе) с указанием даты от (from) = "2024-07-16 00:00:00" и датой до (till) = "2024-07-16 13:45:00" и проведенного анализа возвращаемых данных (часы, процент, интервалы) были получены следующие заключения:
   
   • base_shift = false
     • hours (часы) - полученное значение "4.4" совпадает, с небольшой погрешностью, с количеством часов за заданный периода времени, т.к. в отчёте Загрузка оборудования без учёта смен значение "4.43";
       
     • percent (процент) - полученное значение "37.29", не совсем ясно как считается, т.к. значение не соответствует проценту выполнения в отчёте Загрузка оборудования без детализации по сменам = "32.92";
       
     • timeData - первое значение до запятой "1721102408000", что соответствует дате и времени "2024-07-16 07:00:08" - время начало текущей смены, хотя по идее, значение должно быть равным или близким преданному значению till.
       
     
     
   • base_shift=true
     • hours (часы) - получено значение "3.52", а в отчёте Загрузка оборудования без детализации смен значение "3.55". Значения близкие, возможно погрешности округлений;
       
     • percent (процент) - полученное значение "32.24", очень похоже что это результат деления времени тега на переданный интервал времени, т.к. это значение не соответствует проценту выполнения в смену (вкладка смена на странице оборудования) и не соответствует значениям в отчёте Загрузка оборудования с детализацией по сменам (текущая смена) = "56", без детализации по сменам (общее) = "32.92". Полученное значение более близко к значению в отчете Загрузка оборудования без детализации по сменам;
       
     • timeData - значение начинается с символа запятой и следующее значение равно "1721102408000", что соответствует дате и времени "2024-07-16 07:00:08" - время начало текущей смены.
       
   
   !!! Кроме того:
   • если изменить значение от (till), например на "2024-07-16 01:00:00", то все получаемые значения hours и percent изменятся, что говорит о том, что итоговое значение hours не считает за текущую смену;
     
   • если подставить значение времени till, например, с начала текущей смены "2024-07-16 07:00:00", или "2024-07-16 06:59:59", или даже "2024-07-16 05:00:00" - то во всех случаях возвращаются нули в hours и в percent.
     
   
   Для справки! Для данного приложения значение параметра настроек "46_SHIFT_BASED_ON_DEFAULT_WORKSHIFT = false".
   
   ВЫВОДЫ:
   • получаемое значение hours более-менее соответствует другим отчётам и значение меняется в зависимости от передаваемого параметра base_shift;
     
   • получаемое значение percent не соответствует ни одному из отчётов и не ясно как рассчитывается это значение;
     
   • получаемое значение timeData всегда начинается с временной метки, соответствующей началу смены, и если указан параметр base_shift=true, то получаемое значение начинается с символа запятой;
     
   • не понятно как правильно передавать значения интервалов времени till и from, т.к. значения могут приходить нулевыми.
     
   
   
   
   

2. Альтернативно можно использовать результат расчета робота малых интервалов, который записывает результат расчета раз в три минуты в блокчейн, однако надо иметь ввиду, что робот малых интервалов рассчитывает с некоторой погрешностью из за стыков времени, поэтому в отчетах пока не применяется. Для вашей задачи, возможно, это подойдет, попробуйте. Если точность устроит, метод значительно ускорит ваше приложение. Сигнал записывается в оборудование в формате [App ID].[Tag ID].i.[тип расчета].[тип значения].[номер смены]. Номер смены необязательно. Пример ascii сигнала: 17.145.i.SCHED_PRIO.HOUR, где 17 - номер oid приложения, 145 - номер oid тега, i - обозначает малые интервалы,  SCHED_PRIO - расчет с учетом приоритетности, HOUR - получить часы . Можно запрашивать сразу несколько тегов, через |, например, '17.145.i.SCHED_PRIO.HOUR|17.146.i.SCHED_PRIO.HOUR|17.147.i.SCHED_PRIO.HOUR'.

   
   При использовании формата [App ID].[Tag ID].i.[тип расчета].[тип значения] всегда, даже для прошедших дат, ответ такой:
   
   Код:

   <items status="success" lang="ru_ru">
</items>
   
   Если из предложенного формата убрать "i", то результат уже не пустой, но для текущей даты, соответственно, результат не тот (робот ещё не обсчитал), а вот за предыдущие даты - всё хорошо.
   
   Какой должен быть робот для запросов по предлагаемому формату или как его создать?
   
   
   
   

3. Кстати, вместо getLastTagDataCalculation вы можете использовать getLastTagValue, это новая функция, которая есть в SDK, но еще не попала в документацию. Вычисляет последнее состояние тега и значения сигналов.

   
   Функция getLastTagValue() возвращает только последнее состояние тега, а не время в состоянии тега, и не интервалы в активном состоянии! Она просто возвращает состояние! Название метода подтверждает возвращаемый результат!
   
   Код:

   <items status="success" lang="ru_ru" >
<item id="winnum.foundation.WNSimpleDataObject" success="true" value="0" />
</items>
   
   Функция getLastTagValue() имеет описание на странице платформы "Справочник по Restful API".
   
   
   

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

   
   Есть ли какие-то новости по планируемым изменениям?
   

Hello World!:

- Сообщений не найдено.

[Сергей Соловьев]

1. getTagIntervalCalculation считает интервалы выполнения тега без приоритетности за полное время смен
base_shift
base_shift влияет на сдвиг первой смены в часах, заданных в from. 
Например, если
первая смена с 07:00:00, задали from 00:00:00 и till 19:00:00 и base_shift = true, то расчет выполнится c 07:00  from до 07:00 следующего за till дня
, если base_shift = false, то расчет выполнится начиная c 00:00:00 до 00:00:00 дня, заданного в till
till
Точное время в till значение не имеет, важно лишь к какому дню отнести последнюю смену.
timedata
расчет интервалов выполняется до конца дня ( base_shift = false ) или до конца последней смены (base_shift = true)
percent
Проценты считаются делением длительности тега hours на общее время смены в не зависимости от till и base_shift
Таким образом, обычно задают
from  00:00:00 ( и Winnum будет искать начало первой смены этого дня для старта расчета или считать с этого времени)
till 23:59:59 ( и Winnum будет отсчитывать 24 часа от from в дату till)
Текущее время, текущую смену и текущие проценты к текущему времени метод сам не определяет
 
2. Возможно расчет выключен или версия слишком старая, включение в
"\WinnumPlatform\config\workers\application\standalone.xml"
"WinnumAppSES.instant.enable" value="true"
После изменения надо перегрузить платформу
 
3. Да, совершенно верно.
getLastTagValue альтернатива getLastTagDataCalculation , о которой шла речь в предыдущих постах.
getLastTagDataCalculation также считает только последнее состояние.
 
4. По getPriorityTagDuration пока полностью не решен вопрос, если я не ошибаюсь. Хотя исправления были, но некорректность осталась. По getLastTagDataCalculation исправлено

Hello World!:

- Сообщений не найдено.

[Сергей Соловьев]

getPriorityTagDuration также исправлен, будет включен в ближайший дистрибутив.

Hello World!:

- Сообщений не найдено.

[Сергей Борисов]

getPriorityTagDuration также исправлен, будет включен в ближайший дистрибутив.

Отлично! Спасибо! Ждём обновления 

Hello World!:

- Сообщений не найдено.

[Lamantur]

getPriorityTagDuration исправлен в версии 5.4.5

Hello World!:

- Сообщений не найдено.