toksoft

Между 820 и 940 для камеры разницы нет. На этих конкретных не проверял, проверял на старых хиках. Разница в том, что на 940 не видно светящегося кристалла. Почти не видно. iVMS-4200 ставил последнюю, с сайта хика. Не считая нескольких корявостей, работает. Если камеры поставить на максимум то тогда наблюдается следующая картина уже на 2х камерах: Не, я понимаю что лучше substreams, но на 5Мр/h264 я могу себе позволить смотреть сразу 8 камер (в интерфейсе DAHUA). Прошивка на регистраторе у меня такая (я в курсе на счет 255): Если есть необходимость доступа к камерам извне, то тогда "ставим птичку": и о чудо, все камеры становятся доступными через регистратор (без перезагрузки): В случае если IP один, и нужно построить компактную систему, то тогда камеры лучше того,- подальше за регистратор. Что касается digital zoom, то таки проблема присутствует: Регион не выделяется. На Dahua все работает: В принципе не критично, думаю если косяк,- то исправят с новой прошивкой. Если попытаться накатить более древнюю прошивку, то "обломается" где-то на 30%. Хоть через интерфейс, хоть через флешку. "WebComponents.exe" у камеры похоже более новый, по крайней мере без update просмотр не работает. Digital Zoom, именно на регистраторе, не работает ни на одном из плагинов. Cisco конечно бэушная,- там кроме вентиляторов и блока питания, редко что-то выходит из строя. Ну разве что пару портов "поджаренные" , но это проверяется за 5 минут. Облако хотелось приспособить для целей совместного наблюдения, т.к. регистратор думаю не потянет более 3-4 live view + просмотр истории. "висит в воздухе" имеется в виду что экран не подключен к RJ45 на стороне камеры. Только через защиту на стороне регистратора (ethernet адаптер) + экран выведен на заземляющий контакт адаптера. Добавлено через 1 час 44 минуты Только что попробовал с FireFox ESR (ftp.mozilla.org/pub/firefox/releases/45.9.0esr/). Показывает прекрасно, нагрузка на процессор судя по всему меньше, но digital zoom по прежнему не работает. Добавлено через 21 минуту Капец какой-то. Только что при нажатой клавише "digital zoom", случайно покрутил колесиком мыши. И ... о чудо,- zoom "нашелся". Наверное еще как-то можно с клавиатуры управлять. Я так привык к интерфейсу DAHUA, где после выбора zoomа нужно было определить мышью зону этого самого zoomа, что даже не думал что у другого вендора может быть иначе. "по дороге" попробовал выгрузить 10мин видео с одной из камер на локальный HDD. ~1Gb. Скорость выгрузки - около 5 мегабайт в секунду (у DAHUA ~1.5Mb). "родной" vsplayer без проблем воспроизводит, причем как прямое, так и реверсное воспроизведение. Smart Player (который DAVы имени DAHUA воспроизводит), так же воспроизводит скачанный MP4 на ура. Какой там кодек в самом контейнере - разбираться сегодня уже лень.

Хозяин я

uafisher успешно продавал и продает свои опыт и знания. Оные у него есть, тут спорить нет смысла. Камеры и регистратор можно купить за "очень дешево", но вот собрать все это хозяйство - это проблема. Можно "не угадать", и тогда расходы удвоятся, если не утроятся. У меня есть некий опыт "c 0", но он пришел нелегко. https://www.stroimdom.com.ua/forum/showthread.php?t=147723 С новой платформой я потратил неделю на понимание, и остановился на POE регистраторе по причине того, что "на сейчас", доступен в наличии только 48 портовая CISCO POE (60$), а это явный перебор для моих задач. Да, вопрос спорный, но я знаю зачем мне это нужно, и как это все запустить. Это морока, причем с с бюджетом более 50000 грн. Одна ошибка - и первая гроза прикончит ваше решение. Если уверены в своих силах, есть знания и время,- тогда можно "выходить на эстакаду".

