elman434, вам каждый раз удаётся виртуозно отвечать не проясняя до конца ситуацию.
Там вторая лебедка для закрывания? Или вы трос переставляете? У лебёдки храповик в одну сторону работает или переключается?
Ложка в мозге, иногда неопытные программисты неправильно работают с путями и делают неправильные предпосылки. К примеру, часто люди пытаются соединять пути как обычные строки конкатенацией. Иногда это делают не пытаясь анализировать абсолютный там путь или нет. Само собой, что добавив что-то слева от абсолютного пути мы получим какую-то ерунду в большинстве случаев.
Используйте pathlib. В современном питоне это встроенная библиотека. Она навязывает программисту более правильный способ работы с путями и вводит абстракции, позволяющие автоматически избежать некоторых проблем.
Ну и самое главное -- это очень удобно!
Армянское Радио, да всё правильно, я с вами не спорю. Но что-то мне подсказывает, что пофигу за какое вменяемое время эти форточки откроются. Если человек "легко рукой крутит", то слабенький моторчик от стеклоподъёмника (а там вёсла крутить тоже не сложно) примерно справится.
Армянское Радио, да какой там киловаттный? 800 кгс - это на выходе. При десятикратном коэффициенте, который вы, полагаю, с потолка взяли (ну в смысле оценочно, нчего тут плохого, я не наезжаю), на валу рукоятки (при учете его небольшого диаметра) будет 80 кгс. Это не так много для мотор-редуктора. И, опять же, это верхняя оценка. Автор легко крутил это рукояткой (сантиметров 20), так она тоже даёт плечо x40 получается. Вот вам и те же пара тройка кило на рукоятке.
Автору следовало бы подетальнее описать радиусы шестерней, крупно их сфотать, посчитать зубья, сказать какой ход у троса (надо ли его наматывать в несколько рядов или для закрытия форточек достаточно туда-сюда 20 см троса промотать.
Вопрос поставлен очень хреново.
Думаю там у него обычный мотор-редуктор от вазовского стеклоподъёмника со свистом справится. Если нет, можно шестерню добавить одну и точно справится.
Армянское Радио, да понятно, но если никаких замеров и дополнительной инфы нет, то, видимо, следует исходить из 800кгс на выходе. Вообще можно очень хорошо прикинуть плюс-минус усилие, если посчитать зубья и посмотреть во сколько слоёв может намотаться трос.
Имеет смысл, если уж колхозить, то покрыть номинальные допустимые параметры исходной лебедки.
Владимир Олохтонов, а что может быть проще и надёжнее очередей? Это не ваш код, он сделан качественно для куда бОльших нагрузок, он изолирован, запускается в отдельном докере, хорошо задокументирован и все подводные камни его использования давно и тщательно исследованы.
Чтение из очереди и запись в БД - отдельный тривиальный процесс. Работает в один поток, масштабируется простым запуском любого нужного количества таких процессов. Решение изолированное, средствами очереди нормально обрабатываются падения и дисконнекты при перезапусках.
Осталось самое интересное - приём пакетов. Тут я с вами вынужден согласиться. Действительно, если заработает более простое решение, то имеет смысл его придерживаться. Но вам всё равно захочется несколько бэкендов, как-то бесшовно их переключать при обновлениях... Если асинхронное решение будет близкО к самому типовому случаю применения выбранного фреймворка, а фреймворк достаточно надёжный, то нет ничего плохого и такого уж сложного в асинхронности. Тем более под тот же капот вам не придётся прятать работу с БД,
Ну можно поиграться с онлайн конструкторами кроновских расписаний типа этого, или погуглить вот, к примеру.
Но я бы, раз уж вам приспичило именно раз в 90 минут, сделать две записи в кронтабе, обе с интервалом в три часа и со сдвигом в полтора на старте.
z0ng, разделите процессы приёма сообщений и записи их в БД персистентной очередью. Это сделает предсказуемыми нагрузки на все части системы, позволит горизонтально отмасштабировать отдельно приём и отдельно запись в БД.
Приём, конечно, лучше сделать асинхронным.
z0ng, ну тогда конечно. Но возможно ваша задача неплохо горизонтально масштабируется? Насколько разнообразны и велики по объёму данных передачи от этих устройств?
