WB-MAP6S Изменение направления трансформаторов

Периферийные устройства Счётчики WB-MAP
1

Добрый день!

В окрестности 15.08.2024 оказалось, что токовый трансформатор был подключен в неправильном направлении, из-за чего вместо накопления
wb-map6s_153/AP energy 2, началось накопление wb-map6s_153/AN energy 2

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

https://wirenboard.com/wiki/WB-MAP6S_Modbus_Power_Meter#Направление_подключения_токовых_трансформаторов
Начиная с прошивки версии 2.10.0 настройки позволяют инвертировать трансформаторы тока программно и, таким образом, подключать их в любом направлении к нагрузке.

и еще три упоминания версии 2.10.0.

А также

https://wirenboard.com/wiki/WB-MAP6S:_Changelog
2.10.0 (07.08.2024) — доступно в testing
Добавили функцию программного реверса токовых трансформаторов

После чего контроллер был переведен на testing релиз, далее был запущен wb-mcu-fw-updater update-fw, и… ничего

Оказалось, что версия прошивки WB-MAP6S как была 2.8.1, так ей и осталась, что подтверждают записи в https://fw-releases.wirenboard.com/fw/by-signature/release-versions.yaml

map6semG16:
  _firmwares_stable: fw/by-signature/map6semG16/main/2.8.1.wbfw
  _firmwares_testing: fw/by-signature/map6semG16/main/2.8.1.wbfw
  stable: fw/by-signature/map6semG16/main/2.8.1.wbfw
  testing: fw/by-signature/map6semG16/main/2.8.1.wbfw
  unstable: fw/by-signature/map6semG16/main/2.8.1.wbfw
  wb-2207: fw/by-signature/map6semG16/main/2.8.1.wbfw

Затем был обнаружен PR Feature/fw547 reverse ct by Ilia1S · Pull Request #797 · wirenboard/wb-mqtt-serial · GitHub, и, вероятно, соответствующая ему прошивка 2.10.0 в https://fw-releases.wirenboard.com/?prefix=fw/by-signature/map6semG16/unstable/bugfix-fw547-bugfixes/
43b4edfbce5a1573189d07ebedc90584 2024-08-12T15:04:33.000Z 26.2 kB bugfix-fw547-bugfixes/2.10.0.wbfw

Далее был вручную применен патч из PR templates/config-map3h-fw2.json для файла /usr/share/wb-mqtt-serial/templates/config-map6s-fw2.json и была обновлена прошивка (2.8.1 → 2.10.0), с помощью wb-mcu-fw-updater update-fw /dev/ttyRS485-1 -a 153 --branch bugfix-fw547-bugfixes, после чего все заработало.

Вопросы

№1

Когда будет исправлена неточность в документации, либо рассмотрен PR на github и выпущена прошивка?

Версия пакета wb-mqtt-serial на момент указанных выше манипуляций была 2.138.1, после нее вышло еще три версии, но в чейнджлогах ничего нет

(2.139.1) * Fix address validation for setup/parameters -- Nikolay Korotkiy <nikolay.korotkiy@wirenboard.com> Tue, 13 Aug 2024 10:05:00 +0400
(2.139.0) * Add template for Ensystec -- Mikhail Burchu <mikhail.burchu@wirenboard.com> Fri, 23 Aug 2024 08:28:00 +0300
(2.138.2) * Add comments for Cleaning Mode in WB-MWAC template -- Radmir Khakimov <radmir.khakimov@wirenboard.com> Tue, 15 Aug 2024 16:05:00 +0500
(2.138.1) * Fix APC NMC2 AP9630 template -- Nikolay Korotkiy <nikolay.korotkiy@wirenboard.com> Tue, 06 Aug 2024 16:05:00 +0400

№2

Рядом с bugfix-fw547-bugfixes/2.10.0.wbfw есть другая прошивка
493a16183a9d944951ecd200216e7374 2024-08-13T06:53:49.000Z 26.1 kB pre-release-2.9.0/2.10.0.wbfw
Она свежее, но не имеет связи с номером PR на github - её ставить не стоит?

№3

Как по модели (wb-map6s) узнать её signature (map6semG16)?
Я увидел signature в логах работы утилиты wb-mcu-fw-updater
Способ, предложенный в Загрузчик периферийных устройств Wiren Board — Wiren Board не работает
При вызове команды
echo -e $(modbus_client --debug -mrtu -pnone -s2 /dev/ttyRS485-1 -a153 -t0x03 -r290 -c12 | grep Data | sed -e 's/.*Data://' -e 's/ 0x00/\\x/g')
Наблюдаются следующие выводы (одна строчка - одна ошибка)

ERROR Resource temporarily unavailable: read
ERROR CRC received 0xFFFF != CRC calculated 0xC18F
ERROR Resource temporarily unavailable: read

Удалось получить signature, лишь предварительно остановив службу wb-mqtt-serial, есть ли другой способ?

№4