Хроматизм ессно есть I - это которые 12Мп. Тут уже вопрос не столько к регистратору, сколько к машине, на которой будет воспроизводиться видео. Для моих задач - это явный перебор. В принципе не проблема, разница в стоимости около 1800 грн,- но на обозримое будущее точно не нужно. Камеры мне обошлись по 2500 грн за штуку. В Украине. В Китае - ~1870 гр. Еще не заказал, когда все установлю - определюсь нужен мне фокус 6, 8 или 12. Родные, которые с серийниками, которые принимает хик-облако. В принципе "не родные" меня тоже устроят, я их перешивать не планирую,- где-то 1350грн. Наверное еще потребуются ИК прожекторы,- тут не все так радужно: один прожектор - 24$. Меньше ну никак. И это не 940... 20 fps на 6Mp эти камеры дают, на большее не претендую. h265+ на слабых машинах дает артефакты. Например человек "застрявший" в дверном проеме. Так и висит, пока не отрефрешится путем повторного прохода. 6 камер 24/7 - примерно 6 дней на 4Тб. Дело в том, что preview для всех камер, приезжает в максимальном качестве. Не сильно advanced users пренепременно откроют все камеры, причем не для substream, а именно для main stream На счет переключения камер с честных адресов на POE регистратора, я конечно понял где я ошибся, но по причине ленности, я все-таки предпочитаю factory reset. Инструкция под регистратор, ессно не указывает через какой интерфейс идет управление. Уже когда завел, понял что инструкция "заточена" под HDMI. Монитор цеплять не стал, решил "добить" через WEB. При нажатии "+" в интерфейсе, происходит ничего. Тут ничего нового нет, и как это работает, я могу проверить на своем стареньком DAHUA (спасибо вам за консультации лет 5 назад). Регион не выделяется никакими силами и кнопками. samson.ua подтвердил мое "робкое предположение" что таки придется использовать iVMS-4200. Оно на сайте хика в свободном доступе. Вопрос с логинами/паролями, я для себя решил так: Когда монтажники будут вешать на опоры, я вряд-ли проконтролирую какую камеру где повесили, и при условии разных логинов и паролей, будет большой бардак, посему activation with registrator admin login/pass. Потом посмотрим. Все мои 9 камер висят на деревянных основаниях, connection в коробках OBO. IP67, но все-таки в коробках. Старенький Dahua честно пишет все 24/7, и при этом, как не удивительно, за все это время, оба HDD по прежнему живые. Проблема в том, что теперь новые камеры придется монтировать на столбах как с круглым, так и с прямоугольным профилем. Посмотрел на доступные крепления, и решил путем 3х отверстий монтировать камеры прямо на столб. Может я просто пожадничал ? Ether с тросом имени FTP, традиционно пускаю через разрядники только на стороне регистратора. С обратной стороны оболочку оставляю висеть в воздухе. Доказано временем, что уравнивание потенциалов путем оплетки ethernet кабеля не самая лучшая идея. Проект не коммерческий, кэш мой личный, поэтому считаю очень тщательно С облаком наверное вариант более предпочтительный. Веду переговоры с eagleye и camcloud.com. Двойственное чувство: ненавижу OPEXes, и в то же время понимаю что масштабирования для моей локальной схемы нет, причем от слова совсем.

Получить совет, и поделиться "ощущениями". Возможно кому-то будет полезно. Это нарушение правил, нет ?

