Панове,
Поставив датчик CO2 для моніторингу рівня на CO2 на лоджії™©®. Працює, випльовує акуратні json такого виду
{ "ppm":971,"ppm3":945 }
де ppm — дані CO2 через UART, ppm3 — дані через PWM.
Підключено до orange pi, там читається і надсилається сповіщення, якщо більше тисячі. Там же крутиться мікросайт. Як би прикрутити графіки CO2 без використання бази?
Складывайте данные в VictoriaMetrics и стройте графики с помощью Grafana.
VictoriaMetrics должна работать на Orange PI — см. эти доки. Также есть готовые Docker images для arm и arm64. Данные в VM можно записывать по любому из поддерживаемых протоколов:
Вертай на сервер в POST те, що вже є на клієнті, додавай наступне з міткою часу, видаляй перше (якщо потрібне обмеження в 5 МБ з-за localStorage), повертай як результат POSTу. Клієнт за мітками часу зобразить це як годиться. Зберігай це в localStorage. Можна не повертати, якщо серверу не потрібна історія для якихось обчислень.
Це якщо робити рєал-тайм моніторінг. Накшталт вісить підключення десь і малює картинку. Щодо історичних даних.. А вони потрібні на балконі? )) Ну, можна sqlite спробувати для зручності. Той же файл, тільки з драйвером.
PS Ідея с гітхабом від Senseye — норм.
20 лет назад мы использовали простенький SNMP плагин + MRTG ( oss.oetiker.ch/mrtg ) и горя не знали.
Node + grpc(streaming), на клиенте grpc-web + d3.js.
Як би прикрутити графіки CO2 без використання бази?
Хранить массив в RAM? А что мешает базу поставить на жирный одноплатник? это ведь целый полноценный сервер, а не мк... особенно если там жирный борд с sata ssd.
Та можно сразу дату в html документ через XSLT писать. Заодно и кофе всегда тёплый будет
Заодно и кофе всегда тёплый будет
ага, будет, если еще нейросети там обучать.
Навіщо? Колись так зробив, зберігав дані з датчиків температури/вологості у базі (sqlite), за рік-другий база розпухла до непристойності, прибив, тепер показує поточну температуру, та й по всьому. SATA я бачив хіба в Banana Pi, і то в перших моделях, зараз обходяться USB.
Колись так зробив
Тогда вообще ничего не понятно- от данных распухает что угодно, что база, что файл :) Какие тут варианты? Либо у себя хранить, либо взять бесплатное (или не очень) облако (DynamoDB) и туда лить, либо хранить ограниченное количество данных, а не за все года :) Памяти нынче завались, SD карты жирные.
В OrangePi давно была модель с SATA около 35-40$, кажется это был Orange Pi Plus. Может уже и выпилили, хотя вряд ли там usb3.0 завезли.
Крути сайт на виртуалке в облаке, туда же шли телеметрию с edge девайсов и сохраняй там же в «базу». Будет стоит пару десятков баксов в месяц.
Якщо для мобла то є блінк — duckduckgo.com/...raph&iax=images&ia=images
Без базы не круто. Реальные пацаны делают ИнфлаксДБ с телеграфом, и шоб развернуто все в кубернетисе через хелмы с питоногм и нампаем, шоб датасаенц сразу крутить...
Можеш зберігати JSON на GitHub а сайт розмістити на Netlify і при комітах в GitHub сайт на Netlify буде також оновлюватись, така схема вже рік працює для сайту devspace.com.ua
Не дуже розумію, що означає «без бази», але класну бібліотеку для графіків можу підкинути: Plotly. Точно є API для Python i JS, багато різних видів графіків. Я нею користуюся, щоб різні візуалізації для студентів робити.
А зачем тебе база? Тупо пиши в текстовый файл максимальное или среднее показание за какой-то период. А там уже на кроне напиши обработку минутных файлов в часовой, часовых — в
Суть проста: этот файл должен или быть готовой кормёжкой для скрипта отрисовки графиков, или же парситься на стороне сервера или клиента в удобоворимую форму.
То есть грубо говоря ты имеешь записанные наборы данных за последнюю минуту, 5 минут, 20 минут, час, 6 часов, сутки, возможно недели. И график строится прямо по этим данным, они у тебя уже в агрегированном состоянии. А минутные данные за прошлый час ты просто не хранишь нигде, они тебе триста лет не нужны, тебе нужны средние или пиковые значения.
Естественно, ты можешь использовать базу данных на примитивных движках типа SQLite. Но как по мне, это лишнее.
Кстати, хочешь открытий чудных — поставь датчик возле комнатных растений.
Є кільканадцять способів зробити подібні речі. Нативно вони звуться кронтабами. А от чи професійно робити на мікросерверах саме крон — чом би й ні? Цей «продакшен» має свою вузьку задачу та розрахований саме на це навантаження.
Я тут адмін локалхоста, так що можна )
Зроблю так: баш-скрипт читатиме, зберігатиме в теку в /tmp, яке в RAM.
Крон-завдання раз на годину видалятиме файли старіше години.
і 2 http-ендпойнти, поточне значення (файл з найновішою міткою часу фс) та всі значення за останню годину (склейка файлів за останню годину за мітками часу фс).
Далі вже робота epochjs.github.io/epoch/real-time
Тільки нащо це? Яж казав, роби одразу агрегати і викидай те, що застаріло. Писати в /tmp розумно, а от чи втрачати дані при перезавантажнні — гадай сам. Я не бачу резону втрачати, тобто файли агрегатів, де одиниця виміру 1 година та більше, можеш писати в реальні файли на файлову систему. Але вже після того, як оттестиш в /tmp.
Вигода в тому, що агреговані дані доступні миттєво для побудови графіку, і це не створює навантаження. А фоновий процес зробить усе інше.
Неочевидний момент: дані мають бути потоковими, де елемент даних має свій чітко визначений термінатор. Щоб один запоротий запис не зробив недоступними усі інші. CSV формат найбільш поширений в таких задачах.
Ось така є бібліотека, теоретично її можна якось прикрутити
epochjs.github.io/epoch/real-time
Aliaksandr Valialkin
Dmytro Shchurov
Mike Gorchak
Dmitriy Onykyyenko
Dmitriy Mozgovoy
Armin Van Tubin
Dmitriy Mozgovoy
Armin Van Tubin
Дмитро Думанський
Grez
Senseye
Senseye
Tymchyshyn Vitalii
Олексій Пєніє
Maxx
Олексій Пєніє
Sergii Voloshyn
23 комментария
Добавить комментарий Подписаться на комментарииОтписаться от комментариев