Основная проблема/беда Far, на мой взгляд, — высокий порог вхождения. И не очень дружелюбное сообщество поддержки :( Я и сам до сих пор иногда открываю для себя новые «фичи», а уж случаев, когда подсказывал другим, и получал в ответ «ого! а так можно было?!» — без счёта. Была даже идея сделать плагин наподобие юниксового fortune, с базой разных сценариев использования всех фичей фара…
Увы, это всё не очень сильно отличается (причём, увы, в худшую сторону) от того проекта, на который я ссылался в своем посте… Вроде valify V2 очень многообещающе выглядит, но совершенно непонятно, чем там на самом деле кончилось дело. После 2018 года его следы теряются :(
Про то, что «кто-то, кое где, у нас, порой» — встречал, да. У меня-то вопрос был именно про стандартный интерфейс управления внешними осветителями для камер в массовом сегменте. Я так понимаю, тут всё глухо пока…
Не знаю, как это устроено на самом деле (не причастен), но из общеинженерных соображений могу предположить, что при проектировании закладывается определённый ресурс (типа «сделаем трубу на 50% толще, она выдержит в 50 раз больше испытаний») и, конечно, регулярные проверки.
Думал для себя про использование в проектах с большой кодовой базой, когда приходится дописывать код в тех местах, с которыми знаком поверхностно, и хочется иметь под руками типовые шаблоны как по аргументам, так и по структуре вызовов. Насколько большие и правильные куски кода оно может порождать? Не приходится ли за этим копилотом потом в три раза внимательнее всё «перечитывать»? (Анекдот такой был… — Как правильно, Ирак или Иран? — Гугл говорит, что и так, и так — правильно).
Было бы интересно провести перекличку. Я оставлял заявку в августе прошлого года — ни ответа, ни привета не получил (справедливости ради, подавался от пустого акка).
Для начинающих погружаться в тему — статья полезная, но для практиков-любителей, которые столкнулись с организацией видеонаблюдения «в домашних условиях» (особенно уличного) — эти «открытия» — увы, давно пройденный этап. Было бы интересно узнать, не появились ли на али модели камер, учитывающие все эти «открытия». Например, имеющие в «хвосте» выводов интерфейс к осветителю, позволяющий его запитать, включить/выключить, узнать освещённость и т.п., и ИК осветители, которые можно к этому «хвосту» подключать.
Вроде, вся внутренняя машинерия IP-камер более-менее совместима (по посадочным и присоединительным размерам, разъёмам, характеристикам интерфейсов) а наружу, кроме аудио-входа, редко кто что выводит…
P.S. Плюс, на этом поле можно реализовать много интересных идей. Например, импульсное освещение (камеры наблюдения зачастую работают на пониженной частоте кадров, и если синхронизировать осветитель с затвором, можно на низкой скважности питать светодиоды в overdrive режиме, не повышая их тепловую нагрузку и срок службы), или добавлять мощности при срабатывании датчика движения, и переключать группы освещения с общего на спот и т.п… кто бы занялся...)
Если вы когда-нибудь видели вблизи ракетный двигатель, то наверняка обращали внимание на каркас из труб, хорошо заметный со стороны, противоположной соплам. Так вот прочности этого каркаса с запасом хватает, чтобы передать всю силу тяги, которую развивает двигатель, ракете. А трубы там, даже на самых мощных моделях, толщиной едва с детскую руку. Так что и удержать двигатель при испытаниях можно каркасом аналогичных характеристик (надёжно закреплённым).
Не вполне понял извращение с «systeminfo.exe /fo csv | ConvertFrom-Csv». Зачем заказывать вывод в csv и потом его конвертировать в читабельный вид, если systeminfo без параметров и так всё показывает в читабельном виде (и версию виндов и, кстати, список накаченных hotfix'ов?
P.S. Кстати, поделитесь, если у кого есть рабочий алгоритм накатывания апдейтов безопасности на «старые венды». Т.е. как на условную 10.0.10240 поставить все актуальные на июнь 2022 security патчи, но не ставить feature updates?
Тема умных газонокосилок — непаханное поле. То, что сейчас есть на рынке, это просто тихий ужас, особенно учитывая цену. При этом, практически все приборы, которые позиционируются как автономные газонокосилки, имеют на борту почти полный набор компонентов, используя которые можно сделать нормальное устройство, но почему-то никому пока это не удалось. Может, место проклятое… DJI вот удалось вытеснить все коптеровские самоделки в маржинальные ниши, а в области газонокосилок такой компании пока нет. Нашел тольк один проект, который пытается играть на этом поле: github.com/ClemensElflein/OpenMower — но у него дела пока ни шатко, ни валко…
Странно, что Вы не знаете: «самостоятельно поменять» в Швеции нельзя. Вообще нельзя прикасаться к сети 220В если нет соответствующего «допуска». Именно из-за этого в домах розетки на потолке, а все люстры продаются с вилками, а не зачищенным «хвостом» провода, как почти во всём остальном мире.
Тут мы плавно подходим ко всем преимуществам модели opensource. Если бы планы ядерных ударов, вместе с моделями оценки угроз, эффективности и результативности, лежали на условном гитхабе, множество желающих, и просто любопытных, смогли бы оценить, насколько текущие полётные задания отвечают заявленным политическим целям. Что эффективнее: воздушный взрыв, дающий больший радиус поражения ударной волной, световым излучением и ЭМ-импульсом, или наземный, дающий больший вынос РА-частиц, в т.ч. с долгоживущими изотопами, и большую площадь радиоактивного заражения. Имеет ли вообще смысл в ответном, или ответно-встречном, ударе, поражать пусковые шахты (пустые уже в момент принятия решения о пуске) и прочие объекты военной инфраструктуры, или больший вклад в неприемлемый ущерб для противника даст поражение его объектов критической инфраструктуры («ямальский крест», Wall Street, Yellow Stone etc.). Стоит ли, вообще, ограничивать мощность заряда, если есть возможность в тех же массогабаритных рамках, сделать его на порядок, или даже два-три, больше…
Сейчас, увы, весь подобный анализ делают узкие группы людей, и я совершенно не уверен, что они руководствуются теми же критериями, что и Вы, и учитывают все те превходящие обстоятельства, которые учитывать стоит.
Бывают трёхточечные (два входа, один выход) термостаты для душевых кабин. Выход из такого термостата нужно подать на оба входа (хол. и гор.) штатного смесителя. После чего он будет регулировать только напор, а температуру будет контролировать термостат.
P.S. Как будет работать на практике — пока не знаю. У меня запчасти для такой переделки третий год лежат на даче, ждут своего часа…
Насколько я понял, они не совместимы в привычном смысле этого слова, но используют одни и теже стандарты передачи данных (physical & data link layers: IEEE 802.15.4). У zigbee всё, что выше (по OSI-модели: network, transport etc. layers) — своё, а Thread использует IPv6 (с разными примочками и ограничениями, специфичными для low-power устройств), так что именно Thread можно считать основой Internet of things.
По идее, поскольку сейчас вся подобная машинерия делается по одним и тем же принципам (чип PHY + чип MCU со стандартным интерфейсом), есть шанс, что производители смогут относительно малой кровью адаптировать свои zigbee устройства к thread/matter. Но это в том случае, если в соответствующие микроконтроллеры влезет стек IPv6+Thread+Matter (+криптография), либо если они умеют выставлять на интерфейс промежуточный уровень, что позволит поддержать нужный стек «софтварно» на сервере или в контроллере более высокого уровня.
Вроде, вся внутренняя машинерия IP-камер более-менее совместима (по посадочным и присоединительным размерам, разъёмам, характеристикам интерфейсов) а наружу, кроме аудио-входа, редко кто что выводит…
P.S. Плюс, на этом поле можно реализовать много интересных идей. Например, импульсное освещение (камеры наблюдения зачастую работают на пониженной частоте кадров, и если синхронизировать осветитель с затвором, можно на низкой скважности питать светодиоды в overdrive режиме, не повышая их тепловую нагрузку и срок службы), или добавлять мощности при срабатывании датчика движения, и переключать группы освещения с общего на спот и т.п… кто бы занялся...)
P.S. Кстати, поделитесь, если у кого есть рабочий алгоритм накатывания апдейтов безопасности на «старые венды». Т.е. как на условную 10.0.10240 поставить все актуальные на июнь 2022 security патчи, но не ставить feature updates?
Сейчас, увы, весь подобный анализ делают узкие группы людей, и я совершенно не уверен, что они руководствуются теми же критериями, что и Вы, и учитывают все те превходящие обстоятельства, которые учитывать стоит.
P.S. Как будет работать на практике — пока не знаю. У меня запчасти для такой переделки третий год лежат на даче, ждут своего часа…
По идее, поскольку сейчас вся подобная машинерия делается по одним и тем же принципам (чип PHY + чип MCU со стандартным интерфейсом), есть шанс, что производители смогут относительно малой кровью адаптировать свои zigbee устройства к thread/matter. Но это в том случае, если в соответствующие микроконтроллеры влезет стек IPv6+Thread+Matter (+криптография), либо если они умеют выставлять на интерфейс промежуточный уровень, что позволит поддержать нужный стек «софтварно» на сервере или в контроллере более высокого уровня.