Возникла задача закрыть камерами некоторую часть берега Днепра, задумался о старой доброй и проверенной модели с POE Switch, и ... решил попробовать HikVision NVR. Выбрал ds-7608ni-k2/8p. Камеры взял "народные" DS-2CD2063G0-I. С фокусом 4мм. Хотелось бы конечно фокус 8мм, но похоже в Украине нет, или есть (может быть), но по крайне неадекватным ценам. Регистратор изолирует камеры в своей внутренней подсети, но путем виртуального хоста, позволяет через регистратор получить доступ к меню камер. Впервые попробовал h265+ на максимальном качестве. Во первых камеры сами сначала предупредили что часть функций пост обработки будет недоступна, а во вторых, ресурсы машины, с которой ведется просмотр, должны быть явно выше чем мой 4 ядерный 3.2Ghz процессор. На 3х потоках на полном разрешении и максимальном качестве, начало подтормаживать. Остановился на h265, без плюса. Камеры можно подключать как к встроенному в регистратор POE свичу, так и ко внешнему. Ограничение - количество камер (в моем случае 8). Интерфейс регистратора, как мне кажется, поприятнее чем у Dahua. Отдельный вопрос - это "танцы с бубном" после переключения камеры с внешнего адреса, на внутренний регистратор. Проще всего - factory reset камеры. Когда одна камера, то можно конечно поставить разные логины/пароли на регистратор и на камеру, но когда больше 2х, лучше конечно (по крайней мере на время установки) активировать, и поставить логин/пароль админа с регистратора, прямо из меню этого самого регистратора. Работает только с IE (live view/records playback). К Хрому посоветовали приделать extention имени IE TAB,- у меня запустить не получилось. Из "косяков", не работает digital zoom, причем как при просмотре live video, так и при просмотре архивных записей. При автоконфигурировании через регистратор, почему-то по умолчанию выключен WDR, и стоит какой-то уж совсем мрачный white ballence, собсно почему я и потянулся к camera config. В интерфейсе самой камеры, digital zoom работает как часики. Так же работает и в iVMS-4200, а вот в меню IE - никак. Compatibility mode не помогает. Плагины у камеры и у регистратора, похоже разных версий, похоже у камер поновее. Версия прошивки с которой прислали - V3.4.104 build 190128. Такой у них даже на сайте нет. Кроме этих "малозначимых" деталей,- претензий нет. Поскольку доступ к системе предполагается совместный, попробовал Hik облако.Оказалось что это не более чем redirector на адрес регистратора, т.е., насколько я увидел, речи о том, чтобы данные лились в облако, не идет. Встречал на Украинских сайтах фэйки о том, что этот регистратор может писать на google drive, и/или в облако. Не может. Присутствует еще достаточно полезная опция, которая позволяет при обрыве связи и/или при неработоспособности регистратора, буферизировать запись в пределах емкости SD карточки, а потом выливать на регистратор после того, как связь восстановится. Может гуру подскажут какие-то детали ?

Перевод вашего длинного speech для меня выглядит так: Украинскому производителю можно вынести мозг, т.к. спецификации предоставлены не полностью, либо вообще не предоставлены - все "на пальцах", а с китайцами такой номер не проходит. Да, именно так. Если хотите заказать платы и сборку у китайцев, нужно попотеть и предоставить достаточно много спецификаций (на английском), включая инструкции по монтажу и сборке. Исполнят в точности. За последние 5 лет проблем не наблюдалось. Заказывать доработку софта китайцам - это вы конечно выдали ... Вы хоть раз переговоры с китайцами самостоятельно вели, или пересказываете чужой опыт ? Могут кстати сделать (небезплатно) валидацию вашего мегадизайна, на предмет соответствия требованиям EU/US. Нет английского - тогда да, беда непоправимо, тогда приходится покупать телефоны с килоамперными аккумуляторами. Говорят Google иногда помогает, но наверное вас забанили. Вы хоть раз заказывали нормальное тестирование своей продукции, с test cases ? А документацию с китайского производства никогда не получали ? Самое грустное в том, что с большой долей вероятности, вы даже не понимаете смысла того, что я пишу .

Вопрос качества - это не только в линии по пайке, производству плат или комплектующих. Купить сейчас тоже не проблема. Вопрос в процессах. Чтобы получалась продукция аналогичная китайской, нужна лавка с построенными процессами, и без "народного творчества". Китайцы народ достаточно дисциплинированный, посему они способны работать на конвеере, и разрабатывать, скажем, свои самолеты. В Украинских условиях, мало того что работа в основном ручная (как в 19м веке, только с использованием технологий 21го), так еще и исполнительская дисциплина страдает. Почти всегда. Даже если есть самый навороченный аппарат, который способен минимизировать человеческую ошибку, "умелые руки" местных специалистов, с вероятностью 99% что-то накосячат. Или как минимум, проскипают какой-то из "кажущихся необязательным" этапов производства. Посему "местные легенды об ужасном Китае" - это не более чем оправдание своей криворукости, и неумения строить процессы. Сейчас, практически любой промышленный (или массово произведенный) китайский товар, на порядок, если не больше, превосходит Украинские поделки. Компания из дяди Васи и Пети, которые "договорились выпускать массово" скажем, систему сигнализации, максимум толкнет идею, и выполнит первоначальную разработку, а все производство будет выполняться там, где построены процессы, которые позволяют массово продавать, и потом не рассказывать сказки о том что "есть голимый Китай", выслушивая претензии клиентов. Кроме того, R&D в наших, Украинских реалиях - это "обнять и плакать". То есть оного практически нет. Если есть, то как часть лавки, головной офис который находится далеко, и которые способны инвестировать в исследования и разработки, координируя при этом деятельность нескольких команд. Так что увы и ах ...

