сейчас тоже к домашней автоматизации присматриваюсь. Пока в самом начале — взял несколько датчиков/диммеров zwave, там мне понравилось что простые сценарии можно делать на ассоциациях напрямую — т.е. условный вкл/выкл света будет работать даже если контроллера нет совсем.
В ZigBee если я правильно понимаю — хотя и есть стандартные интерфейсы для разных типов устройств — они не (в общем случае) не умеют общатсья напрямую, т.е. выключатель не может отправить сообщение напрямую реле/диммеру лампочки: включись/выключись.
Хотелось бы уточнить — почему выбран именно ZigBee (меня как раз смущает что без центрального контроллера всё перестаёт работать) и действительно ли даже простейшего взаимодействия напрямую между устройствами не получится?
If you use Z-Way on top of the RaZberry Shield the complete functionality is available free of charge without any limitations
В первом пункте говорится о том что я могу использовать по на RaZberry без доп. оплаты
If you want to use Z-Way on a different platform than Raspberry Pi with support for Z-Wave you can download the code free of charge but you will need a Z-Wave.Me transceiver hardware such as UZB and you will need a licensing key to unlock the Z-Wave function
А в 3-м что для использования с z-wave на платформе не Raspberry Pi надо покупать лицензию.
Вопрос: если у меня есть свой Raspberry Pi, есть Z-Wave.Me стик — надо ли мне покупать лицензию для его использования?
Если проект ещё жив и между клиентом и сервером используется только одно соединение — тогда как вам вариант:
go-программа запускает бинарник сервера из той же папки (или из PATH если в той же папке нужного бинарника нет), а дальше взаимодействие идёт через стандартный ввод/вывод.
Это поможет избежать проблем с локальными Firewall-ами + можно будет легко понимать что гуи-сервер запущен/остановлен (и например тоже сваливаться).
+ Упрощается настройка: достаточно будет скачать один архив (с двумя бинарниками) и распаковать, доп. настройки опять же не надо, не надо отдельно сервер в PATH складывать и т.п.
Прошел год от вопроса и вы свою задачу уже решили, так что комментарий больше для читающих историю.
Я правильно понял что проблема в том что сборки запускаются последовательно и при 4 коммитах надо ждать 12 часов чтобы дождаться результата проверок?
Если проблему я понял правильно — самым простым я вижу решение запускать сборки параллельно.
Те же 3 часа после коммита всё равно пройдёт до получения результата, но несколько проверок могут идти одновременно и время ожидания между ними не будет суммироваться.
Не мучайте дочь :)
Есть же EAP — они бесплатны для использования и выходят достаточно часто, чтобы сидеть на них более-менее всё время. Через ToolBox удобно ставятся и удобно обновляются.
По стабильности работы я не заметил различий между стабильной и EAP версией. Для Goland предпочитаю EAP по причине того что можно раньше новыми возможностями воспользоваться.
Я имею ввиду доступ к самому kubernetes.
Например при настройках по умолчанию может остаться доступ к API без пароля или с каким-то известным паролем, заданным при установке по умолчанию.
Тогда без дополнительной настройки (смены пароля, закрытие всех путей доступа к API и методов авторизации, кроме тех что заданы явно) — кластер получается открытым для для внешних систем и кто угодно сможет запускать там свои образы.
Кроме непосредственно поднятия кластера до состояния «заработало» было бы еще интересно почитать основы по защите кластера — т.е. что нужно учитывать, когда настраиваешь кубернетс на серверах с прямым доступом из интернет: чтобы и внутренние сервисы можно было наружу отдавать и условно не выставлять базу с админским доступом без пароля во внешнюю сеть.
Есть ли лицензии на «Телематику» и «Передачу данных»? Отсутствие этих документов недопустимо.
Почему недопустимо?
Это компании занимающиеся лицензиями со всех сторон трубят что это обязательно и без лицензии никак и т.п. Трубят хорошо — так что весь интернет этим забит.
Я делал официальный запрос — нужна ли лицензия для услуг хостинга (размещение сайтов, аренда вирт. серверов и т.п.) и получил официальный ответ что услуги хостинга (сдача своих мощностей в аренду) — нелицензируемый вид деятельности и получать ничего не нужно.
Ну если всё до сих пор хорошо — то хорошо.
Если что — о проблемах можно писать. Эффективнее будет в issues на github — я их лучше получаю, чем уведомления отсюда.
Кстати сейчас от такого mitm и https не спасёт, без дополнительных средств вроде привязки к сертификату в заголовке и/или мониторинга в реальном времени выпущенных сертификатов.
точно так же можно подменить DNS-ответы для сервера lets encrypt, получить их сертификат.
Потом уже атаковать DNS-сервер провайдера/клиента чтобы встроится посередине с сертификатом Let's encrypt. Тогда и клиент увидит валидный сертификат и браузер паниковать не будет и трафик будет прослушан.
Мне кажется потери гитлаб неприятны, но врядли для кого то критичны.
и даже если бы коммиты за сутки потеряли — тоже неприятно, но в большинстве случаев не критично, т.к. они есть у разработчиков на локальных машинах.
кроме того надо делать скидку на то что gitlab.com полностью бесплатный сервис, фактически просто публичная демка enterprise решения, а пользователи с т.з. бизнеса там нужны для рекламы и для массового тестирования этого платного продукта.
и с этим учетом 6 часов данных не очень большая потеря.
к тому же это потеря из за ошибок админа, а не бага в продукте, так что врядли это повлияет на отношение к гитлаб как к системе.
В смысле чтобы я на тестовой виртуалке сделал ту же конфигурацию что у вас, запустил расширение и гарантировано получил сломанную таблицу (ну или с большой долей вероятности).
От fdisk тут зависимости нет — с таблицей разделов я работаю напрямую на диске.
Ошибки про loop-девайсы это номально, они ни на что не влияют. Ошибки в первом выводе это про то что ядро не смогло распознать увеличение нижележащего раздела без ребута и не получается PV сразу расширить, т.е. тоже ничего страшного.
рекламировать основной, а там когда есть проблемы делать рассылку, что тормоза связаны с ограничениями телеграм. Можно оставаться тут с тормозами или регнуться в таком-то боте где места есть и всё быстро.
сейчас тоже к домашней автоматизации присматриваюсь. Пока в самом начале — взял несколько датчиков/диммеров zwave, там мне понравилось что простые сценарии можно делать на ассоциациях напрямую — т.е. условный вкл/выкл света будет работать даже если контроллера нет совсем.
В ZigBee если я правильно понимаю — хотя и есть стандартные интерфейсы для разных типов устройств — они не (в общем случае) не умеют общатсья напрямую, т.е. выключатель не может отправить сообщение напрямую реле/диммеру лампочки: включись/выключись.
Хотелось бы уточнить — почему выбран именно ZigBee (меня как раз смущает что без центрального контроллера всё перестаёт работать) и действительно ли даже простейшего взаимодействия напрямую между устройствами не получится?
ПО Z-way можно бесплатно использовать на других raspberry?
https://z-wave.me/z-way/z-way-licensing/
В первом пункте говорится о том что я могу использовать по на RaZberry без доп. оплаты
А в 3-м что для использования с z-wave на платформе не Raspberry Pi надо покупать лицензию.
Вопрос: если у меня есть свой Raspberry Pi, есть Z-Wave.Me стик — надо ли мне покупать лицензию для его использования?
Теперь похоже есть оба подхода
https://z-wave.me/z-way/download-z-way/
https://z-wave.me/z-way-v3-0-0/
go-программа запускает бинарник сервера из той же папки (или из PATH если в той же папке нужного бинарника нет), а дальше взаимодействие идёт через стандартный ввод/вывод.
Это поможет избежать проблем с локальными Firewall-ами + можно будет легко понимать что гуи-сервер запущен/остановлен (и например тоже сваливаться).
+ Упрощается настройка: достаточно будет скачать один архив (с двумя бинарниками) и распаковать, доп. настройки опять же не надо, не надо отдельно сервер в PATH складывать и т.п.
Я правильно понял что проблема в том что сборки запускаются последовательно и при 4 коммитах надо ждать 12 часов чтобы дождаться результата проверок?
Если проблему я понял правильно — самым простым я вижу решение запускать сборки параллельно.
Те же 3 часа после коммита всё равно пройдёт до получения результата, но несколько проверок могут идти одновременно и время ожидания между ними не будет суммироваться.
Кстати в ответ на мой вопрос — такая библиотека есть, например github.com/pkg/errors
Есть же EAP — они бесплатны для использования и выходят достаточно часто, чтобы сидеть на них более-менее всё время. Через ToolBox удобно ставятся и удобно обновляются.
По стабильности работы я не заметил различий между стабильной и EAP версией. Для Goland предпочитаю EAP по причине того что можно раньше новыми возможностями воспользоваться.
Например при настройках по умолчанию может остаться доступ к API без пароля или с каким-то известным паролем, заданным при установке по умолчанию.
Тогда без дополнительной настройки (смены пароля, закрытие всех путей доступа к API и методов авторизации, кроме тех что заданы явно) — кластер получается открытым для для внешних систем и кто угодно сможет запускать там свои образы.
Почему недопустимо?
Это компании занимающиеся лицензиями со всех сторон трубят что это обязательно и без лицензии никак и т.п. Трубят хорошо — так что весь интернет этим забит.
Я делал официальный запрос — нужна ли лицензия для услуг хостинга (размещение сайтов, аренда вирт. серверов и т.п.) и получил официальный ответ что услуги хостинга (сдача своих мощностей в аренду) — нелицензируемый вид деятельности и получать ничего не нужно.
Ну если всё до сих пор хорошо — то хорошо.
Если что — о проблемах можно писать. Эффективнее будет в issues на github — я их лучше получаю, чем уведомления отсюда.
Странные у вас контакты какие-то.
точно так же можно подменить DNS-ответы для сервера lets encrypt, получить их сертификат.
Потом уже атаковать DNS-сервер провайдера/клиента чтобы встроится посередине с сертификатом Let's encrypt. Тогда и клиент увидит валидный сертификат и браузер паниковать не будет и трафик будет прослушан.
Мне кажется потери гитлаб неприятны, но врядли для кого то критичны.
и даже если бы коммиты за сутки потеряли — тоже неприятно, но в большинстве случаев не критично, т.к. они есть у разработчиков на локальных машинах.
кроме того надо делать скидку на то что gitlab.com полностью бесплатный сервис, фактически просто публичная демка enterprise решения, а пользователи с т.з. бизнеса там нужны для рекламы и для массового тестирования этого платного продукта.
и с этим учетом 6 часов данных не очень большая потеря.
к тому же это потеря из за ошибок админа, а не бага в продукте, так что врядли это повлияет на отношение к гитлаб как к системе.
А это можно как-то воспроизвести?
В смысле чтобы я на тестовой виртуалке сделал ту же конфигурацию что у вас, запустил расширение и гарантировано получил сломанную таблицу (ну или с большой долей вероятности).
От fdisk тут зависимости нет — с таблицей разделов я работаю напрямую на диске.
Ошибки про loop-девайсы это номально, они ни на что не влияют. Ошибки в первом выводе это про то что ядро не смогло распознать увеличение нижележащего раздела без ребута и не получается PV сразу расширить, т.е. тоже ничего страшного.