Не в обиду будет сказано, но я даже не предполагал, насколько дешево Вы цените собственное время.
Исходя из того, что изготавливать и паять антенну, как минимум 5 минут, то получается, что час Вашей работы стоит не более 240 рублей. Напишите в личку. По такой часовой ставке я найду для Вас просто море работы паяльником.
думал вам интересно будет
Вы знали, что это не так, так как я написал: "С керамической антенной я даже не пытался брать модули, так как много отрицательных отзывов."
Ну что же, я рад, что до Вас наконец-то дошло, что поддержка open source обходится намного дороже, чем поддержка вендора. Что, собственно говоря, и объясняет, почему тот же Linux в корпоративных кругах широко распространен, а в SOHO встречается очень редко. Первые могут позволить себе содержать штат для поддержки open source решений, а вторые - нет.
Сжатый protobuf явно будет занимать меньше места, чем такой же сжатый json. Но не забывайте, что даже на 10 Гбит сжатие наверняка увеличит задержки и, скорее всего, снизит скорость. А уж на 40/100 Гбит, обычных для обмена данными внутри k8s, сжатие вообще бессмысленно. Иными словами, если достаточно 100 Мбит сети, то преимущества двоичных неочевидны. А уже на 10 Гбитах сразу увидите разницу.
Не забывайте ещё, что нагрузка CPU при преобразовании чисел из символьного представления в двоичное или обратно будет существенно различаться от нагрузки при декодировании или кодировании в двоичном формате.
А смысл? Ради 20 рублей экономии тратить время на такой колхоз не оправдано даже школьнику или пенсионеру. Я понимаю ещё тех, кто уже нарвался на такое чудо. Но зачем намеренно искать себе приключения?
Вы лично готовы вложить 30-40 миллионов рублей в такой бизнес, чтобы продержаться хотя бы год до весьма маловероятного выхода на самоокупаемость? Если нет, то почему Вы считаете, что кто-то другой должен это сделать?
совершенно не лечит
Врать не надо. Проприетарные решения работают у миллиардов людей. И у Вас в том числе. Или у Вас в автомобиле open source прошивка в ЭБУ? )))
Если пользователь захочет платить в разы больше за поддержку открытого решения, то почему бы и нет? Как раз наоборот, это возможность существенно увеличить выручку. Вот только таких пользователей слишком мало, чтобы даже десятикратное увеличение стоимости поддержки смогло окупить содержание собственного отдела разработки.
Сами посчитайте. Стоимость содержания отдела разработки - 2-3 миллиона рублей ежемесячно. А большинство внедренцев имеют клиентскую базу до тысячи заказчиков. Вы сами согласитесь платить за поддержку 3-5 тысяч рублей ежемесячно, чтобы не вникать и только пользоваться IoT, как домофоном или шлагбаумом?
С керамической антенной я даже не пытался брать модули, так как много отрицательных отзывов. А вот такой и такой модули до 600 метров прямой видимости цепляются к AP и работают устойчиво даже сквозь лобовое стекло автомобиля, лежа на торпеде.
И за чей счёт банкет? С точки зрения поставщика решения, обслуживать открытые решения существенно дороже, чем закрытые проприетарные. Хотя бы потому, что пользователь рано или поздно влезет туда своими шаловливыми ручками. Ведь всё открыто и доступно.
Если вы не хотите вникать и обслуживать, то лучше ничего не покупать
Вот только есть пользователи, которые не хотят вникать и обслуживать, но хотят покупать. Предлагаете им отказывать?
Люди разные. Потребности, возможности, желания и навыки у людей тоже разные.
Кто-то согласен жить с тем же ESPHome, потому что ему не сильно мешает одна из полутора тысяч известных проблем и не требуется одна из полутора тысяч новых возможностей (количество смотрю по GitHub).
А мне и без открытых решений хорошо, так как мне проще написать свой код и его поддерживать, чем разбираться с исходниками тех же HA и ESPHome, чтобы туда коммитить. Зато обхожусь без центрального сервера и у меня нет единой точки отказа.
А кто-то просто хочет, чтобы у него всё работало и готов платить за поддержку, чтобы самому не вникать. Точно так же, как не вникают в работу системы вентиляции и кондиционирования, домофона или автоматического шлагбаума.
не сталкивался с заводскими интерпретациями mesh сетей для IOT тройств на основе wi-fi
Я тоже. Так как до сих пор отсутствует поддержка EPS-MESH/ESP-MESH-LITE в HA/ESPHome. Если с ESP-MESH проблема понятна, то в ESP-MESH-LITE каждый узел получает свой IP адрес у роутера, пусть даже через корневой узел. Так что я затрудняюсь сказать, что мешает реализовать его поддержку в ESPHome.
Какие у вас в ней устройства
Сейчас все устройства на ESP32-C3 и все прошитые моим же кодом. Управление пока только по HTTP непосредственно через веб-сервер в ESP32.
Как много устройств, не будут ли 10-20 устройств замедлять и создавать помехи в основную wi-fi сеть, они же вероятно забивают все свободные каналы и опрашиваются каждые N секунд.
Тестировал пока только 10 ESP32-C3 так больше у меня нет. Опрос из js каждую секунду в 10 вкладках браузера, вполне совмещался с полной загрузкой WiFi торрентом с ноутбука. Но у меня они не пересекаются, так как ноутбук 802.11ac 5ГГц, а ESP32 802.11g 2.4ГГц.
Видно, что AP в узлах ESP-MESH-LITE предпочитают другие каналы, чем у WiFi роутера. Соответственно, мешать ему они ему вряд ли могут.
Сам Espressif пишет следующее:
Below are some common performance metrics for the ESP-MESH-LITE network:
Provisioning time: < 60 seconds
Repair time
Root node disconnection: < 50 seconds
Child node disconnection: < 45 seconds
Per-Hop delay: 8 to 12 ms
Notes
The test conditions for the above performance metrics are shown below.
Number of test devices: 50
Maximum number of downstream connections allowed: 6
Maximum number of layers allowed: 6
Что думаете об использовании подобных решений в многоквартирных домах?
Смотря насколько забит диапазон 2.4ГГц. Где-нибудь в общежитии с гипсокартонными стенами это может быть проблемой.
По моей практике часто wi-fi устройства вроде терморегуляторов или умных выключателей света обладают крайне слабым приёмником и будучи установлены куда-нибудь в подрозетник бетонной стены с арматурой могут терять связь с роутером уже через две комнаты.
Одни технологии, такие как Zigbee и Z‑Wave, Thread, ориентированы на построение устойчивых и масштабируемых Mesh‑сетей, в то время как другие, например Matter и Wi‑Fi
Не совсем так. Espressif предлагает для WiFi поддержку ESP-MESH и ESP-MESH-LITE. При этом я вижу устойчивую дальность в своей деревне до 600 метров. Так что для загородного применения, когда участок 20 соток или более, WiFi, особенно с ESP-NOW, может быть заметно предпочтительней, чем ZigBeе или BLE.
А это уже перетекает в холивар на тему архитектур, и я не очень хочу участвовать конкретно в этом.
Но сами начинаете холивар на тему сравнения CLang и GCC? )))
Они разные. И одно это уже хорошо.
вижу чаще clang
Я уже подробно описывал текущую ситуацию. Почитайте.
Так же не следует забывать об отличиях Apache и GPL лицензий.
отличаются своей скоростью
Ответ неверный. Особенно при использовании NGen или GraalVM, компилирующих в машинный код.
Причины две.
Необходимость среды выполнения, что не позволяет, например, писать обработчики прерываний или свободно, без тяжелых прослоек вроде C++/CLI, использовать динамическое связывание библиотек написанных на .NET или Java из любых других языков.
Субъективно, последние годы C# развивается существенно быстрее Java. Но сейчас быстро развивается Kotlin. Так что, лично с моей точки зрения, между C# и Java/Kotlin - паритет.
За мелочи, вроде отсутствия в C# "из коробки" BigDecimal, как в Java, я цепляться не хочу.
В этом и есть смысл существования этих языков в GCC
Каких именно? Rust, Go, C, C++? Вы знаете им альтернативы?
Специфическое использование.
За 2024 год было продано ~3 миллиарда RISC-V CPU на сумму почти 20 миллиардов долларов США. Прогноз на 2030 год - ~16 миллиардов чипов RISC-V на сумму около 100 миллиардов долларов США. Я бы сказал, что скорее amd64 грозит стать нишевым продуктом.
C# это чудесный мир
С# действительно хорош только когда необходима рефлексия, вплоть до генерации и компиляции кода на лету. В таких случаях я его с удовольствием использую. В остальных случаях, как и Java, его используют исключительно из-за более низкой стоимости разработки, по сравнению с компилируемыми в машинный код языками.
Попробуйте догадаться, почему, для примера, MS SQL Server или Hyper-V не написаны на C# и никогда не будут на него переписаны )
Очень интересно, как Вы собрались в 100 байт уместить дефектоскопию даже одного колеса, не говоря уже о всех восьми )))
Неравномерность, это когда за минуту мимо 20 тысяч дефектоскопов по всей стране проехало 10 тысяч вагонов, а за последующие 59 минут - сотня.
Во-первых, данные приходят неравномерно, а низкая латентность необходима. Ничего об этом не слышали?
Во-вторых, прочитайте полностью список, чтобы опять не выглядеть глупо.
На проде сейчас около пятиста. Но у нас 40/100 гигабитка.
Самый большой объем - трекинг транспорта (только полувагонов сотня тысяч), обмен с АСУ ТП двух портов и десятка комбинатов/заводов/фабрик.
Само собой, данные обогащаются из нескольких источников.
Не в обиду будет сказано, но я даже не предполагал, насколько дешево Вы цените собственное время.
Исходя из того, что изготавливать и паять антенну, как минимум 5 минут, то получается, что час Вашей работы стоит не более 240 рублей. Напишите в личку. По такой часовой ставке я найду для Вас просто море работы паяльником.
Вы знали, что это не так, так как я написал: "С керамической антенной я даже не пытался брать модули, так как много отрицательных отзывов."
Ну что же, я рад, что до Вас наконец-то дошло, что поддержка open source обходится намного дороже, чем поддержка вендора. Что, собственно говоря, и объясняет, почему тот же Linux в корпоративных кругах широко распространен, а в SOHO встречается очень редко. Первые могут позволить себе содержать штат для поддержки open source решений, а вторые - нет.
Сжатый protobuf явно будет занимать меньше места, чем такой же сжатый json. Но не забывайте, что даже на 10 Гбит сжатие наверняка увеличит задержки и, скорее всего, снизит скорость. А уж на 40/100 Гбит, обычных для обмена данными внутри k8s, сжатие вообще бессмысленно. Иными словами, если достаточно 100 Мбит сети, то преимущества двоичных неочевидны. А уже на 10 Гбитах сразу увидите разницу.
Не забывайте ещё, что нагрузка CPU при преобразовании чисел из символьного представления в двоичное или обратно будет существенно различаться от нагрузки при декодировании или кодировании в двоичном формате.
Ответьте на заданные мной вопросы, а после этого я буду отвечать на Ваши.
А смысл? Ради 20 рублей экономии тратить время на такой колхоз не оправдано даже школьнику или пенсионеру. Я понимаю ещё тех, кто уже нарвался на такое чудо. Но зачем намеренно искать себе приключения?
Вы лично готовы вложить 30-40 миллионов рублей в такой бизнес, чтобы продержаться хотя бы год до весьма маловероятного выхода на самоокупаемость? Если нет, то почему Вы считаете, что кто-то другой должен это сделать?
Врать не надо. Проприетарные решения работают у миллиардов людей. И у Вас в том числе. Или у Вас в автомобиле open source прошивка в ЭБУ? )))
Если пользователь захочет платить в разы больше за поддержку открытого решения, то почему бы и нет? Как раз наоборот, это возможность существенно увеличить выручку. Вот только таких пользователей слишком мало, чтобы даже десятикратное увеличение стоимости поддержки смогло окупить содержание собственного отдела разработки.
Сами посчитайте. Стоимость содержания отдела разработки - 2-3 миллиона рублей ежемесячно. А большинство внедренцев имеют клиентскую базу до тысячи заказчиков. Вы сами согласитесь платить за поддержку 3-5 тысяч рублей ежемесячно, чтобы не вникать и только пользоваться IoT, как домофоном или шлагбаумом?
С керамической антенной я даже не пытался брать модули, так как много отрицательных отзывов. А вот такой и такой модули до 600 метров прямой видимости цепляются к AP и работают устойчиво даже сквозь лобовое стекло автомобиля, лежа на торпеде.
И за чей счёт банкет? С точки зрения поставщика решения, обслуживать открытые решения существенно дороже, чем закрытые проприетарные. Хотя бы потому, что пользователь рано или поздно влезет туда своими шаловливыми ручками. Ведь всё открыто и доступно.
Вот только есть пользователи, которые не хотят вникать и обслуживать, но хотят покупать. Предлагаете им отказывать?
Люди разные. Потребности, возможности, желания и навыки у людей тоже разные.
Кто-то согласен жить с тем же ESPHome, потому что ему не сильно мешает одна из полутора тысяч известных проблем и не требуется одна из полутора тысяч новых возможностей (количество смотрю по GitHub).
А мне и без открытых решений хорошо, так как мне проще написать свой код и его поддерживать, чем разбираться с исходниками тех же HA и ESPHome, чтобы туда коммитить. Зато обхожусь без центрального сервера и у меня нет единой точки отказа.
А кто-то просто хочет, чтобы у него всё работало и готов платить за поддержку, чтобы самому не вникать. Точно так же, как не вникают в работу системы вентиляции и кондиционирования, домофона или автоматического шлагбаума.
Я тоже. Так как до сих пор отсутствует поддержка EPS-MESH/ESP-MESH-LITE в HA/ESPHome. Если с ESP-MESH проблема понятна, то в ESP-MESH-LITE каждый узел получает свой IP адрес у роутера, пусть даже через корневой узел. Так что я затрудняюсь сказать, что мешает реализовать его поддержку в ESPHome.
Сейчас все устройства на ESP32-C3 и все прошитые моим же кодом. Управление пока только по HTTP непосредственно через веб-сервер в ESP32.
Тестировал пока только 10 ESP32-C3 так больше у меня нет. Опрос из js каждую секунду в 10 вкладках браузера, вполне совмещался с полной загрузкой WiFi торрентом с ноутбука. Но у меня они не пересекаются, так как ноутбук 802.11ac 5ГГц, а ESP32 802.11g 2.4ГГц.
Видно, что AP в узлах ESP-MESH-LITE предпочитают другие каналы, чем у WiFi роутера. Соответственно, мешать ему они ему вряд ли могут.
Сам Espressif пишет следующее:
Below are some common performance metrics for the ESP-MESH-LITE network:
Provisioning time: < 60 seconds
Repair time
Root node disconnection: < 50 seconds
Child node disconnection: < 45 seconds
Per-Hop delay: 8 to 12 ms
Notes
The test conditions for the above performance metrics are shown below.
Number of test devices: 50
Maximum number of downstream connections allowed: 6
Maximum number of layers allowed: 6
Смотря насколько забит диапазон 2.4ГГц. Где-нибудь в общежитии с гипсокартонными стенами это может быть проблемой.
Сам Espressif именно на это и упирает.
Не совсем так. Espressif предлагает для WiFi поддержку ESP-MESH и ESP-MESH-LITE. При этом я вижу устойчивую дальность в своей деревне до 600 метров. Так что для загородного применения, когда участок 20 соток или более, WiFi, особенно с ESP-NOW, может быть заметно предпочтительней, чем ZigBeе или BLE.
И опять ответ неверный )
Лучше или хуже может быть только для конкретной задачи. Есть задачи, для которых лучше CLang и есть задачи, для которых лучше GCC.
Пруф? Вот у меня он есть. А у Вас?
Но сами начинаете холивар на тему сравнения CLang и GCC? )))
Они разные. И одно это уже хорошо.
Я уже подробно описывал текущую ситуацию. Почитайте.
Так же не следует забывать об отличиях Apache и GPL лицензий.
Ответ неверный. Особенно при использовании NGen или GraalVM, компилирующих в машинный код.
Причины две.
Необходимость среды выполнения, что не позволяет, например, писать обработчики прерываний или свободно, без тяжелых прослоек вроде C++/CLI, использовать динамическое связывание библиотек написанных на .NET или Java из любых других языков.
Непредсказуемые задержки из-за сборщика мусора.
У меня за последние лет 10 был целый ворох проектов на C#. Ни разу даты модификации файлов случайно не менялись. Так что это руки, а не C#.
Субъективно, последние годы C# развивается существенно быстрее Java. Но сейчас быстро развивается Kotlin. Так что, лично с моей точки зрения, между C# и Java/Kotlin - паритет.
За мелочи, вроде отсутствия в C# "из коробки" BigDecimal, как в Java, я цепляться не хочу.
Каких именно? Rust, Go, C, C++? Вы знаете им альтернативы?
За 2024 год было продано ~3 миллиарда RISC-V CPU на сумму почти 20 миллиардов долларов США. Прогноз на 2030 год - ~16 миллиардов чипов RISC-V на сумму около 100 миллиардов долларов США. Я бы сказал, что скорее amd64 грозит стать нишевым продуктом.
С# действительно хорош только когда необходима рефлексия, вплоть до генерации и компиляции кода на лету. В таких случаях я его с удовольствием использую. В остальных случаях, как и Java, его используют исключительно из-за более низкой стоимости разработки, по сравнению с компилируемыми в машинный код языками.
Попробуйте догадаться, почему, для примера, MS SQL Server или Hyper-V не написаны на C# и никогда не будут на него переписаны )