не сталкивался с заводскими интерпретациями 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# и никогда не будут на него переписаны )
Большинство современных языков программирования вообще собираются одной командой
А если проект гетерогенный? В простейшем случае может быть необходимость деплоя SQL кода и алгоритмического языка для сервиса. В более сложных нужно еще компилировать схему Protobuf, деплоить sink для Kafka, скрипт в AirFlow, yaml в k8s и т.п.
очень много какие программы творят с датами дичь
На самом деле очень немногие. MSBuild, Cargo и прочие системы сборки поступают по такому же принципу. В крайнем случае всегда есть make clean.
GCC сборник компиляторов для архаичных языков
Но для современных архитектур. Не складывается.
По крайней мере для последних RISC-V CPU LLVM может предложить только ассемблер или экспериментальную поддержку. Тогда как производитель CPU/SoC GNU toolchain (как раз включая make и gcc) предоставляет почти всегда.
моё мнение C#-огузка
А посмотрите на csproj для сборки простейшего gRPC сервиса. Уже появится
А можно поподробнее чего там llvm не имеет, мы применяем для ARM, пока никаких проблем не встречали
С ARM у LLVM всё хорошо, за исключением поддержки сопроцессоров. Но это отдельная история. Тот же PIO в RP2040 можно и на ассемблере программировать. С Integer Divider в RP2040 ситуация хуже, так как совершенно непонятно, как в Rust отсчитать восемь тактов.
Куда веселее, когда в CPU/SoC ядра и ARM, и RISC-V.
чего там не так с risc-v?
Если упрощенно, то или поддержка экспериментальная (как у E), или через ассемблер (как у H и Q).
Если копнуть глубже, то есть проблемы с оптимизацией. Например, IR в LLVM хорошо ложится на флаги (ZNCV), которые есть в ARM и amd64, но которых в принципе нет в RISC-V.
Если упрощенно, то выражение if a > b { ... } else { ... } ; при целочисленных a и b для IR две команды, а для RISC-V - одна.
По этой причине, например, Milk-V предлагают GCC toolchain.
Они неизбежно отстают от rustc, разработчики которого считают rustc референсной реализацией Rust, что особенно заметно при попытке использовать std library. В случае no_std явных проблем нет.
Например, ESP32-C5 rustc вообще пока не поддерживается и судьба его неясна, так как в LLVM поддержки Xhwlp нет даже в планах, а Zcmt поддерживается только ассемблером. При этом Espressif кодогенератор GCC для него уже опубликовал, следовательно gccrs должен работать. Но я не пробовал, так как ESP32-C5 официально стал доступен только с 1 мая 2025 года.
Я уже теряю надежду увидеть в Rust стабильный ABI, вместо костыля abi_stable с extern "C".
Я понимаю, что консольные утилиты можно собирать и со статическим связыванием. Но что-то более-менее серьёзное без динамического связывания нежизнеспособно.
Уже молчу о стандарте языка, который всё более востребован в связи все с более частой необходимостью использовать GCC или форки rustc для компиляции под RISC-V или иные платформы, для которых LLVM по ряду причин не имеет стабильного кодогенератора.
Автор заметно упрощает. Fillfactor 85 обозначает увеличение объема всей таблицы на 15%. А на многих профилях нагрузки UPDATE выполняется преимущественно для относительно недавно созданных записей. То есть, операций обновления вроде бы и много, но они затрагивают 3-5% страниц кучи.
В подобных случаях увеличение fillfactor до 85-90% оправдано только в сочетании с партиционированием. Например, когда данные за последний месяц находятся в разделе с заполнением 85%, а остальные данные - в разделах с заполнением 100%
Для справочников, когда старые версии записей при обновлении поля окончания действии записи автоматически переносим в другой раздел, установка fillfactor смысла не имеет.
На самом деле первые критерии малозначимы. Данные для фискального учета можно выгружать в 1С бухгалтерию. Зарплату и кадры можно вести в Босс Кадровик. А вот выбор ERP с оперативным учетом, планированием, оптимизацией, тесной интеграцией с АСУ ТП, электронными торговыми площадками и B2B системами логистики - это уже задача посложнее. Тут во главе угла оказывается открытость к расширениям, совместимость с компонентами различных поставщиков через поддержку широкого спектра стандартов взаимодействия, масштабируемость и гетерогенная модульность.
Вы считать умеете? По проводкам получится собрать только баланс, отчет о финансовых результатах и два приложения к ним. Отчет о целевом использовании и пояснения к балансу собрать не получится. Так же не получится собрать декларации по налогу на прибыль, имуществу, НДПИ, ЕСХН, НДС, акцизам, подоходному налогу, РСВ, страховым взносам, персонифицированному учету и т.п.
Вы слишком увлеклись демагогией. Исходя из того, что я привел примеры внедренной непрерывной оптимизации для всех перечисленных Вами ERP, то не вижу смысла повторять их список. Так же как и не вижу смысла обсуждать подключение ККМ, не поддерживающей ни USB, ни Bluetooth, ни TCP/IP.
А реализовать обертки для всего спектра драйверов, компонентов и библиотек силами 1С разработчиков не реально. Так же как и поддерживать их в течение всего жизненного цикла. Это даже не рассматривая стоимость таких разработок и поддержки.
Я тоже. Так как до сих пор отсутствует поддержка 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# и никогда не будут на него переписаны )
А если проект гетерогенный? В простейшем случае может быть необходимость деплоя SQL кода и алгоритмического языка для сервиса. В более сложных нужно еще компилировать схему Protobuf, деплоить sink для Kafka, скрипт в AirFlow, yaml в k8s и т.п.
На самом деле очень немногие. MSBuild, Cargo и прочие системы сборки поступают по такому же принципу. В крайнем случае всегда есть make clean.
Но для современных архитектур. Не складывается.
По крайней мере для последних RISC-V CPU LLVM может предложить только ассемблер или экспериментальную поддержку. Тогда как производитель CPU/SoC GNU toolchain (как раз включая make и gcc) предоставляет почти всегда.
А посмотрите на csproj для сборки простейшего gRPC сервиса. Уже появится
У меня в проекте csproj бывают килобайт по 20 с кучей Condition, Import, DependentUpon и т.п.
Для простых сборок MSBuild удобней make, Но make намного более гибок.
С ARM у LLVM всё хорошо, за исключением поддержки сопроцессоров. Но это отдельная история. Тот же PIO в RP2040 можно и на ассемблере программировать. С Integer Divider в RP2040 ситуация хуже, так как совершенно непонятно, как в Rust отсчитать восемь тактов.
Куда веселее, когда в CPU/SoC ядра и ARM, и RISC-V.
Если упрощенно, то или поддержка экспериментальная (как у E), или через ассемблер (как у H и Q).
Если копнуть глубже, то есть проблемы с оптимизацией. Например, IR в LLVM хорошо ложится на флаги (ZNCV), которые есть в ARM и amd64, но которых в принципе нет в RISC-V.
Если упрощенно, то выражение if a > b { ... } else { ... } ; при целочисленных a и b для IR две команды, а для RISC-V - одна.
По этой причине, например, Milk-V предлагают GCC toolchain.
Для Espressif тоже есть тонкости. Требуется:
Espressif Rust fork with support for Espressif targets
nightlytoolchain with support forRISC-VtargetsLLVMfork with support forXtensatargetsGCC toolchain that links the final binary
Они неизбежно отстают от rustc, разработчики которого считают rustc референсной реализацией Rust, что особенно заметно при попытке использовать std library. В случае no_std явных проблем нет.
Например, ESP32-C5 rustc вообще пока не поддерживается и судьба его неясна, так как в LLVM поддержки Xhwlp нет даже в планах, а Zcmt поддерживается только ассемблером. При этом Espressif кодогенератор GCC для него уже опубликовал, следовательно gccrs должен работать. Но я не пробовал, так как ESP32-C5 официально стал доступен только с 1 мая 2025 года.
И где это чашка кофе $30?
Вот RP2040 - это действительно по цене чашки кофе. Хотя Linux туда всунули уже с трудом и только после добавления внешней SPI PSRAM.
Я даже SQL собираю make. Например, проект размером в 20 МБ RedGate деплоит почти 10 минут, а через make получается 5-6 секунд.
Я уже теряю надежду увидеть в Rust стабильный ABI, вместо костыля abi_stable с extern "C".
Я понимаю, что консольные утилиты можно собирать и со статическим связыванием. Но что-то более-менее серьёзное без динамического связывания нежизнеспособно.
Уже молчу о стандарте языка, который всё более востребован в связи все с более частой необходимостью использовать GCC или форки rustc для компиляции под RISC-V или иные платформы, для которых LLVM по ряду причин не имеет стабильного кодогенератора.
Да, Вы правы. Спасибо! Но редактировать комментарий сайт уже не позволяет (
Автор заметно упрощает. Fillfactor 85 обозначает увеличение объема всей таблицы на 15%. А на многих профилях нагрузки UPDATE выполняется преимущественно для относительно недавно созданных записей. То есть, операций обновления вроде бы и много, но они затрагивают 3-5% страниц кучи.
В подобных случаях увеличение fillfactor до 85-90% оправдано только в сочетании с партиционированием. Например, когда данные за последний месяц находятся в разделе с заполнением 85%, а остальные данные - в разделах с заполнением 100%
Для справочников, когда старые версии записей при обновлении поля окончания действии записи автоматически переносим в другой раздел, установка fillfactor смысла не имеет.
На самом деле первые критерии малозначимы. Данные для фискального учета можно выгружать в 1С бухгалтерию. Зарплату и кадры можно вести в Босс Кадровик. А вот выбор ERP с оперативным учетом, планированием, оптимизацией, тесной интеграцией с АСУ ТП, электронными торговыми площадками и B2B системами логистики - это уже задача посложнее. Тут во главе угла оказывается открытость к расширениям, совместимость с компонентами различных поставщиков через поддержку широкого спектра стандартов взаимодействия, масштабируемость и гетерогенная модульность.
А теперь поинтересуйтесь не только приказами Минфина, но и приказами ФНС.
И перечитайте мой изначальный комментарий, который Вы пытаетесь оспаривать. Там отчетные формы для ФНС указаны явно.
Это не считаю, а ФНС.
Вы считать умеете? По проводкам получится собрать только баланс, отчет о финансовых результатах и два приложения к ним. Отчет о целевом использовании и пояснения к балансу собрать не получится. Так же не получится собрать декларации по налогу на прибыль, имуществу, НДПИ, ЕСХН, НДС, акцизам, подоходному налогу, РСВ, страховым взносам, персонифицированному учету и т.п.
Или в Вашей математике 4 больше 12?
Даже с Hana есть смысл сначала агрегировать проводки в модуле, а потом постить в FI и CO.
Вы слишком увлеклись демагогией. Исходя из того, что я привел примеры внедренной непрерывной оптимизации для всех перечисленных Вами ERP, то не вижу смысла повторять их список. Так же как и не вижу смысла обсуждать подключение ККМ, не поддерживающей ни USB, ни Bluetooth, ни TCP/IP.
А реализовать обертки для всего спектра драйверов, компонентов и библиотек силами 1С разработчиков не реально. Так же как и поддерживать их в течение всего жизненного цикла. Это даже не рассматривая стоимость таких разработок и поддержки.