Судя по wb_mcu_fw_updater/update_monitor.py (tag v1.11.0), ask_user вызывается только в ветке, когда утилите передается --branch.

Возможно, при понижении версии (а может и всегда), также стоит задавать вопрос пользователю?

Либо же, добавить флаг --dry-run, чтобы видеть, что произойдет Downgrade, и уже потом принимать решение - перезапускать ли утилиту для непосредственного Downgrade, или нет

Т.к. во время подготовки этого сообщения произошла следующая ситуация

Во время поиска ответа на вопрос “что будет, если попробовать произвести update-fw сейчас”, утилита без вопросов начала выполнять ломающий функционал downgrade, после чего, очевидно, снова пошло накопление обратной энергии

root@wirenboard-ANH5JH52:~# wb-mcu-fw-updater update-fw /dev/ttyRS485-1 -a 153
Will find serial port settings for (/dev/ttyRS485-1 : 153; response_timeout: 0.20)... (elapsed: 00:00)
2024-08-28 21:48:32,493 Has found serial port settings: SerialSettings(baudrate=9600, parity='N', stopbits=2)
2024-08-28 21:48:37,390 fw (map6semG16 153 on /dev/ttyRS485-1):
2024-08-28 21:48:37,392 Downgrade: 2.10.0 -> 2.8.1 (map6semG16 153 /dev/ttyRS485-1)
2024-08-28 21:48:40,737 Flashing /var/lib/wb-mcu-fw-updater/map6semG16__2.8.1_master_0e97e88.wbfw (180 data chunks)
100%|#####################################################################################################|180/180
2024-08-28 21:49:20,621 Done

root@wirenboard-ANH5JH52:~wb-mcu-fw-updater update-fw /dev/ttyRS485-1 -a 153 --branch bugfix-fw547-bugfixeses
Will find serial port settings for (/dev/ttyRS485-1 : 153; response_timeout: 0.20)... (elapsed: 00:00)
2024-08-28 21:50:38,742 Has found serial port settings: SerialSettings(baudrate=9600, parity='N', stopbits=2)
2024-08-28 21:50:39,490
2024-08-28 21:50:39,491 Flashing device: "map6semG16" branch: "bugfix-fw547-bugfixes" version: "release" is requested.
2024-08-28 21:50:39,492 Stability cannot be guaranteed. Flash at your own risk? [Y/N]
Y
2024-08-28 21:50:43,541 Confirmed update: 2.8.1 -> 2.10.0
2024-08-28 21:50:47,003 Flashing /var/lib/wb-mcu-fw-updater/fw/map6semG16__2.10.0_bugfix-fw547-bugfixes_572891e.wbfw (197 data chunks)
100%|#####################################################################################################|197/197
2024-08-28 21:51:30,639 Done

№5

Какое значение у следующих ключей файла https://fw-releases.wirenboard.com/fw/by-signature/release-versions.yaml?
_firmwares_stable, _firmwares_testing, stable, testing, unstable, wb-2207

3

Добрый день.

Если PR еще не одобрен - то он (пока) не попадет даже в testing.
Благодарю за указание на ошибку, уберем из changelog версию которая еще не официальная.

Применение изменений, которые еще не влиты в основную ветку - способно вызвать труднодиагностируемые (потом) проблемы. Если у вас пока не эксплуатируемый объект - ладно, вполне нормально экспериментировать.

Даже не знаю что в ней за изменения. Вполне может быть что-то для отладки, в том числе с неверным расчетом значений.

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

А на практике - какое поведение ожидается? Точнее - зачем, кроме отладки спрашивать если не указана ветка?

На практике применяются только stable, testing и 2207. Но поддержка 22 07 заявлялась на два года и, пожалуй, скоро будет прекращена.
Назначение - чтобы в релизе без программной поддержки каких-то функций не удалось установить прошивку.

4

Добрый день! Прошу уточнить, актуальна ли еще эта проблема?

8

Добрый день!

Дошли руки обновить пакеты, прошивки и протестировать - все работает, спасибо.

Как будто были проигнорированы три абзаца текста описания конкретной ситуации после вопроса в пункте №4, где из-за отсутствия вопросов произошел нежелательный даунгрэйд…

Зачем? Чтобы иметь хоть немного контроля, над тем, что будет выполнено. Раз по умолчанию никаких вопросов не задается - почему бы не добавить флаг --dry-run, который произведет соответствующий опрос устройства, запрос к серверу с прошивками, но не flashing устройства.

Это в целом связано с отсутствием семантики update-list upgradeable upgrade/dry-run, в утилите wb-mcu-fw-updater, в том смысле, что узнать что сделает update-all или update-fw можно только непосредственно запустив процесс обновления.
Т.е. нельзя выполнить абстрактную команду update-all --fetch, которая вернет список устройств и версий, для которых будет произведено обновление прошивок.

Поэтому, как самый простой вариант, я и предлагаю рассмотреть добавление --dry-run