Ужас то какой ... Похоже я так и не понял сути проблемы. Я бы в общем тоже дидой бы перезатер первые секторы, но решил упростить человеку задачу. Руки как-нибудь дойдут, поставлю android, посмотрю. Мой выбор Jessie. desktop я не ставил, сервер работает как часики. 2 вечера танцевал по граблям, но кроме ухода в sleep после shutdown -r now, проблем не осталось. WiFi не отваливается, Еще и потихоньку дошлифовываю WiFi repeater. Придется таки ядро под себя пересобррать на большой машине...

А можно поподробнее, для "чайников" ? Это как "совершенно не так" ? Я реально сталкивался с Android только на телефоне, и из того что я там видел, это Linux. Обвеска другая, драйвера дополнительные, но это таки System V UNIX. Если вы что-то знаете,- не стесняйтесь сказать об этом прямо, думаю всем это будет интересно. Все что попросил человек - это переустановить любую систему, т.к. загрузчики с образов, которые он скачал в первую очередь пытаются загрузить систему (если таковая присутствует) с mmc. А она, блин, присутствует, значит ее нужно прикончить. Пофиг какого типа разделы, ext2, 3,4, FAT, NTFS, что-то еще ... Нужно найти в комплекте Android тулзу, аналогичную fdisk/pdisk/qdisk, запустить ее, удалить раздел, желательно все, прямо на живой системе, сохранить изменения, несмотря на грозные предупреждения и, собсно, все. Какие риски ? Человек случайно грохнет раздел на SD карте. Ну перезапишет образ на компьютере ... В чем собсно проблема ?

Ну тут как бы в 2х словах, я наверное объяснить не сумею. Погуглить Linux fdisk delete partition. Как запустить командную строку (shell) для Android, я не знаю.

Я не ставил Android, но насколько я знаю, это тоже "типа" Linux. Я вижу 2 варианта: 1. Не важно что нет сети, главное что есть возможность запускать приложения. Если хоть что-то загружается с sd, то нужно запустить mount, и посмотреть что куда помаунтилось. Как вариант - добавить в fstab то, что должно помаунтится, но по каким-то причинам не сложилось 2. Вариант "hard core" - запустить fdisk/gdisk, или нечто подобное, и грохнуть partition на mmc, тогда собсно кроме как с карточки загружаться будет неоткуда. Очевидно в конфиге grub стоит опция в первую очередь загружаться с mmc (на скачанных образах)

Нужно перелить образ на sd, вставить карточку в гнездо на плате, и попробовать загрузиться. Признаком того что система (хоть какая-то) загрузилась, будет доступность системы по сети (например ping). HDMI подключен ? Что-либо на экране пишет ?

Я android не ставил, посему до конца не понимаю в чем именно проблема. Если вставить SD,- загружается с SD ? Если да,- то все что нужно сделать,- это загрузиться с SD, и перезатереть загрузочный сектор на mmc, ну или по новой оттрансферить систему с SD (с которой вы загрузились) на mmc.

Не видит путем wifi, через шнурок (ssh/ssh2) тоже не видит ?

