РЕКЛАМА НА ФОРУМХАУС А в автоматике дома достаточно холодного резерва. Самое сложное - не забывать периодически проверять, что он работает. Самое гнусное - невозможность сделать резерв кинетика, контроллера в меш-сети
Хотя, впрочем, чему нас почти 30 лет назад учили в институте я и тогда знал плохо - прогулял все что можно и что нельзя прогуливать было
RRD позволяет хранить любую детализацию сколь угодно долго. и автоматически получать меньшее "разрешение". Это индивидуально задается при создании БД. для каждого параметра. Любой срез хранимых данные можно вычитывать в csv (легко конвертировать в xml/json), можно сразу рисовать графики в png.
Если это надо заказчику - это все отлично. Но если не надо, то заявление, что "sqlite плох всем, а RRD-победитель" это, извините, глупость. Потому что можно снижать "разрешение" у показаний датчиков, статистики, но нельзя у событий.
В норме разрешение не снижается "само". это дополнительная функция, которую нужно включать специально, отдельно для каждой колонки (источника данных).
Как говорится, "хум хау" (С). У меня увлечение rrd - подобными игрушками прошло как-то быстро. Был опыт по работе со всякими mrtg, prtg, cacti (была самая популярная, пока не подняли zabbix) и т. д. Но довольно быстро я уперся во всякие ограничения, и перешел на специализированные TSDB (БД временных рядов). Типа InfluxDB, Prometheus, Victoriametrics и подобные
Любая СУБД это просто инструмент, и нет тут места увлечению чем-то или поиска самой наилучшей. Что лучше годится здесь и сейчас, более знакомо или лучше подходит, тем и пользуемся.
Что значит "избыточно", если пользователь HA имеет поддержку InfluxDB из коробки и инструкцию по ее установке, и перейдя на нее получает плюшки. А SQLite, который "плох всем", внезапно вообще не требует никаких усилий по развертыванию в случае HA (да и не только HA), и бонусом позволяет себя бекапить тупым копированием во время работы. Какие-то религиозные терки там, где место только здравому техническому цинизму.
Избыточно. Но не более избыточно, чем RRD. Я так думаю! (С) P. S. Система мониторинга от источника данных, например, mqtt до визуализации, типа Grafanа, разворачивается в контейнерах за полчаса. Дольше ТЗ для себя сформулировать
Если time series - то лучше Prometheus конечно же. на работе не могу избавится от InfluxDB - дашборды графаны нарисована на него дофига...
Рисовать из csv\xml\json? Если что то и умеет это делать - то тем более умеет работать нормальным способом без промежуточных трансформаций)
А это смотря какая задача стоит. Иногда тупо удобнее иметь один сравнительно простой инструмент, рисующий графики из json по API, десяток самых разных источников, хранящих данные так-как-им-удобно и методы-конверторы из них в этот самый json, вместо того чтобы разворачивать соответственно десяток хороших мониторинговых систем, из которых нужны только графики...