ПО мониторинга и управления МАП и MPPT linux. ПАК "МАЛИНА"

РЕКЛАМА НА ФОРУМХАУС

Добрый день, уважаемый @Osolemio.
Решил я сделать аккумуляторам КТЦ на ночь. Малина 4.01. Проверил погоду на следующий день и на ночь отключил сеть. Сделал первый скриншот. Утром оказалось, что счетчик А*ч не работает Печально, но не критично. Сделал второй скриншот и пошел за обновлениями. Накатил 4.02. Сделал третий скриншот. Так и не захотел он у меня считать потраченные А*ч.
Скриншот перед КТЦ


Скриншот с утра


Скриншот после обновления до версии 4.02


Подключил сеть и включил КЭС для начала заряда аккумуляторов и вкладка ПРИБОРЫ перестала отображать текущую ситуацию. Перегружал малину и перезапуска сервисы- не помогло. Во вкладке ТЕКСТ параметры отображаются.

 

Уважаемые, прикручиваю МАЛИНУ к такому общедоступному китайскому инвертору Power Star W7 3х-кВт. У него есть выносная панель, которой можно управлять, но данных с неё собирать вроде как нельзя. Зато есть встроенная ЖК панелька, к которой идут 4 провода. Очень похоже на RS232 - два питания, TX, RX. Хочу попробовать к ним подключиться и увидеть что-нибудь. Кто-то с этим уже сталкивался? Пробовал?

В любом случае, к малине будет подключен BMV-700 и такая плата https://openenergymonitor.org/emon/modules/emonTxV3

Вообще, что вам умным товарищам стоит дом построить. Найти бы переферию, датчики тока - и любой инвертор, контроллер, система может быть подключена к малине...

 

Интерфейс вкладки ПРИБОРЫ завелся. Этот вопрос снимается.

 

Уважаемый @Alexx11,

Он не работает у вас.
Вас не смущало, что верхняя батарея не зеленая, а пустая? Это значит что вы не синхронизировали данные монитора с состоянием батареи вручную, и автоматической синхронизации на 100% тоже не происходило. Либо по причине отсутствия заряда, либо из-за неверных настроек
Не вижу сислог. Там может быть вообще батарейный монитор стартовать не может.
Все счетчики прекрасно работают на 4.02.
Разберитесь, пожалуйста, наконец, с настройками батарейного монитора. Это сложная штука, не отрицаю, и настроек много. Но и инструкция подробнейшая (кстати, они все обновлены)
КТЦ надо начинать делать, когда вы видите четко, что монитор работает и все правильно настроено.
А так - у вас батарея в%% по нулям. БМ даже % заряда не откуда взять начальный.
Если сами не справляетесь - напишите мне в личку какая батарея у вас, и данные для входа в настройки. Я запущу все за пару минут

 

Благодаря неудавшемуся КТЦ @Alexx11
Нашлась еще одна ошибка. Не записывались данные настройки БМ
Апостроф не напечатался, когда локализацию делал.
Поправил это, и датчик тока по графикам по отзыву @Demandrei
На самом деле в обоих случаях только по ДТ1 строился график. Копипаст же наше все А потом не исправил
Обновил update_4.02.sig
Ищем ошибки дальше.

 

Господа, всем напоминаю еще раз
Пожалуйста, посматривайте иногда в сислог.
Идеальный сислог - почти пустой. С редкими системными сообщениями
Если видны ошибки, либо постоянные попытки старта демона - что-то не так.
Если батарейный монитор пробует стартовать все время - проверяйте настройки и читайте инструкции!

 

Сейчас посмотрел syslog (вообще никогда не заглядывал), сообщений немного, чаще всего повторяется примерно такое
Transfer to device 7 endpoint 0x1 frame 1548 failed - FIQ reported NYET. Data may have been lost.
За сегодня таких пять штук накопилось.
Не подскажете что происходит? Какие-то данные могут быть утеряны, может флешка опять умирает?
С виду все работает четко

 