Поменял Hiaomi WiFi extender Pro на один из самых простых ASUS RT-12E. Стоимость - 300 грн. Доставка Новой почты ... Эхх... 55 грн. С Укрпоштой имеет смысл иметь дело только для поставок с aliexpress, т.к. дешево. Других преимуществ нет, приходится выбивать посылки. Из плохого - пришлось пожертвовать бесценным гигабитным портом, чтобы подключить оный в режиме AP. Осталось 11 100Mbps POE портов и 2 гигабитных. Кончатся, прижется снова нп local.com.ua покупать еще один маршрутизатор, а это потребление энергии, место в мини-серверной, и тепловыделение. В общем, хотеллось бы выразить благодарность авторам прошивки Xiaomi Extender, т.к. без них, я бы вряд-ли смог организовать такую бардачеллу, с целью проверить как будет вести себя фрагмент системы, при постоянно отваливающемся коннекте. С Xiaomi extender, картина выглядела так: [/url] То есть каждые 5 минут. DHCP settings на главном роутере в учет не брались, т.е. причина была не в них. Если навести фокус на лог, ту станет понятно, что некоторое время, причем каждые 5 минут, устройства находились в offline, т.е. не были приконнекчены к точке доступа. Это, если посмотреть с практической стороны, затрудняет, а скорее полностью исключает возможность работы с MQTT. Зачем вообще при таких раскладах MQTT ? В моих реалиях - дистанционный мониторинн и управление, ну и "продвинутые сценарии", которые достаточно проблематично реализовать на каждом из контроллеров, по причине ограниченного объема памяти (причем уже как RAM, так и EEPPROM). Сами устройства самодостаточны, т.е. "выпадение" точки доступа, не означает что что-либо перестанет работать. Как это реализовано ? Каждое устройство, при наступлении события, рассылает (в случае наличия connect с AP) информацию на muulticast address, и все остальные устройства реагируют согласно заданным программам. В приведенном выше screenshot, когда срабатывает одно из реле, сообщения отправляются с некиим признаком, типа "виртуальный канал", 5 и 6 для реле N1 и реле N2. Все остальные устройства, у которых в "Accept announcements from", при получении такого сообщения, "отзеркалят" у себя состояние соотв. реле. Могут "отзеркалить" состояние управляющих контактов, типа есть напряжение (90-220В), или нет. Далее, каждое из устройств будет отрабатывать сигналы, согласно локальной программе в каждом из устройств. Если локальные программы не заданы, то тогда все устройства "слушающие", например, канал 5 (для channel 1 на картинке выше), в случае замыкания на устройстве, которое передает информацию остальным, просто повторят состояние контактов своих реле (для каждого из каналов независимо), согласно полученному сообщению. ESP8266 имеет очень неслабые сетевые возможности, в частности возможность работы в режиме "mesh network". Для этого не нужно использовать имеющиеся библиотеки (хотя конечно можно), а использовать "родной SDK", что позволяет исполнять разные чудеса. Что это значит ? 2 или более ESP8266 могут общаться напрямую, без участия точки доступа, или каких-либо других аппаратных средств. Основное условие - прямая видимость. "прямая видимость" в общем достаточно условно, например один из моих контроллеров в подвале, "достреливает" до соседнего здания через метров 20. С RSSI примерно -85. Сообщения на multicast и на остальные устройства передаются "условно одновременно", при этом каждый из кристаллов фильтрует дубли. Это означает, что подключение к точке доступа мне нужно только для того, чтобы я мог "c удобствами", в своей домашней сети, мониторить и управлять каждым из устройств путем http интерфейса. Если оного не будет, тогда нужно расслабиться на время, пока не поднимется точка доступа, либо коннектиться к встроенной точке доступа каждого из устройсв. При этом, вся эта конструкция остается в полностью рабочем состоянии. В примере нав картинке выше, контроллер "следит" за наличием сетевого наряжения на 2х фазах и, в случае если пропало, и система перешла на резерв, отключает конвекторы и бойлер, которые подключены на каждую их этих фаз. Ясен перец, что при таких раскладах, неполучение конечными устройствами сигналов об отключении, чревато тем, что резерв "кончится" через час, может даже меньше. А что будет если устройства находятся слишком далеко друг от друга, т.е. "не достают" один до другого ? Каждое из устройств, помимо локальной отработки команд, форвардит пакеты остальным (настраивается, точка доступа по прежнему не нужна). Да, при этом из своей локальной сети я это устройство "не вижу", но при этом, например, оно исправно включает прожектор, и открывает/закрывает калитку. Выключателями которые в доме, и не только. Другие устройсва, которые "по дороге" ретранслируют команды от/к устройству, и вся эта конструкция работает, пока не пропало питание. MQTT мне нужен для сценариев, когда требуетсся выполить какие-либо действия, при совпадении нескольких условий, например температура в одном из помещений повысилась до заданного предела, при этом "выпала" одна из фаз (или все), датчик освещенности показывает что "капец как ярко", а дачтик UVB гоаорит что больше 8. Такой сценарий контроллеры самостоятельно не отработают, и для этого есть MQTT. Если AP "упадет", то я ессно лишусь этих самых сценариев, но "базовые" продолжат работать, и я смогу управлять всем своим хохяйством. MQTT так же крайне полезна для аггрегации всего этого хозяйства, т.к. при наличии более 10 устройств, начинают возникать вопросы типа "а какой собсно IP у контроллера, который управляет светом в беседке" ? Не, понятное дело, что я могу пойти и щелкнуть выключателями в этой самой беседке, но из интерфейса это сдедать немного удобнее Через WEB интерфейс я мало того что могу выключить свет (или конвекторы, бойлер, ...) так еще и отключить возможность управления выключателями. Все то же самое можно выполнить через MQTT, разве что из WEB интерфейса можно отключить возможность обработки "обратки" (PUBLISH) от MQTT, либо вообще отключить MQTT для данного конкретного устройства. Сам движок MQTT (в моем случае mosquitto с API) работает исправно (на Orange PI), не хватает собсно только GUI, где будут красиво прорисованы и представленны строения/комнаты, с утановленными устройствами и элементами управления. Home Assistant я рассматривал эксклюзивно с этой точки зрения, но ... не завелся. Back end для всего этого хозяйства достаточно простой, основная проблема в визуализации, и конструкторе. Нашел пару frameworks имени JS, сейчас присматриваюсь к трудозатратам. Все последующие устройства, включая контроллер давления/потока имени насоса, будут работать по сходной логике, т.е. с возможностью взаимодействия друг с другом.

