Непонятная ошибка serial

22

Мне кажется ровно противоположное, причем уже давно; это и есть причина эмоциональности моих постов.

  1. Любой сервис должен действовать понятно и предсказуемо, а не как приснилось вчера левой ноге юного кодера;
  2. Любой сервис обязан в полной мере блюсти общую и частную обратную совместимость И в алгоритме работы, И в конфигурации.

Если правила 1 и 2 не соблюдаются, речь о контроллере как продукте не пойдет никогда. На мой взгляд, вы сейчас все быстрее удаляетесь от идеи сделать продукт. Это сильно расстраивает: я два года уложил на попытки сделать на нем что-то рабочее.

По конкретике. В предыдущей версии контрол при ошибке записи возвращал error w, на уи его название краснело и значение через некий (около 500мс, няп) возвращалось в старое. Полсекунды отличаются от заданного в конфиге таймаута не на порядки, так что поведение это выглядело логично и понятно.
Вообще, serial был на мой взгляд наименее глюкавым из компонентов.

Что происходит сейчас, я вам в красках изложил выше, за вычетом ответа скрипта (доползу до компа, процитирую). Что вы хотите сделать в итоге - я понять не могу.

23

так я полностью согласен, и мы так и стараемся делать. На мой взгляд, старое поведение при ошибках записи было как раз неожиданным: сервис их просто игнорировал. Обработать это снаружи, в пользовательских скриптах, теоретически было можно, но практически - очень сложно, так никто не делал.
Причём с ошибками чтения поведение было другое: регистры просто опрашивались в следующем цикле, поэтому одиночные ошибки чтения ни на что не влияли и думать про них было не надо. А одиночные ошибки записи - влияли.

Вот мы это и сделали консистентно.

сейчас то же самое

оно возвращалось просто при следующем чтении значения. Причём внутри в значение контрола сначала ставилось новое значение (даже при неуспешной записи), а потом сбрасывалось на старое (после чтения из устройства). Это был баг, мы его исправили.

Естественно, про устройства типа вашего, которые отдают переходящую ошибку постоянно, мы и не думали. Но я сейчас даже с ним пока не услышал никакой проблемы! На работу скриптов повтор записи повлиять не должен был. Единственные изменение, которое вы должны были увидеть, это:

  1. в интерфейсе канал всё время горит красненьким (что логично: устройство отвечает ошибками)
  2. появляются ворнинги в логах (что тоже логично, но, кажется, их можно было бы выводить поменьше).

Если мы поймём, какие проблемы доставляет повтор записи с такими устройствам, то придумаем какую-то настройку для них. Т.к. есть десятки способов сломать Modbus, то внутри wb-mqtt-serial есть огромное множество настроек на все такие отлонения от стандарта, добавим ещё одну. Но, повторю, я пока не понял, какие собственно проблемы надо решать.

Если вдруг у вас скрипт каким-то образом был завязан на баг с игнорированием ошибки записи, который мы исправили, - то мы тоже подумаем, какую настройку про это добавить. Но, повторю ещё раз, я не могу придумать, каким образом это могло бы повлиять на поведение скриптов. Если повлияло - напишите подробно.

24

Это было бы логично, если бы так было, повторяю в седьмой раз. Но - на уи никакого намека на ошибку не отображалось.

25

Поколупал еще.
На уи контрол таки коротенько взмаргивает красным, если писать данные только сразу после рестарта serial. В очереди - вот что, подряд, без паузы, один раз:

/devices/ttymod1_delta cp200x_202/controls/cmd_src/meta/error w
/devices/ttymod1_delta cp200x_202/controls/cmd_src/meta/error (null)

Если второй раз попытаться записать - уже и не взмаргивает, и ошибку не постит, вообще полный молчок, кроме флада в логах. Именно поэтому я не видел ошибок, пока не закомментил стартовый скрипт (каюсь, в нем проверку не делал).

Флад в логе продолжается больше 10мин, в контроле торчит новое значение. Если сделать cmd+shift+R, появится старое.
Пц.