Нет. Это нормальное сообщение. Иногда по ком порту ошибки. Вот это они.
И еще бывает can't read pid ...
Это тоже нормально. Поговаривают, что баг ядра линукс

 

Добрый день форумчане. У меня на малине установлен готовый образ 4.01 на флеш накопителе. На первой странице все доходчиво написано. Но как обновить малину до версии 4.02 с помощью файла update_4.02.sig - допереть не способен. Прошу подсказать. Заранее спасибо.

 

Сходить по локальной ссылке /update.html
С версии 4.02 ссылка меняется на update. php

 

@Osolemio, нужна Ваша помощь. перенёс ПО на сервер на базе Ubuntu, подключение к контроллеру MPPT осуществляю через виртуальный com-порт (преобразователь com-Ethernet). Проблема в том что продолжительность работы данной схемы не превышает одного часа, после обрыва требуется перезапуск mpptd. Может быть подскажете что можно подкрутить чтобы повысить стабильность? Как возможно диагностировать причину обрыва соединения?

 

У меня со всеми драйверами, туннелями и ПО с преобразователем ком-эзернет постоянно были затыки. Со своим ПО не проверял. Надобности нет. Это ПО разработано именно для прямого включения. В этом его основной смысл, чтобы чтение было без затыков и realtime. И данные были верны и актуальны, а не отлежавшие в буфере драйвера или адаптора. Я его делал специально, чтобы отказаться от таких адапторов, а вы решили натянуть его обратно Очень плохая идея. Идеологию ПО нарушает.
Заочно ничего не подскажу, я не Вольф Мессинг Но тут явно дело только в канале или прошивке адаптора. На контроллере и так ком-порт время от времени ошибки кидает, а тут с адаптором, да еще и с драйвером виртуального порта - можно ожидать любого гемора.
Отследить может оказаться очень сложно. Начать с анализа пакетов IP, например. Или смотреть сырые данные в/из порта и смотреть где идет непротокольное общение и затык.
Еще раз говорю - тема фиговая и стремная. У меня все тайминги расчитаны на скорость обмена 19200 и прямое включение. У вас могут образоваться непонятные очереди и по батарейному монитору данные тоже теряют актуальность. Ибо задержки в канале TCP/IP - Ethernet могут быть весьма существенны.

 

начать стоит с того, что tcp не гарантирует доставку пакетов раз, их последовательность - два.
плюсом линух не рт система ни разу. можно поупражняться в гугле на тему rt-linux или realtime linux, авось чего и всплывёт.
для проверки можно по-пробовать написать примитивную эхо-систему, которая погоняет через виртуальный ком поверх эзернета туда-сюда пакеты с фиксацией задержек и учётом потерь, потом проанализировать минимальное/максимальное/среднюю температуру

 

И подучить отличие TCP от UDP - три. А потом уже писать - четыре.
TCP гарантирует и доставку, и последовательность, которая определяется битами с 32 по 96 пакета TCP в двух полях. Ибо разрабатывался на случай ядерной войны. А вот пролежать пакет может долго в ожидании переотправки предыдущего.

Нигде не говорилось, что линукс - рт система. Это раз. Говорилось про разницу в чтении/записи
В масштабах МАЛИНЫ, с ее настройками и допусками - там все вполне себе происходит с заданными временными допусками и ничего большего совершенно не нужно.

Ваш совет про гоняние пакетов можно сразу выкидывать. Ибо речь идет о коммуникации с контроллером, где свой протокол обмена по ком-порту, который иногда глючит и идет некорректный поток данных. А гоняние пакетов между двумя устройствами почти ничего не покажет Кроме массы ненужных данных

 

Я смотрю показания с малины через браузер. Прошу прощения, но где именно и как можно сходить по ссылке? Судя по всему, я совсем темный...