Да уж... Это самый Xiaomi extender достаточно глючное чудовище. Лог имени моего RT-N66u: и так каждые 5 минут... Все бы ничего, но даже на 2х устройствах, которые подключены к этой замечательной модели наблюдается следующая картина: ессно устройства, получив "неожиданный" DHCPOFFER находятся в некотором недоумении и, совершенно логично отваливаютися и реконнектяться по новой. В общем конечно не проблема, только лог засоряется сообщениями, ну и на время reconnectа ессно устройства подключенные к этому самому extender недоступны. При текущих раскладах, меня это особо не напрягает, т.к. все мои устройства работают автономно, и, в случае недоступности сети общаются напрямую, но поскольку я хочу все это завязать на свой MQTT сервер, так оно, к сожалению, точно не заработает. Стоимость Asus RT-N12E - 300 грн. В режиме AP, придется таки пожертвовать одним портом, ну или в режиме WDS, что в общем не самая хорошая идея (open access point only). Сам extender перегружается около 3х раз за сутки. Обычно это происходит, если подключилось 4 или более устройства. Вне зависимости оттрафика от этих самых устройств. Максимально пробовал 6, поработал пару минут, ушел в глубокие раздумья, и где-то минут через 20 перегрузился. Таки пора с ним прощаться. К сожалению, я больше не увижу такой картинки и, о ужас ! не смогу управлять пылесосом

А что можно пообещать "under GNU public license" ? Linux в общем достаточно стабильная система. Основная проблема в том, что все это хозяйство нужно правильно настроить. Или вы сомневаетесь в своей квалификации, т.е. в возможности все это настроить так, чтобы "не бабахнуло" ? Тогда rozetka вам в помощь, или аналогичная трейдинговая площадка. Ну или можно в магазин электроники заглянуть, и вынести мозг несчастному менеджеру, который только вчера еще доил корову в селе, а теперь пытается заработать копейку, продавая "сам не знаю чего". Если вы точно знаете что вы хотите исполнить, и есть квалификация, то тогда у вас все получится. Ладно, пусть даже начальная квалификация, и желание разобраться. Верьте в себя :-) Я собсно делюсь опытом как все это хозяйство работает "прямо из коробки", и какие можно и нужно предпринять действие чтобы это все уконфигурить под свои задачи. Ничего сложного тут нет - только нужно потратить пару дней времени, это да, таки проблема. Задачи для мини компьютера с 2Gb RAM (правда расшаренного с GPU, около 80к без графики) и 8Gb EMCC у меня есть. Возможно конечно что владеете матчастью гораздо лучше меня,- тогда жду ваших подсказок. Например как подключить bridge, если товарищи китайцы собрали ядро без поддержки bridge, а собирать ядро по новой имеет смысл только при наличии радиаторов на кристаллах.

Debian Jessie вроде-как работает стабильнее. uptime был более 24х часов, чудес не замечено, ошибок нет, память не течет. Есть конечно нюансы с "коммерциализацией" части пакетов, но поскольку есть gcc, то можно без особых проблем самостоятельно собрать недостающие из исходников. Собрал Apache, в общем, не считая времени сборки и нагрева кристалла - проблем не вижу. В комплекте с самим Jessie идет замечательный скрипт, при помощи которого можно перенести OS + packages + все остальное на emmc. На всякий случай выкладываю: https://www.stroimdom.com.ua/forum/attachment.php?attachmentid=653820&stc=1&d=1553461361 mosquitto тоже нужно собирать с сорцов, но это самая малая проблема, по сравнению с остальными. OPI_EMMC.rar

