MЛадно... после того как #collectd, точнее cgi его, отправил систему в глубокие раздумья, все же решился перепилить конфиг. Ok.
Загрузка, память, температуры -- ok, осталось -- df (хотя за сколько лет в место и не упирался, тем не менее). Пару часов, чтобы вспомнить и решить чего надо. Пару часов, чтобы настроить трешхолды и уведомления -- это отдельная песня, матерная.
За смарты висит отдельный smartd с уведомлялкой на почту -- проверил, что отрабатывает. И вот же зараза: работает уже лет 10-15, на факап алертит, внимания не требует -- прямо радует.
Пока все это настраивалось, поглядывал в сторону малинки -- вот прямо туда оно и просится. Уже утомляет ползать по девайсам, чтобы проверить как, что и когда они.
Видимо притащу на домашнюю что-нить из актуального. Когда-нибудь.
Stuart Longland (VK4MSL)More work on the #SolarCluster tonight. Using #Zephyr to bridge between #collectd and some INA219 current shunt monitors.
The code runs on a Raspberry Pi Pico, and enumerates two USB CDC-ACM UART devices. One is a console, the other is a Modbus/RTU slave.
Two things I learned:
1. Your first CDC-ACM UART is easy, but a second one is a royal PITA.
2. Zephyr's Modbus stack assumes you have dedicated callback functions for each and every Modbus unit you create, with no concept of passing a user pointer or a unit ID to the callback function.
I had thought of a scheme where I had 3 units, the unit ID being equal to the I²C address of the slave, and just registers for voltage, current and power (Vshunt is not exposed by the Zephyr driver).
Nope, I've had to use one unit ID, and just offset the register numbers. But, whatever… I have a bridge now. I'll put in some settings interface so I can adjust scaling (the Zephyr driver assumes a shunt with a resistance in whole milliohms, mine is 500µohms) and we should be in business.
Code is a work-in-progress, but you can see it here: https://codeberg.org/sjlongland/modbus-ina219-bridge
DJGummikuhSweet!
A lot of sensors still have wrong values or are not working at all, but it's progress nontheless.
#HomeAssistant #Omnia #CollectD
A lot of sensors still have wrong values or are not working at all, but it's progress nontheless.
#HomeAssistant #Omnia #CollectD
I mentioned `collectd`, that's feeding into InfluxDB and visualised by Grafana.
I plan to write a small Python script that'll read the data recorder on the PMC-512 and pump that into InfluxDB, but in the meantime, this gets me going.
`collectd`'s Modbus plug-in is quite an idiosyncratic beast to get right. I wouldn't recommend it to be honest. Each data point is a separate read. #Grafana #collectd #energy
KadinI use #Grafana as well, to create the dashboard itself.
The underlying data comes mostly from #Prometheus (which pulls data from any software that provides a compatible endpoint, which is a lot of stuff).
To monitor ping times to various servers (and also implicitly, that they are up), I use #collectd running on a couple of VMs.
Prometheus+collectd get me most of the system/server-level data I want on a dashboard.
たこたこ
Serpent7776
AliveDevil
NundrumQuestion for the other #selfhosting fans out there - what are you using to monitor system health and bring it to your attention when something is going wrong. After having a drive go boom, I'm particularly interested in SMART stats and getting ahead of the next failure.
I already have #collectd, #prometheus, and #graphite.