Привет Всем! Кто нибудь заказывал такой погружной датчик для ёмкостей с водой с унифицированным сигналов 4-20 мА за невероятные 1300 р. Хотя аналоги нашем рынке стоят от 10000..заявленная погрешность 0.5%. Доставка очень долгая, питать надежды на него или это шляпа шляпная?
Привет всем диабетикам
Могу поздравить тех товарищей, кому назначались датчики Libra
Теперь у нас импортозамещение, и будут давать......
не, не российские аналоги (их тупо нету)
а китайское гамно
Не сертифицированное
не проходящее исследования
тупо копия...
наша жизнь государству пох
Все, кто возится с гидропоникой или аэропоникой, знают: китайские TDS-метры с двумя торчащими контактами — штука удобная, но врёт со временем. Контакты окисляются, солевой состав меняет показания, приходится калибровать через раз. Решил попробовать принципиально другой способ — без прямого контакта с жидкостью.
В основе — два ферритовых кольца (тора). Одно передаёт сигнал в жидкость (Tx), второе принимает (Rx). Жидкость работает как часть цепи связи. На Rx ставлю пиковый детектор — дальше уже переменное напряжение выпрямляется, и можно судить о концентрации. Никаких оголённых металлов в растворе — нечему окисляться.
В чём соль технической реализации — пока расписывать не буду, сам ещё в процессе. Но то, что метод в принципе работает, видно уже сейчас.
Это пока предпрототип. Без контакта с электродами. Уже видно изменение амплитуды при добавлении соли в воду. Cам факт работоспособности радует.
Частота на 60 кГц, вольтметр 0,3251В вода - дистиллят
Частота на 60 кГц, вольтметр 0,3413В в дистиллят добавил 10-15 мл обычной воды
Частота на 60 кГц, вольтметр 0,3534В в дистиллят добавил 10-15 мл обычной воды + остатки кофе xD
Сделал схемотехнику + заказал пластины (платы), жду еще, в общем делаю на камне STM32F407VET6 измерительную часть +АЦП (гальво) + ESP32 для MQTT.
Продолжение следует... но не скоро.
продолжение уже скоро)
Вот здесь начинается самое приземленное: не разговоры "как было бы красиво", а конкретный план, на котором нужно расставить все так, чтобы оператор этим пользовался в рабочем сценарии.
Это не абстрактная картинка, а демонстрационный план объекта из проекта EAS, на который нанесены камеры, датчики и точки СКУД.
За основу взят план из демо в проекте использовал с сайта rgsecru (по факту используется реальный план схема здания-территории объекта), а инфраструктура разложена так, как оператору удобно читать объект:
где смотрят камеры;
где стоят датчики (TVOC/температура/влажность);
где критичные точки доступа (двери/ворота/проходы).
Почему это принципиально
Потому что инцидент без привязки к месту - это половина информации. Когда событие сразу "сидит" на точке плана, становится понятно:
что рядом;
какие камеры перекрывают зону;
есть ли по этому месту тревога датчика;
были ли проходы по СКУД до или после события.
И это уже не просто "таблица событий", а полноценная картина.
Как размещены элементы на схеме
Нужна простая логика:
камеры закрывают обзорные точки и коридоры;
датчики ставятся по зонам риска (склады, бытовка, офисы);
СКУД ставится на контрольные входы.
При такой раскладке даже новый оператор за короткое время понимает объект визуально, а не по длинным спискам.
Что это дает в работе оператора
На практике оператор смотрит не "какой id у события", а:
где это произошло;
что было вокруг;
куда быстро перейти дальше.
Схема в таком виде становится рабочим инструментом, а не просто красивым фоном в интерфейсе.
План объекта с маркерами камер, датчиков и СКУД (иллюстрация размещения)
Панель вкладки «Схема (онлайн)»: что реально есть в программе
Ниже — не маркетинг, а элементы интерфейса, которые уже выведены на вкладку «Схема (онлайн)» в веб-админке:
Схема — выпадающий список этажей/планов; «Обновить план» — перезагрузить данные плана.
«Онлайн на схеме» — периодический опрос; рядом интервал (секунды) и при необходимости свой интервал (1–120 с).
«На схеме показывать» — фильтр проходов СКУД на подложке: «Все проходы», «Только допуск», «Только отказ и прочее» (именно этот переключатель часто нужен, чтобы не засорять схему «зелёными» проходами и сосредоточиться на отказах и нестандартных событиях).
«Только проблемы» — флажок: на плане и в списке остаются устройства с активными инцидентами (удобно для обхода объекта «по красному»).
«Серьёзность» — отбор списка проблем: все / Предупреждение / Критично.
Дополнительно в этой же зоне: «Звук при отказе», «Следить за событием (центр на метке)», окно тишины для звука (местное время), быстрые камеры, «Полный экран», автопереключение схем, счётчик «Отказов в сессии» с кнопкой сброса.
Справа от плана — блок «Проблемы» с быстрыми кнопками типа «Датчики» / «Камеры» / «СКУД», «Лента событий» с теми же фильтрами по типу (СКУД / Датчики / Камеры) и подсказкой, что лента учитывает текущий фильтр отображения на схеме.
Панель фильтров и режимов вкладки «Схема (онлайн)» (верхний блок карточки)
Только панель настроек над планом (без списка «Проблемы»). Здесь нет ни устройств, ни интеграций по имени — только фильтры интерфейса.
Тот же экран с включённым «Только проблемы»
Включён «Только проблемы»: на плане и справа остаются открытые инциденты по тем же типам точек, что на разметке — камеры, двери/СКУД, датчики Home Assistant. Надпись про TVOC на карточке — предупреждение по показанию через HA, это не облако MagicAir. Отдельные строки про MagicAir в «Проблемах» появляются только если в базе есть учётная запись/устройство MagicAir (`magicair_*`).
Что на этой вкладке есть кроме самой схемы
Чтобы не было ощущения "просто картинка на плане", важно отдельно назвать реализованные блоки этой же вкладки:
Проблемы — список текущих warning/critical по датчикам и точкам, с быстрым переходом к контексту и фильтром серьёзности.
Лента событий — последние изменения состояния по объекту в хронологии; фильтры СКУД / Датчики / Камеры управляют тем, что попадает в ленту.
События проходов учитываются в фильтре «На схеме показывать» и в ленте.
Именно сочетание плана с этими блоками дает рабочую картину:
на плане видно где;
в «Проблемах» видно насколько критично;
фильтры «Только проблемы» и «Только отказ и прочее» помогают сузить картину до действительно важного.
Схема онлайн: полный экран вкладки (план, проблемы, лента)
Полный вид вкладки «Схема (онлайн)»
Как читать такую схему обычному человеку
Когда оператор впервые открывает схему, ему не нужны сложные термины. Ему нужно быстро понять три вещи:
где это;
что именно там стоит;
куда нажимать, если что-то пошло не так.
Поэтому логика сделана максимально прямой:
камера = вижу картинку;
датчик = вижу текущее состояние и историю;
СКУД-точка = вижу кто проходил и когда.
Даже если оператор не "технарь", через пару минут он начинает уверенно ориентироваться.
Почему используется план объекта, а не условная картинка
Потому что план объекта сразу убирает много ошибок. На условной схеме легко перепутать зоны. На плане объекта оператор узнает помещение так, как оно выглядит в реальности.
Это особенно важно ночью и в стрессовых ситуациях:
оператор видит "тот самый коридор", а не абстрактный прямоугольник;
быстрее связывает событие на экране с реальным местом;
быстрее дает команду на месте.
Небольшой жизненный пример
Допустим, пришла тревога по датчику в зоне склада. Оператор делает по шагам:
Видит датчик на плане, понимает точную зону.
Смотрит ближайшую камеру в этой же зоне.
Проверяет, был ли проход по СКУД рядом с этим временем.
Если нужно, зовет ответственного уже с понятным контекстом.
В разрозненной схеме это обычно занимает больше времени. Когда все точки сведены в один экран, разбор идет заметно быстрее и без лишних переключений.
Почему добавлены подписи и легенда
Иногда кажется, что легенда "мешает". На практике она экономит время новым операторам.
Когда оператор видит:
цвет камеры,
цвет датчика,
метку точки доступа,
он быстрее "въезжает" в логику и меньше делает ошибочных действий.
Это мелочь, но именно из таких мелочей складывается работа без нервов.
Что было бы ошибкой и почему так не делается
Самая частая ошибка - пытаться поставить маркеры "как попало", лишь бы на плане что-то мигало. Тогда оператору кажется, что система есть, но пользы с нее мало.
Здесь работает простое правило: каждая точка на схеме должна отвечать на конкретный вопрос. Если точка не помогает принять решение, значит она там лишняя.
Простой пример правила размещения на плане:
Камера — там и под таким углом, чтобы в обзор попадало то, что нужно проверять при инциденте (подход к двери, перекрёсток коридоров, зона погрузки), а не «точка посередине комнаты ради галочки».
Датчик — в помещении или зоне, где вы действительно следите за климатом/воздухом/утечкой и т.п., то есть там, где есть риск или режим, а не там, где на чертеже симметричнее.
СКУД (дверь, ворота, считыватель) — на реальном проходе людей или транспорта, где выдаётся допуск; маркер ставят у этого прохода, а не «где удобно нарисовать» и не «рядом со столом оператора» — оператор поста к объекту может вообще не выходить.
Тогда схема превращается из "рисунка" в рабочую карту объекта.
В следующей части перейду к тому, как это работает в реальном ритме дежурства: TV Wall, схема онлайн и почему именно связка этих экранов дает скорость, а не хаос.
Всем привет. В принципе речь пойдёт о системе СКУД, видеонаблюдении и системе отслеживания показаний датчиков в одном стакане. Кому тема не интересна думаю и читать не стоит, только зря потратите время.
Да, сейчас много решений «на любой фломастер и кошелёк», но в одной системе одного нет, в другой — другого, в третьей — вроде есть всё, но так «склеено», что пользоваться больно.
Начать, наверное, надо вообще с простого вопроса: с чего вдруг автор решил так заморочиться, чтобы объединить всё это в одно?
В одно прекрасное утро приходит ко мне руководитель и говорит, что «у нас всё как-то несерьёзно». Бабки-охранницы, открывающие ворота, открытые двери — иди куда хочешь, бери что хочешь. Камеры — уже с прошлого века, регистратор такой, что, кажется, ещё динозавров снимал. А мы, говорит, ребята серьёзные, производство как-никак. И вот тебе, говорит, задача:
Нужно внедрить СКУД, чтобы и на территорию, и в здание без пропуска не попасть.
Камер должно стать больше, и совсем плохие заменить.
Датчики температуры восстановить — чтобы работали и записывали данные, которые всегда можно было посмотреть и при необходимости собрать отчёт.
И всё это должно быть отражено на схеме территории и помещений: где что стоит, где происшествия, чтобы всё это — как новогодняя ёлка. Глянул — и сразу увидел, где проблема.
Наверное, самое главное: всё должно быть локальным настолько, что даже датчики, которые «в приложении через интернет», в случае отвала этого самого интернета всё равно продолжили бы работать. Вот прям чтобы обрыв внешней связи не превращал объект в тыкву.
И почесав репу, я полез в интернет…
Не буду пересказывать полностью, сколько времени я потратил и сколько у какой системы плюсов и минусов — не стоит сейчас задача сравнивать, а то будет много букв. Просто тезисно, как оно ощущалось по факту:
Если нужно, чтобы прям СКУД — то забудь про датчики.
Если нужно видеонаблюдение и смотреть, кто ходил в курилку, а кто нет — то можно «СКУД + камеры». Но тогда теряешь нормальную схему и датчики.
Если нужно «умный дом» и красивые датчики — то легко, но «промышленное» видеонаблюдение и нормальный контроль доступа уже как-то мимо кассы.
Если нужно «всё сразу» — либо это огромный дорогущий комбайн от вендора, либо «давайте мы вам допилим под вас», и дальше звучит сумма, от которой хочется уйти в отпуск… лет на пять.
По итогу: полноценного «СКУД + Видеонаблюдение + Датчики + Схема» в одном месте, чтобы это было адекватно по деньгам и при этом работало локально, я не нашёл. А если идти к производителям с просьбой доработать продукт, то суммы получались заоблачные. И самое обидное — не то, что дорого, а то, что ты всё равно привязываешься к чужой логике, чужим ограничениям и чужому «так задумано».
И тут я вспомнил, что лет 10 назад, когда я ещё занимался созданием сайтов, был у меня проект простенького видеорегистратора с веб-мордой и схемой, на которую можно было наносить камеры. Тогда это было сделано «по приколу» и чтобы работало. И вот я подумал: а почему бы не попробовать добавить туда связку СКУД и датчиков?
Что я хотел получить (простыми словами)
Я сформулировал для себя картинку результата:
Открываю веб-страницу — вижу схему объекта (территория, здания, помещения).
На схеме отмечены двери, турникеты/ворота, камеры, датчики.
Любое событие — сразу видно: дверь открылась, проход по карте, тревога, движение по камере, температура улетела, датчик отвалился.
Могу нажать на точку на схеме и провалиться: «показать живую камеру», «показать архив», «показать историю датчика», «кто входил/выходил».
И всё это работает локально, без обязательного интернета. Интернет — это бонус для удалённого доступа, а не «пуповина».
И тогда стало понятно: если делаю сам, то нужен не «комбайн», а нормальная архитектура, где каждая часть делает своё, и где всё можно заменить без боли.
Техническая основа, на которой в итоге вырос EAS
Я не буду делать вид, что сразу всё идеально спроектировал. Нет. Сначала было «чтобы работало», потом «чтобы не ломалось», потом «чтобы можно было поддерживать». Но базовые решения в итоге получились такими:
Сервер: обычный Ubuntu-сервер на объекте (без облаков и магии), всё крутится как сервисы.
API и логика: Python + FastAPI (по сути — быстрый веб-движок), запуск через uvicorn, управление через systemd. Это удобно: сервис поднялся, упал — поднялся, логируется нормально, обновляется аккуратно.
База данных: PostgreSQL. Потому что нужна надёжность, нормальные индексы, понятные транзакции и чтобы потом не плакать, когда данных станет много.
Видеопотоки: отдельная штука для камеры — go2rtc. Он берёт RTSP от камер и отдаёт нормально в веб (HLS/WebRTC), и не надо городить зоопарк плееров и костылей.
Датчики и интеграции: чтобы не изобретать велосипед с «умным домом», используется Home Assistant как слой интеграций (он умеет говорить с кучей датчиков/хабов). EAS забирает оттуда сущности, состояние, события и складывает в свою БД.
Веб-интерфейс: админка — обычный web UI (без сложного SPA-фреймворка ради фреймворка). Главная идея — чтобы мог открыть в браузере хоть с ноутбука охраны, хоть с планшета, и оно работало быстро.
Если по-честному, этот набор технологий не «самый модный», а самый практичный. Мне не нужно было впечатлять конференцию. Мне нужно было, чтобы на объекте это не разваливалось и чтобы любой адекватный инженер мог потом разобраться.
Как я разделил задачу на части
Когда пытаешься сделать «и СКУД, и видео, и датчики, и схему», мозг начинает кипеть. Поэтому я разделил всё на несколько подсистем.
1) Схема (план объекта)
Это центр интерфейса. По сути, это «панель ситуации»: точки на плане, состояния, подсветки, быстрые переходы. Схема не должна быть музейной картинкой — она должна быть рабочей.
2) Видеонаблюдение
Тут важны две вещи:
живой просмотр (желательно без «у меня не открывается, потому что в браузере не тот плагин»),
архив (чтобы можно было быстро промотать и найти момент).
И вот тут очень быстро выясняется, что «просто подключить камеры» — это детский сад. Камеры разные, RTSP иногда капризный, сеть иногда не идеальная, а пользователю всё равно надо «чтобы работало». Поэтому go2rtc стал прям спасением: он берёт на себя роль «прокладки» между камерами и браузером.
3) Датчики
С датчиками похожая история: легко получить показания, сложно сделать так, чтобы потом этим можно было пользоваться. Важны:
история за период,
отчёты,
фильтрация мусора (технические метрики, которые пользователю не нужны),
и самое важное — нормальные имена, которые человек дал датчику, и чтобы они были везде: в списках, графиках, отчётах, выгрузках.
4) СКУД
СКУД — штука «про ответственность»: кто, куда, когда. Здесь нельзя «приблизительно». Нужны события, журнал, привязки, роли, точки доступа, и чтобы это не зависело от «а интернет есть?».
И вот на этом месте я окончательно понял: если система будет завязана на облако — это будет постоянная боль. У охраны нет задачи разбираться, «почему не работает». У них задача — чтобы ворота открывались тем, кому надо, и чтобы на объект не заходили те, кому не надо.
Почему «локально-сперва» — это необходимость
Требование «чтобы без интернета продолжало работать» многим кажется странным, пока не поживёшь на производстве.
Интернет может лечь. Провайдер может «что-то там …..». Роутер может «устать». Электрики могут «поиграть с автоматами». И если в этот момент у тебя СКУД или камеры превращаются в кирпич — это не техническая проблема, это уже организационная.
Поэтому принцип был такой:
всё критичное работает локально;
удалённый доступ — это сверху, как дополнительная возможность;
а данные хранятся так, чтобы потом можно было поднять отчёт «за вчера», «за месяц», «до инцидента», «после инцидента».
Как это всё начало собираться в EAS
Идея «взять старый веб-видеорегистратор и допилить» не быстро превратилась в нормальный проект. Потому что когда начинаешь добавлять СКУД и датчики, выясняется, что:
нужна единая модель объекта (помещения, зоны, точки на плане),
нужна единая система пользователей и прав доступа,
нужна нормальная база и индексация,
нужна админка, в которой можно всё это поддерживать не через консоль,
нужен механизм обновления, чтобы можно было развивать систему, не превращая каждое обновление в «в ночь с пятницы на субботу молимся».
Так и появился EAS (Enterprise Automation System) — по сути, локальная система, которая объединяет видео, события, датчики и логику объекта в одном месте.
И самое интересное, что на бумаге всё звучит просто. А на практике начинается: «вот эта камера почему-то отдаёт не тот RTSP», «вот этот датчик шлёт странные сущности», «вот тут время на сервере уехало», «вот тут график не рисуется», «вот тут отчёт нужен в Excel», «вот тут люди хотят на схеме видеть всё сразу».
Но именно из этих мелочей и рождается нормальная система. Не из презентаций и лозунгов, а из того, что охранник нажал — и оно сработало. Инженер открыл — и понял, что происходит. Руководитель посмотрел — и увидел картину объекта.
На этом, пожалуй, закончу и так очень много букв. Текст прогнал через deepseek так как такой объем самому вычитывать после написания просто лень. В следующих статьях постараюсь углубится и рассказать, как это выглядело изнутри.
Думаю, это будет полезно тем, кто решит так же заморочится и позволит не наступать на грабли используя мой опыт.
Можно заказать на АлиЭкспресс: https://aliexpress.ru/item/12744214044071.html
Приложение у-ва стало падать при подключении к компу флэш-накопителя. Любого.
Необработанное исключение:
System.NullReferenceException: Ссылка на объект не указывает на экземпляр объекта. в DiskInfoToolkit.Storage.IdentifyStorageController() в DiskInfoToolkit.Storage..ctor(String storageController, StorageDevice sdi) в DiskInfoToolkit.StorageManager.HandleUnpartitionedDrive(DeviceChangedModel deviceChangedModel) в DiskInfoToolkit.StorageManager.DevicesChangedListener() в System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) в System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) в System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) в System.Threading.ThreadHelper.ThreadStart()
Ошибка генерилась DiskInfoToolkit.dll
Так как код приложения - опенсорсный, лезем в исходники и вносим изменения.
sensors_librehardwaremonitor.py
from LibreHardwareMonitor import Hardware
...
handle = Hardware.Computer()
...
handle.IsStorageEnabled = False # ---- и всех делов!
Всех с праздниками!