Не, сделаю свой. Он был в планах, но явно не на сейчас. Пока как часть логики управления насосом. Сложностей никаких я не вижу, глянул на пример реализации (www.aliexpress.com/item/Active-Single-Phase-Voltage-Transformer-Module-AC-Output-Voltage-Sensor/32860818572.html?spm=a2g0s.13010208.99999999.285.e9933c001VUKKo) - все понятно. Операционник и обвеска. На ali есть уже "типа готовые решения" имени energy monitoring, со снятием показаний через uart,- но смысла в оных я не вижу, тут ничего сложного нет. Алгоритмы простые и известные, трансформатор тока есть, проверен, и работает как часики. На 10 битах имеющегося в наличии ADC точность конечно не позволит что-либо измерить с достаточной достоверностью, но на 16 битах, чуть поджав диапазон - вполне.

Наличие не проблема, это у меня уже давно есть в таймере. Это самая простая задача. В диапазоне от 90 до 240В. С dejitter, т.к. мне нужно знать когда была нажата, а когда отпущена клавиша выключателя. Нужно значение самого напряжения. Желательно в диапазоне от 1 до 400В. Цель - знать потребление насоса как единомоментно, так и за период.

Выполнил первичную оценку, не нашел цифрового flow meter. Значит наверное нет смысла заморачиваться с частично аналоговыми, частично цифровыми датчиками. Придется каятся перед InSAn Минимальный набор я вижу следующий: 1. ADS1115 (www.aliexpress.com/item/16-Bit-I2C-ADS1115-Module-ADC-4-channel-with-Pro-Gain-Amplifier-for-Arduino-RPi-1PCS/32817162654.html?spm=a2g0s.13010208.99999999.260.82353c00k7q5lH) 2. 1" flow sensor (www.aliexpress.com/item/Water-Flow-sensor-Hall-Sensor-Switch-Flow-Meter-DN25-brass-water-meter-Industrial-turbine-flowmeter-1/32954428165.html?spm=a2g0s.8937460.0.0.71372e0e5j0PjI) 3. Pressure transducer (www.aliexpress.com/item/5V-0-1-2-MPa-Oil-Fuel-for-Gas-Water-Air-Pressure-Transducer-Sensor-Oil-Fuel/32816800284.html?)spm=2114.search0104.3.8.5c1b2b7dP4Docc&ws_ab_test=searchweb0_0,searchweb201602_1_10065_10068_319_10059_10884_317_10887_10696_321_322_10084_453_10083_454_10103_10618_10307_537_536_10902,searchweb201603_6,ppcSwitch_0&algo_expid=caf7ee64-5205-4673-8854-5d189c2e093b-1&algo_pvid=caf7ee64-5205-4673-8854-5d189c2e093b) 4. Current transformer (www.aliexpress.com/item/Free-Shipping-1pcs-Non-invasive-Split-Core-Current-Transformer-AC-current-sensor-100A-SCT-013-000/32754634532.html?spm=a2g0s.9042311.0.0.27424c4dyNB2q4) Часть уже есть в наличии, часть дозакажу. АЦП - 4 канала. По идее мне достаточно 3, но учитывая критичность процесса, можно поставить 2 дублирующих датчика давления (И/ИЛИ). Поскольку внешний I2c АЦП доступен, вписываюсь в архитектуру 8266, т.е. ESP32 для этой задачи избыточен. Еще бы напряжение (220V) чем-то померять, тогда был бы полный феншуй, но для того чтобы измерить с приемлимой точностью, увы и ах без трансформатора не обойдешься. Можно такой www.aliexpress.com/item/ZMPT101B-2mA-2mA-Precision-Phase-voltage-transformer-Output-Voltage-Sensor/32960491471.html?spm=a2g0s.8937460.0.0.26e92e0eBoXYbc но меня что-то смущает 2ма. "голым" оный подключать не получится, я думаю как минимум нужно 2 резистора и один конденсатор. Тогда будет чем загрузить 4й порт АЦП. Так, в принципе, все понятно. С алгоритмом - начал рисовать, но пока еще не все понятно.

