Я как совет и воспринимаю, минус я вам не ставил :)
Просто пытаюсь понять, где реальное преимущество KNX, потому что по ощущением будет стоить сильно дороже, чем то решение которое я спроектировал.
Дизайн - реле в розетки позволяет тоже любой дизайн использовать. KNX в целом тоже точка отказа, но я так понимаю что логика работы в самом KNX, а не в HA (там просто сценарии добавляются) и наверное вероятность отказа сильно меньше чем сервака на HA.
Для меня всегда KNX был - инструмент для постройки проводного умного дома. То есть и датчики и все остальное тоже на этой же шине. Причем именно дома, не квартиры.
Количество людей планируется считать не датчиком присутствия/движения, а датчиком посетителей (он считает объекты которые пересекли определенную линию и направление, по такому принципу сейчас на мероприятиях людей считают).
Ну получается что если для света реле ставить в подрозетники, то будет так же надежно. Если что-то заключит, то просто включишь кнопкой. Разве нет?
Да и глушилки и прочее, от протокола мне кажется сильно зависят.
Ну вот большая часть, которую перечислил в статье это китайское, но не бюджетное. Оно прям сильно разное. Наверное самое главное что стоит перед мной - рискнуть и делать без выключателей или все же оставить.
Если отхлебнет свет, будет печально, если остальное - то обидно, но в целом не критично.
Python, Java, Go, Kubernetes, AWS, PostgreSQL, Kafka, Docker, Linux, DevOps, микросервисы, опыт архитектуры 5 лет.
то подразумевается что пишут на python, хотят в go, а на Java соседний сервис, с которым делать интеграцию и весь собес спрашивают про Python. Ну либо нужен менеджер и стек там не сильно важен.
Проблема была основная не сколько в самом Qwen, но и в Hermes, как harness Я сильно много на него возложил, а мне нужна была надежность и повторяемость.
Да, там все сильно лучше, у меня параллельно запущен Hermes личный на OpenAI Sol, он похожий кейс прям сильно надежно делает.
Ну если писать все сразу что у меня есть, то не за день, но за неделю написать можно. Но я писал постепенно, поэтому вполне оправдано. На каждый часа три - четыре с тестированием. Потом итеративно работаешь во время использования, а это уже в целом 10-30 минут.
Если бы была не локальная модель, а подписка, я бы может так сильно и не заморачивался, вся модель именно из-за локальных моделей.
Оруестратор вполне можно сделать, если памяти хватает. В моем случае я не могу юзать глобальную модель, потому что много данных которые я не хочу что бы попали наружу.
Если таких ограничений нет, тогда проще всего использовать фронтир. На моём личном агенте основная модель Codex, дополнительная Claude.
Решал такую же задачу, не стал ничего выдумывать и взял твитеровскую архитектуру - хранение в Redis, максимально быстро. Мастер данные в постгри, сервис ленты берет обновление из кафки.
Сильно не хватает выбора персоны, то есть в два этапа проходить. Типо с десяток персон, а потом уже с нужно смотришь веса и какие нейросети знаю/ не знают.
Как правило ручки сложнее, чем просто Get без параметров.
Поэтому рекомендую вместо первого шага, использовать k6 в проекте, и делать тесты для всех критических мест.
А еще, помимо пуляния нагрузки в короткий период, рекомендую попробовать дать нагрузку часов на 12, потому что самые больные места, это когда внезапно отказывают вроде бы надежные ручки, а понять в моменте причину не всегда получается.
А как вы с возможным баном боритесь? ТГ запрещает же массовый парсинг.
А какую модель взял?
Sprut я как раз ращматривал просто как заб, который поддерживает много протоколов. Если есть свисток хороший - порекомендуйте.
По протечки - скорей всего нептун, но в Китай поеду, хочу местные девайсы посмотреть.
В ванне дизайнеры назвали умный унитаз - унитаз с функцией биде. А подписали просто - биде.
Я как совет и воспринимаю, минус я вам не ставил :)
Просто пытаюсь понять, где реальное преимущество KNX, потому что по ощущением будет стоить сильно дороже, чем то решение которое я спроектировал.
Дизайн - реле в розетки позволяет тоже любой дизайн использовать. KNX в целом тоже точка отказа, но я так понимаю что логика работы в самом KNX, а не в HA (там просто сценарии добавляются) и наверное вероятность отказа сильно меньше чем сервака на HA.
Для меня всегда KNX был - инструмент для постройки проводного умного дома. То есть и датчики и все остальное тоже на этой же шине. Причем именно дома, не квартиры.
Количество людей планируется считать не датчиком присутствия/движения, а датчиком посетителей (он считает объекты которые пересекли определенную линию и направление, по такому принципу сейчас на мероприятиях людей считают).
Ну получается что если для света реле ставить в подрозетники, то будет так же надежно. Если что-то заключит, то просто включишь кнопкой. Разве нет?
Да и глушилки и прочее, от протокола мне кажется сильно зависят.
Спасибо!
Ну вот большая часть, которую перечислил в статье это китайское, но не бюджетное. Оно прям сильно разное. Наверное самое главное что стоит перед мной - рискнуть и делать без выключателей или все же оставить.
Если отхлебнет свет, будет печально, если остальное - то обидно, но в целом не критично.
А с чем больше всего проблем?
Как правило, если в вакансии пишут:
то подразумевается что пишут на python, хотят в go, а на Java соседний сервис, с которым делать интеграцию и весь собес спрашивают про Python. Ну либо нужен менеджер и стек там не сильно важен.
Да, в разных вариантах. Сейчас использую 6 bit.
Проблема была основная не сколько в самом Qwen, но и в Hermes, как harness Я сильно много на него возложил, а мне нужна была надежность и повторяемость.
Да, там все сильно лучше, у меня параллельно запущен Hermes личный на OpenAI Sol, он похожий кейс прям сильно надежно делает.
Ну если писать все сразу что у меня есть, то не за день, но за неделю написать можно. Но я писал постепенно, поэтому вполне оправдано. На каждый часа три - четыре с тестированием. Потом итеративно работаешь во время использования, а это уже в целом 10-30 минут.
Если бы была не локальная модель, а подписка, я бы может так сильно и не заморачивался, вся модель именно из-за локальных моделей.
Оруестратор вполне можно сделать, если памяти хватает. В моем случае я не могу юзать глобальную модель, потому что много данных которые я не хочу что бы попали наружу.
Если таких ограничений нет, тогда проще всего использовать фронтир. На моём личном агенте основная модель Codex, дополнительная Claude.
Решал такую же задачу, не стал ничего выдумывать и взял твитеровскую архитектуру - хранение в Redis, максимально быстро. Мастер данные в постгри, сервис ленты берет обновление из кафки.
Да, все верно. Просто так, как с большими моделями, с локальными не возможно работать.
Но если правильно приготовить, можно очень хорошо жить.
В ВШЭ набор в магистратуру закончился 8-го августа.
Спасибо. Поставлю себе. Я еще понять не мог, че мне постоянно руками надо доставлять.
Хочется конечно одно приложение для всего это, а не комбайн из сервисов.
А чем он лучше Sonarr?
Спасибо, благодаря статье узнал что uCoz еще жив.
Я думал про CRM уже давно не рассказывают в таком контексте.
Сильно не хватает выбора персоны, то есть в два этапа проходить. Типо с десяток персон, а потом уже с нужно смотришь веса и какие нейросети знаю/ не знают.
Как правило ручки сложнее, чем просто Get без параметров.
Поэтому рекомендую вместо первого шага, использовать k6 в проекте, и делать тесты для всех критических мест.
А еще, помимо пуляния нагрузки в короткий период, рекомендую попробовать дать нагрузку часов на 12, потому что самые больные места, это когда внезапно отказывают вроде бы надежные ручки, а понять в моменте причину не всегда получается.