Нашел эту старую тему, поскольку столкнулся с аналогичной проблемой с приобретением данного девайса. Внимательное изучение показало, что в документации WB неверно описано представление данных счетчика энергии. Описано как u64 little endian, на деле же u64 little endian byte swap. Понял это с помощью опроса через Modbus poll. Ну и IoBroker не умеет работать с таким представлением, а установка как в документации WB приводит к некорректностям показаний. Странно что за столько лет не исправили в документации. Ну а с IoBroker - тут либо добавить такое представление для 64 бит регистров (путем слезной просьбы к разработчикам), либо считывать регистры раздельно и пересчитывать скриптом… вот ведь, проблема на пустом месте…
Нет. Документация верна, можно убедиться https://github.com/wirenboard/wb-mqtt-serial/blob/17b5dbd07f1569d076803542687e2460ca173510/templates/config-map6s-fw2.json#L249
Увы… неверна. IoBroker умеет использовать u64 little endian - итог неверный. Поэтому проверял с Modbus poll. С той же установкой считывания - то же показание, что в IoB, а вот с byte swap - нормально выдает. Последнему верю больше, чем документации и IoB. Ну а ссылка - это про ваш контроллер, который не использую уже давно и не собираюсь больше.
Ну и Wb-map6s значение в регистре потребляемой мощности - #3 от пользователя Explorerol
Счетчики работают довольно давно, если бы (теоретически) документация не соответствовала шаблону - то было б заметно.
С мощностью проблем нет. Показывает верно, соответствует тому, что измеряется через другое устройство. И с документацией проблем нет. Проблема только с представлением регистров, отвечающих за потребленную энергию. То есть за квт-ч. Еще раз повторяю - в случае использования представления в документации и IoBroker и Modbus poll показывают одинаково и полную ересь с перескакиванием цифр туда-сюда. А вот если в Modbus poll использовать представление с byte swap - становится нормально, вижу последовательный счетный прирост потребления. К сожалению IoB работать с таким представлением не умеет. Разве что пересчитывать регистры самостоятельно. Но пока лениво это делать. Уверен что так заработает. То есть на лицо ошибка документации. Ну или ваше описание представления регистра отличается от представлений других инструментов. А то, что с контроллером и шаблоном у вас все работает - не показатель, ошибка может в двух местах компенсироваться. Вообщем-то Вы сами можете взять и попробовать Modbus poll - инструмент универсальный и самый распространенный для диагностики модбаса.
Этот иснструмент “черный ящик”. Мне гораздо проще взять обычный modbus_client, прочитать регистры видя отправленные баты как к устройству так и от него, потом просто cj,hfnm pyfxtybt/ Есть пример: WB-MAP6S, прошивка 2.x: измеряемые и вычисляемые величины — Wiren Board
Ну если Вы так считаете - пусть будет так. Вообщем-то эта проблема будет проблемой только с использованием ваших устройств со сторонним софтом и устройствами. Ну и будут время от времени всплывать такие темы. Мне понятно что с этим делать чтобы работало… Ну а изменение прошивок устройств для приведения в соответствие с документацией, понимаю, будет крайне неприятно и наверное не нужно. Да и документацию менять - значит менять шаблоны к своему контроллеру (только в названиях), иначе разночтения будут. Опять неприятно… Байты Вы прочитать сможете, даже прекрасно понимаете как их пересчитывать. Проблема только в соответствии названия представления регистра тому, как это принято у других. И вот тут кроется проблема совместимости с прочими инструментами, если тупо следовать тому, что описано в доке. А вообще, это нередкий случай у разработчиков… недавно была близкая проблема с еще одним российским разработчиком - там вообще была смешная ситуация - в документации написано что импульсный выход TTL - описаны уровни выходного напряжения, тайминги…, общался с разработчиком напрямую - он подтвердил. И не работает… Пришлось брать тестер и прозванивать выходные цепи на плате. Поскольку схему не дают - коммерческая тайна у них. Оказалось что на выходе банальный транзистор с ОК и искать на нем выходные уровни напряжения бессмысленно. Ну и тайминги оказались на пару порядков другие чем в доке - но тут хотя бы разработчик сразу сказал что это так. Извинялись потом, что ввели в заблуждение… А устройство нормальное и нормально работает.
Так. big endian - определение из вики: Порядок байтов — Википедия
точно так же у нас. Младший регистр - старшее значение.
Там в доке на девайс little endian для счетчиков. Что верно. Только байты надо делать swap. Зачем рассказали про big endian - я не понял. Там где это указано (например мощности) - работает без проблем. И, кстати, еще один косяк нашел с этим модулем. “Текущее напряжение питания”, регистр 121 - врет… 6,9 вольт вместо 13,6. Рядом стоит другой ваш модуль WB-MCM8 - на нем показание верное. Но это не критично совсем. Еще странность - раньше вы в доках указывали регистр 130 (для отключения лишней иллюминации), теперь почему-то нет. Но оно работает и на этом девайсе, что порадовало - все эти мигания светодиодов полезны только при отладке. Ну и еще… ошибиться со счетчиком крайне трудно. Там идет последовательный прирост показания и если выбор типа представления неверный - то сразу видно скачущие в беспорядке цифры. Не, можно, конечно, утверждать что именно ваше понимание такого типа верное, а у других нет… Если лень самим проверить с Modbus poll - могу видео снять с обоими вариантами. А могу не делать этого, мне вообщем-то уже безразлично будет ли исправлено в доках или нет - главное есть понимание как получить верный результат из того, что есть. Мне доказывать уже ничего не надо, это больше надо вам.
Неправда. Со счетчиков. Смотрите первое сообщение “в документации WB неверно описано представление данных счетчика энергии”.
Покажите пожалуйста почитанное за один запрос значение, попробуем его разобрать…
Ну или, лучше, покажите как его преобразовываете.
Что Вам даст это единожды прочитанное значение? Ну разберете Вы его - а дальше? Важно насколько оно соответствует реальности и как меняется в процессе. Вот снял видео где сначала в соответствии с докой, а потом переключаю на byte swap. И в последнем случае изменение показания за определенное время соответствует таковому на другом счетчике… ну разумеется с некоторой погрешностью на трансформаторе, около 1%. Да и видно как цифры бегут - оно правильно когда сначала меняются последние - идет счет. https://www.dropbox.com/s/2js4c3kxjkzlzfs/VID20230720211006.mp4?dl=0
Просто покажу как из регистров получить значение.
Что делает это самое “byte swap” в этой программе?
Откуда уверенность что программа с закрытым кодом делает точно в соответствии с нашей документацией?
То есть - какую операцию и над чем?
Я категорически неприемлю закрытые “черные ящики”, в которых похожие на правду значения получаются перебором…
Вот похожая тема: https://support.wirenboard.com/t/map3h-map3e-ne-mogu-schitat-dannye-iz-segnetiks/
Зачем мне этот показ? Мне надо визуализировать измерение в конкретной системе - IoBroker. Там есть свой драйвер, работающий с модбасом и за ним не замечалось раньше некорректного отображения регистров. И вот этот драйвер показывает ерунду если там выставить то, что в вашей документации. Modbus poll - это инструмент диагностики. Разумеется, не получив результат я взялся за него чтобы понять причину. И довольно быстро понял. Требуется byte swap. Но, к сожалению, IoB это на 64 бит регистрах не умеет. Такие регистры вообще экзотика. То есть как минимум два инструмента не хотят работать если указать что в вашей документации. Но вы, конечно, всегда правы. А другие ошибаются. Так? Ну а получить значение я могу и в IoB другим путем - считав отдельно 4 регистра и настроив пересчет полученных из них данных. Вообще никаких проблем. Только возни побольше и более громоздко выходит. Система довольно гибкая во всех отношениях. В отличие от вашего контроллера, который у меня был когда-то - вспоминаю как страшный сон - глючный, тормозной и для его использования нужны регулярные танцы с бубнами. И постоянная фобия “вдруг сломается”. Через год использования, поняв что дальше так жить нельзя, постепенно от него начал избавляться, перенося функционал. А потом он просто сдох - похоже флеш накрылся. Ну и фиг с ним - забыл о существовании. И в моем понимании “черный ящик” - это именно он. Ну и если вы производите и прочие устройства, которые по сути и по вашим заявлениям универсальны и применимы с модбасом - то все же следует прислушиваться к клиентам, у которых возникают проблемы с их использованием. Особенно когда те же клиенты показывают где проблема. А Вы продолжаете рассказывать про какие-то шаблоны (могу вообще ничего не знать про них и контроллер с ними - мне это не надо), про какие-то самописанные вами инструменты для этого контроллера, которым вы доверяете - мне они также без надобности. Всегда удобнее пользоваться тем, что широко распространено и просто удобнее, а не разбираться с параметрами командной строки какой-нибудь вашей программной затычки. Поскольку далеко не только ваши устройства могут быть использованы и их тоже бывает надо отлаживать. И что интересно - вам самим было бы проще без изобретения очередных граблей. Если не знаете что имеется ввиду под byte swap - изучайте общепринятое, а не плодите собственные представления и термины, вызывая путаницу. Не сомневаюсь, что именно это и реализовано в том, о чем я уже выше говорил. Byte and Word Swapping in Modbus Извините, наболело… раньше постоянно сидел на этом форуме, решая регулярно возникающие проблемы… пока не послал лесом то, что их создавало. Ну вот опять пришлось… хотя проблема эта решаемая. Ну и ссылка что Вы дали - скорее из той же серии - проблемы совместимости на уровне документации. Все, завершаю излияние эмоций. Железка нормальная, наверное еще одну куплю.
Это - более конструктивно.
Итак есть 4 регистра, по порядку, от младшего к старшему адресам нумерации регистров октеты обозначил буквами:
0xabcd 0xefgh 0xijkl 0xmnop
В соответствии с нашей документацией для того чтобы получить действительное значение при хранении в виде LE следует собрать:
0xmnop ijkl efgh abcd
Все. Четыре регистра читаются наоборот. Не нужно ничего в словах переставлять, просто располагаем значения регистров в low-endian порядке.
То что вы пишете - это совершенно общие призывы “за все хорошее”. Что именно делают “инструменты” при выборе показанной вами операции “byte swap”? Как именно переставяют байты? Это не документировано.
У нашего контроллера все используемое ПО - открыто и исходники лежат в репозиториях. Если для вас он неудобен - я сожалею.
Ок, про шаблоне не надо… В документации - описано как именно работать с регистрами. С примерами. Если вы считаете что что терминология использована неверно напишите как по-вашему правильно. По моему если регистр с бОльшим адресом содержит старшую часть числа - это low endian. Это еще в школе преподавали ЕМНИП на информатике.
Это база… если я вижу четыре uint LE я беру указатель на его младшую часть и декрементирую.
Обратите внимание, особо указано:
При этом порядок двух **байт** внутри одного 16-битного регистра всегда прямой, в соответствии со стандартом.
Так что никаких “swap”
Не знать досконально используемый инструмент? Можно…
Я предлагал прочитать именно байты ответа устройства. Именно байты, которые точно расположены в определенном протоколом порядке.
Какой для этого иснструмент использовать - дело вкуса.
Ок, вы лучше меня знаете что под этим понимали авторы используемой вами программы.
Ссылка на стандарт: https://modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf
В нем есть хоть где-то о перестановке байт в регистре? Да, производители устройств могут трактовать как угодно значения. О том как трактуем мы - прямо сказано в описании.
Ну и, если у нас описано неудачно - предложите как сделать лучше.
В соответствии с нашей документацией для того чтобы получить действительное значение при хранении в виде LE следует собрать:
0xmnop ijkl efgh abcd
Это Вы правильно уточнили, что “вашей документацией”. А вот из IoBroker:
uint64le-Unsigned 64 bit (Little Endian): AABBCCDDEEFFGGHH => HHGGFFEEDDCCBBAA
Можете сами ознакомиться с полной версией и на основании чего сделан такой выбор. Не помню чтобы кто-то жаловался из пользователей в issues. Просьб расширить варианты представлений - это сколько угодно. Как видно из общего списка - не все комбинации представления регистров имеются. Понятно, что это экзотика.
https://github.com/ioBroker/ioBroker.modbus/blob/master/README.md
Отличие сразу видно. И понятно что надо делать перестановку байтов, чтобы то что отдает счетчик нормально представилось при считывании расширенного регистра. Вообщем-то я это быстро понял, как и понял что для этого надо делать. Что делает Modbus poll искать лень, но не припомню чтобы были разночтения с IoB. Поэтому и использую сие для отладки. То есть получается что под одним термином имеет место быть разное понимание. Кто прав судить не буду, но повторяю, что не припомню чтобы кто-то жаловался на то, чем я пользуюсь. И подозреваю, что таких пользователей по миру (особенно Modbus poll) сильно больше, чем пользователей WB.
У нашего контроллера все используемое ПО - открыто и исходники лежат в репозиториях. Если для вас он неудобен - я сожалею.
Ровно то же и IoBroker. Неудобен - да. Очень замороченное управление. Совершенно не интуитивное. Постоянно приходилось лазать по разным докам. Функционально бедно. И что самое важное - по сути обычный линукс на недокомпьютере, низкопроизводительном и с повышенным риском отказов. Да еще и покупать надо. Я в итоге пришел к пониманию, что мне проще разворачивать виртуальные машины, мигрировать их, бэкапировать и делать все что угодно с ними без малейшего риска что все сломается. Всегда можно вернуться назад и довольно быстро. Или перенести туда, куда надо. Да и наплодить столько, сколько надо для резных тестов и проверок. Контроллер этот наверное интересен там, где вообще ничего нет и такой минимум со всеми рисками лучше, чем разворачивать полноценную инфраструктуру. Хотя и это не факт… вообщем-то гипервизор можно поднять практически на любом PC, можно даже с размером не сильно больше вашего контроллера (и что совсем смешно - даже дешевле). И при этом получить выигрыш во всем и ничего не потерять. Ну а удобство и стабильность софта, в данном случае IoBroker - могу подтвердить личным опытом более 5 лет. И теперь мне ничего не хочется менять, уже давно только расширяю функционал через добавление разных устройств, которых накопилось уже несколько десятков с уникальными ID. И это только модбас, а еще и не модбасы есть… Вообщем-то то, что люди покупают подобные контроллеры - это скорее от стереотипа “контроллер всегда надежнее” и “с контроллером проще, чем устанавливать все с нуля самому”. Увы… по-моему это вообще тупиковый путь. И, кстати, что мешает сделать версию своего контроллерного софта для установки на любое железо с линуксом? Он же у вас с открытым кодом…
В документации - описано как именно работать с регистрами.
Да, там у вас много слов… которые нужны (и то не факт) только под специфику контроллера. Со всеми разными заморочками. На деле же для устройства с модбасом достаточно перечня регистров с их значением. Это у вас есть. И хорошо. Остальное на самом деле - мусор, затрудняющий реализацию проектов.
Не знать досконально используемый инструмент? Можно…
Да запросто! Вы же не задумываетесь над тем как ток течет в проводах и где провода те лежат при включении света… Это то же самое. Экономить время - правильно. Для этого нужны удобные инструменты, позволяющие это делать. Но, к сожалению, случается что инструмент сделан или описан неверно, тогда приходится углубляться - это потери времени. Вы еще предложите изучить архитектуру микроконтроллера что там стоит и методов написания прошивок для него. 
Да, производители устройств могут трактовать как угодно значения.
Не уверен что так и есть (в смысле “могут”), но на лицо именно такой факт. Вообще-то на то стандарты и придумали в самых разных сферах деятельности, чтобы подобного бардака не было.
Вот про риск отказов - интересно. Контроллере вполне работают годами в промышленных условиях.
А Home Assistaint не рассматривали? Он, пожалуй удобнее будет, к тому ж изначально в контейнере.
Докер лучше - меньше накладных расходов.
Если не трогать и не обновлять - есть шанс что проработает годами и при этом с примитивной конфигурацией. Мой личный опыт показал что его надежность оказалась значительно хуже виртуальной машины. Даже если не трогать - случались отвалы и зависания, требующие вмешательства. Ну а если обновление - то риски сильно повышаются. Вообщем-то на промышленный PLC оно слабо тянет, линкус внутри создает больше возможностей, но и влечет за собой много рисков. Ну и если действительно нужны возможности - то нахрена вообще эта убогая железка? Вообщем-то по сути это уже мало отличается от какой-нибудь малинки с вечным бета-тестированием. Ну а IoBroker сначала появился как приложение к WB контроллеру, поскольку визуализация у WB никакая. А потом с удивлением увидел, что с виртуалкой работает куда надежнее, проще и удобнее. И ничуть не медленнее. И стал постепенно переносить туда все, что уже было сделано с контроллером. Когда почти закончил - контроллер сдох. HA на тот момент был в зачаточном состоянии. Смотрел - не понравился, позднее ради любопытства еще поглядывал… прежде всего не нравится его возможность визуализации. SCADA-подобный VIS мне куда приятнее. Хотя с ним и больше возни на освоении и реализацию “как тебе надо”. В НА вроде говорят тоже можно сделать что хочешь, но это уже сопряжено с прямым html программированием. Что менее удобно. Ну а вообще - использование долгие годы IoBroker просто не вызывает желания искать что-то еще. Все устраивает и главное - стабильно работает. Регулярно чего-нибудь туда добавляю новенького в зависимости от появления идей и фантазии. Но если вообще - HA вполне интересный выбор и вроде даже там коммьюнити значительно побольше, чем у IoBroker, что большой плюс к выбору.
Докер - это примитивная имитация виртуальной машины. Попробуйте там поднять виртуальный микротик или винду… А оно тоже мне надо. Вообщем-то у меня вообще все виртуализировано. И такой подход все равно привел бы к отказу и от контроллера, даже если бы он замечательно работал - лишняя сущность, к тому же с дополнительными рисками из-за привязки к железке и невозможности быстро решать вопросы минимизации проблем бэкапами, снапшотами и тп. Ну а накладные расходы… как-то уже глупо экономить оперативную память - она стоит недорого. Я использую ESXi в том числе и по причине привычности. Проще, удобнее, но все же лучше под это использовать полноценное серверное железо, а не десктопный PC. Хотя и на последнем скорее всего получится заставить работать. Я, к примеру, недавно пробовал поднимать 8 ESXi на китайском безвентиляторном целероне, купленном на Али в конце прошлого года чуть дороже 7т.р… 64Г памяти и SSD nvme - вполне работало… но отсутствие IPMI, что есть на специализированных серверах, создает заметные неудобства. Кроме того, целерон - вообщем-то довольно ущербный процессор. В качестве основного у меня фирменный сервер от супермикры на процессоре C3758. Для дома - идеальное решение, но не дешевое (и нифига цена на них не падает, в отличие от тех же ксеонов), уже лет 5 работает, причем на балконе, где температура за год меняется от 0 до 30 по цельсию. И что радует - уже по умолчанию есть DC питание (у меня бесперебойник DC) 12V и низкое потребление в обычном режиме - где-то 1,5А всего… то есть и с энергетической точки зрения это выгодно, по сравнению с использованием кучи отдельных специализированных железок. Ну и в резерве есть выключенные сервера на случай выхода основного железа из строя или необходимости апгрейдов - перенос занимает какие-то минуты. Вообще вся автоматика (которой уже много) + вся сетевая часть (среди чего несколько коммутаторов, в том числе и 2 по 24 порта) потребляет где-то 110вт. Что вполне приемлемо даже при росте цен на ЭЭ.
Тема перешла в разряд филосовских — закрываю.
Рекомендации по чтению регистров энергии, формате и порядке описаны в Вики: WB-MAP12E: измеряемые и вычисляемые величины — Wiren Board