100л. По моему итальянский, уже сходу не вспомню. Живет так более 6 лет. Через 2 года после установки была замена груши. Купил аналог на Юности, поменял, потом пытался накачать ручным насосом, понял бесперспективность, вынес к машине и накачал электрическим насосом. DMI до сих пор жив, и работает как часики. "на сейчас" схема выглядит так: www.stroimdom.com.ua/forum/attachment.php?attachmentid=653758&stc=1&d=1553383432 Water v7.pdf

Датчики TE планируются под задачу регулятора давления. У меня немного сложная система очистка воды (https://www.stroimdom.com.ua/forum/showthread.php?t=93628) и, похоже за 6+ лет, насосу (обычный Водолей в скважине, труба 110), и реле давления, приходит конец. Как это выглядит: У меня реле давления (механическое, кажется какое-то итальянское), было настроено на диапазон 1.5 - 5Атм, насос исправно качал, и все было хорошо. При установке всего хозяйства, я еще "про всяк випадок" добавил систему защиты от сухого хода, которая при вскрытии оказалась усложненной системой реле тока. Иногда, при достижении границы 5Атм, реле давления почему-то не срабатывает. Срабатывает защита по току, где-то в районе 5.9А (проверил экспериментальным путем). После этого нужно исполнить цикл power down/up, и тогда все продолжает работать как задумано. Я морально готов к замене насоса, но мне интересно увидеть "закат цивилицации вручную", т.е. как именно придет конец моему насосу ? Дебит скважины минимум в 3 раза превышает возможности насоса, так что с этим проблем нет. По причине износа пружин, а в моем реле давления стоят 2 регулятора (верхний и нижний предел), которые по факту работают в режиме "верхний предел" и дельта, механические регулировки позволили "переехать" в диапазон 3 - 4.5Атм, что в общем не сильно хорошо как для самого насоса, так и для мембраны в баке. Давление я мониторил путем 3х механических манометров. Почему 3х ? Потому, что давление "на входе", после 3х баллонов, и на трубе раздачи чистой воды конечным потребителям различается. Фактически, для меня значительные отклонения любого из 3х показателей, означали необходимость внеочередной промывки, или замены механического фильтра (одного из). По идее, самое простое решение - это "вернуться" в старый диапазон, путем установки цифровых датчиков (те самые TE), но при этом возникает вопрос,- а как собсно должна работать система на разных режимах ? Может имеет смысл мониторить расход воды за период, и динамически подстраиваться под текущий расход ? То есть, если устройство например видит что расход воды "относительно постоянный", то какой смысл ждать пока давление опустится до 1.5, потом снова накачивать до 5, и снова ждать ? Может зная показатели расхода за период и текущее давление просто включить насос на постоянку, и следить только за тем, чтобы давление не ушло за верхнюю границу ? Пока в раздумьях. В идеале конечно хотелось бы запараметризировать всю эту кухню, но пока не могу сложить в голове puzzle как должно быть "в идеале". Если у кого-либо есть "готовый алгоритм", прошу поделиться. Обещаю подарочные образцы готовых контроллеров.

Дык есть более дешевые варианты. Есть за 10$ с 512к RAM. Я начал c одной из топовых моделей чтобы потом не было "вот блин, был бы мегабайт памяти - летало бы". Home Assistant по факту оказалась достаточно глючным динозавром. В виде контейнера (с ОS) именно на этой плате не стартует (ни 32, ни 64 бита), если инсталлировать на FS - бардак мрачнейший. PIP (python) загадили всю fs, и по финалу я так и не запустил HA. python почему-то упрямо пыталось втулить 2.7, хотя уже стояла 3я версия. "родной" docker этой штуке почему-то не понравился, а docker-ce именно под эту платформу неживой. Принципиально не живой, думаю что чинить самостоятельно нет смысла. Интереса ради поставил mosquitto,- взлетел как часики, и это хорошо. Помучил немного - все работает (даже Websockets), но только вот беда - фронта нет. Что-то у меня нет желания писать свой framefork на Java/Javascript. Если HA ставится так сложно, то ну его нафиг. От слова совсем. Я не сомневаюсь что его можно запихнуть именно в эту архитектуру, но потраченное время и усилия будут немалые. Сырое решение. Если с "сыростью" платы/Linux еще побороться можно, причем коллективными усилиями, то бороться с косяками какого-то 3rd party app в общем дело не очень перспективное. Присмотрюсь к альтернативным фронтам, думаю что более "зрелое" решение уже есть.