Потом могу выложить lsync + api.OldBean, 13 Авг. 19, 05:02
Буду ждать с нетерпением.
сделано более "дружественное" именование ключей. Например, ключи для температур это 'T0', 'T1'..., давлений: 'P0', 'P1'..., клапаны отбора (контроллеры PWM) - это 'q0', 'q1', 'q2'... для скоростей отбора и 'Q0', 'Q1', 'Q2' для суммарных расходов через них и т.д.OldBean, 13 Авг. 19, 05:02
Вот! абсолютно с Вами согласен! Я пришел к этой же мысли, просто в предыдущем своем посте не стал эту тему смешивать с проблемами безопасности... Рассматривал даже два варианта подобных именований:
1. Именовать последовательно все обнаруженные однотипные устройства не зависимо от канала хаба к которому они подключены. Т.е. датчики температуры, подключенные к каналам 1, 3 и 5 хаба в системе появились бы как Т0, Т1 и Т2, а датчики давления, подключенные к каналам 2 и 4 - как P0 и Р1.
2. Именовать двухзначным индексом с учетом номера хаба и канала. Первая цифра - номер хаба (их ведь может быть несколько). Для предыдущего примера: T01,T03,T05 и P02,P04
Проанализировав оба варианта более склонился к первому, т.к. клиент будет отвязанным от железа, то ему все равно к какому каналу и хабу что подключено, важно лишь количество и порядок подключения чтобы можно было отличить один датчик от другого. Также по поводу ключей была мысль, что вообще не обязательно каждому датчику давать свое индивидуальное имя ключа, можно вообще использовать списковые типы ключей, редиска это позволяет, и обращаться к однотипным датчикам по индексу в списке: TEMP_SENSOR[0], TEMP_SENSOR[1] и т.п.
Сейчас клиент жестко завязан на фиксированное число датчиков. Если что-то недостает, например, не подключен один из датчиков температуры, то даже не запустится. Это безобразие. Для разных режимов работы необходим разный набор исходных данных:
- для первичной дистилляции браги на СС в минимуме достаточно только одного температурного датчика в кубе
- для ректификации в зависимости от сложности колонны нужно либо два датчика температуры (куб, деф), либо три (куб, деф, центр колонны), либо четыре и более (+датчики в ПБ и ЦП)
Кроме этого минимума факультативно (кому-то это надо, кому-то наплевать) могут быть датчики безопасности: температура в ТСА, вода на выходе, вода на входе и т.п. Если они есть, то учитывать их показания, если отсутствуют, то не учитывать.
Клиент должен видеть в базе лишь обезличенный набор датчиков: есть, например, пять датчиков температуры Т0-Т4, а вот связь какой датчик куда подключен это видимо надо решать уже в настройках клиента под конкретную задачу. Можно конечно как сейчас делать жесткую привязку: Т0 - это куб, Т1 - колонна, Т2 - деф, Т3 - ТСА и т.п., но тогда теряется гибкость конфигураций оборудования. Например, клиент видит что подключено 4 датчика и разбирает их по вышеизложенному принципу, но он не знает, что из 4 подключенных к системе датчиков в данный момент я использую только два (куб и деф), на безопасность (ТСА) мне сегодня наплевать, а датчик колоны воткнуть просто некуда т.к. в данный момент я поставил колпачковую колонну без отверстия для центрального датчика. А четыре их видится потому что у меня все оборудование стационарно собрано и я не стал выдергивать разъемы: два неиспользованных датчика сейчас подключены, но просто рядом лежат. Т.е. в клиенте должна быть возможность указать, что из четырех видимых датчиков вот этот - в кубе, вот этот - в дефе, а вот эти два неиспользуемые. Тогда и алгоритм работы должен измениться и строиться не с учетом показаний трех датчиков (куб, колонна, деф), а только двух (куб, деф), а показания двух неиспользуемых могут отображаться чисто информативно. В идеале возможно что еще и для одной конфигурации предоставить выбор алгоритма работы, например: классический стар-стоп или последовательное уменьшение отбора или гибрид или что-то еще.
Добавлено через 50мин.:По концепции клиента:
То, что мне не нравится идея держать подключенным к блоку автоматики (к малинке) монитор и клавиатуру я уже писал выше. Критиковать конечно хорошо, но вот как я действительно хотел бы это видеть мысли были разные и решение до конца еще не сформировалось.
1. Работа без клиента
1.1. На блоке автоматики не зависимо от наличия/отсутствия монитора и клавиатуры хочу видеть дублирующий дисплей с отображением важнейших параметров. Думаю, достаточно будет текстового LCD 20 символов на 4 строки, подключенного через переходник на I2C шину. Для себя в изготовлении такого вообще проблем не вижу. Выводить текущую информацию на него может синхронизатор, который должен запускаться после загрузки малинки в фоне как системный сервис.
1.2. Не хочу совсем отказываться от аппаратных кнопок на корпусе, как минимум: мощность нагрева, величина открытия клапана. До этого проекта экспериментировал у себя на эту тему с ардуинками - для этих целей идеально подходят инкрементальные энкодеры. Прямо вообще супер получается: ставишь две крутилки-энкодера, на каждый на разные события можно навесить кучу функций (медленный поворот, быстрый поворот, поворот в нажатом состоянии, одиночное нажатие, быстрое двойное-тройное нажатие, нажатие с длительным удерживанием). Совместно с дисплеем из п.1 это позволит использовать автоматику вообще без клавы и дисплея для простейших операций в ручном режиме. В автоматическом режиме при работе по программе реакцию на энкодеры можно отключать либо использовать их для других целей.
2. Простейший клиент. Если не требуются графики, не хочется долго смотреть ни в какие экраны, имеется необходимый набор оборудования и программа полностью автоматизирующая процесс, то достаточно простейшей менюшки с текстовым интерфейсом. Например: открыл терминальное окно по ssh, запустил в нем какой-нибудь tmux чтобы при закрытии окна все не прервалось, затем запустил программу управляющую процессом (можно на том же питоне), выбрал из меню нужный алгоритм работы, закрыл терминальное окно, пошел спать. При особом любопытстве важные параметры, ход и шаги процесса можно контролировать на дисплейчике из п.1.1. или зайдя в терминальное окно повторно.
3. Web клиент. Все это же самое что есть в п.2. можно реализовать без терминального окна. Поставить на малинку маленький web сервер и управлять через него режимами работы из браузера. Из плюсов: тут можно и графики пристроить рядом красивые и с телефона или планшета зайти... Язык программирования может быть тот же питон.
4. Красивый графический клиент. Подобно текущему, но функциональнее. :-) С кнопочками, окошечками, рюшечками, закладками. Запускать либо локально на малинке если к ней подключены монитор, клавиатура, мышь, либо, если ничего этого нет, зайдя на малинку удаленно через VNC (как я это делаю сейчас).
5. Сетевой графический клиент. Как в п.4., только запускаться клиент будет в другом месте на компьютере, планшете, телефоне, подключение к малине по IP. Редиска это позволяет.
В общем, вариантов развития много. Пока зафиксировал все что пришло в голову чтобы не забылось.
OldBean, 13 Авг. 19, 05:02
