Jump to content

    

abcalex12

Участник
  • Content Count

    25
  • Joined

  • Last visited

Community Reputation

0 Обычный

About abcalex12

  • Rank
    Участник

Информация

  • Город
    Array

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Да, я не пробовал HiveMQ, поэтому и "вроде". Я имел в виду их систему плагинов, куда проброшены колбеки на разные события: https://github.com/hivemq/hivemq-database-example-plugin Бизнес логика -- там, где делается выборка из базы, очевидно. Оно же у ТС все конфигурируемое. Что, на новую хотелку пользователя менять схему?
  2. Проблема не в базе. Со старыми локальными файлами-то что делать? либо скрипт должен их с системы удалять, либо начинать всегда писать все с самого начала, либо запоминать состояние. Или вычитывать timestamp, как-то колдовать вокруг этого значения, и надеяться что никакая запись не продолбается.
  3. Ну так.. если новые данные все время посылаются, то скрип должен следить за тем, что уже залито (или спрашивать у базы). Разбирать всевозможные отлупы от базы. Надо, чтобы были права прописать это в systemd (или крон для олдфагов). Те наверное да, 50-100 строк на питоне или жабе. Неизвестно, с какой оперативностью надо данные обновлять, и сколько их.
  4. Без труда -- собственно в брокер MQTT. Далее, нужна фигня которая будет подписана на определенные топики, и получив сообщения будет класть их в базу. Это может быть самописный бридж(коннектор, кто как называет), или плагин к брокеру если брокер сильно умный(HiveMQ вроде такое имеет, что там с лицензией хз). Бридж довольно прост: как получили сообщение, так засунули его в базу. Примеров много, люди часто такое делают. Про mqtt в приборе, надо понять где будет открытый интернет, и как там быть с аутентификацией и ssl.
  5. На мой взгляд, да. в п.2) надо(очевидно), чтобы все устройства знали, куда пересылать данные. Часто для этого используют паттерн publish/subscribe, он же брокер сообщений. Те некая более-менее публичная штука, куда все кому надо шлют -- и оттуда же все, кому интересно, читают. Там внутри часто очередь. Хотя и не обязательно (те если сообщение никто не вычитал, оно пропало). Также, часто берут какой нить стандартный протокол вроде MQTT. Для него обычно полно реализаций как для дивайса, так и для напихивания в базу.
  6. вот тут обсуждают например https://physics.stackexchange.com/questions/374747/does-temperature-affect-the-index-of-refraction#:~:text=2 Answers&text=Refractive index does not change,of a change in density.&text=If density is kept the,no change in refractive index.
  7. Да, Grafana опенсорсный продукт, работает с разными базами в кач. источника данных, в тч и с традиционными реляционными. Это можно поставить на компе. Насчет гео-фич не уверен, есть ли. У них также есть сервис -- облако с всем их хозяйством. Возможно, это почти то, что вам нужно. Но что-то, специфичное для ваших устройств, написать придется. https://grafana.com/products/cloud/#pricing PS какие-то гео-плагины есть.
  8. Я бы смотрел на IoT в исполнении Amazon, Microsoft и тп. Забирать из файла вариант нынче маргинальный, думаю что большинство вендоров будут ждать посылки сообщений в свое облако. Хотя всегда можно написать "коннектор" который вычитает ваш файл, но это уже не то zero configuration которое вы хотите. Отображения временных срезов, "правила" по которым триггерятся разные события (ваш 3)), гео-опции скорее всего есть. Ключевые слова IoT, time-series database, grafana (это такая платформа мониторинга, рисования картинок и тп. Сейчас популярна и много где применяется) Насчет совсем без настройки сомневаюсь правда. Возможно придется склеить пару продуктов вместе. Да, никакого локального GUI пользователя это все не предусматривает, смотреть в браузере. В лучшем случае будет мобильное приложение.
  9. Интересно. Ващет ширина запрещенной зоны у Al2O3 немаленькая, ок 7eV. Много надо дополнительнх носителей. У такого процесса должна бы быть сильная температурная зависимость. Где-нибудь при криотемпературах, например, это должно работать гораздо хуже. А откуда избыток кислорода?
  10. Туннельный эффект -- да, забыл. Неужели на нем и держится вся "наука о контактах"(с)? потрясающе. Про пасту -- это способ сделать контакт с алюминием лучше. Я хочу понять, почему он вообще есть.
  11. Может, вопрос не совсем в ту рубрику, но.. Вот есть алюминиевая деталь, корпус/радиатор или еще чего. И, например, для электробезопасности мы это дело заземляем. Как известно, алюминий на воздухе образует оксид очень быстро. И этот оксид, вообще-то, изолятор. Ну хорошо, пусть в деталь закручен винт, или шайба с царапками есть. Понятно что оксид разрушается в момент создания механического соединения. Но потом все равно же окислится. Как вообще работает электрический контакт с алюминием? В голову приходят три варианта -- в точку контакта воздух все же не попадает; в точке контакта образуется проводящее химическое соединение (интерметаллид -- но они точно не все проводники); оксид образуется но пленка тонкая и пробивается любым практическим напряжением. Как оно на самом деле?
  12. Мировой эспрессо-разум не согласен по поводу ПИДа. Ну может на хороших машинах с большим баком и отдельным бачком для пара и можно без, но вот у меня -- бойлер на 100 мл (даже не 120 как я думал), и киловаттная грелка. Процесс бодрый --- там же, как кофе делаешь, в бойлер холодная вода идет. Одна чашка -- грамм 30 минимум. Я всунул ds-ку пока для мониторинга -- и видно что штатный биметаллический термостат быстрее. Но также видно, что с его гистерезисом температура качается от 80 до 100 градусов в покое, и до 110 когда делается кофе и вливается холодная вода(термостат смонтирован рядом со впуском). Ну это температура стенки бака конечно, всунуть датчик внутрь и узнать всю правду пока кажется нереальным. А у эспрессо ну пара градусов толерантность, при большем отклонении вкус сильно меняется. Так что, конечно, главная цель ПИД к эспрессо -- стабильная отработка уставки. По хорошему же не просто ПИД нужен, а с feedforward. Чтобы компенсировать поступление воды.