Позволил себе внести несколько изменений в файлыekochnev, 05 Апр. 20, 19:51
Зря... У Вас другие цели и задачи. Поэтому вмешательства в lsync.py будут похожи на, как говорил Жванецкий, "подгонку фигуры под костюм". Интерфейсы через редиску или lite.py (через автоматически сгенерированные объекты) дают полную свободу разработчику. Поэтому модифицировать синхронизатор (с точки зрения его функциональности) не имеет смысла. Конечно, Вы можете делать с ним что хотите, но я не могу обещать, что буду учитывать все изменения. Особенно, если они связаны с изменением функциональности синхронизатора, а не с исправлением ошибок или улучшением качества кода.
Давайте я еще раз расскажу
что, как и для чего запланировано в этой версии (0.3.x.x) варианта LITE. Может быть Вы учтете эту логику в своей работе.
Моя задача (точнее - задача редиски и синхронизатора) - максимально упростить пользовательский интерфейс для пользователей-непрограммистов. Поэтому никаких функций типа ui, uicallback и uihelp в пользовательских скриптах быть не должно. Они сложные, неочевидные и небезопасные. То, что они сейчас там есть - это просто остатки слегка расширенных
отладочных вариантов скриптов. Они не предназначены для конечного пользователя. Я эти скрипты выкладывал просто для примера. Поэтому отработка клавиш q, r, h никак не должна быть связана ни с ui, ни с uicallback, ни с uihelp или какими-нибудь другими пользовательскими функциями. Так же, как и отработка цифровых клавиш. Они - тоже чисто отладочная примочка.
Другими словами:
работа пользователя в консоли синхронизатора не предусмотрена. Клиентское приложение должно крутиться в своем процессе, в своей консоли, если приложение консольное, и
работать с железом только через БД redis. А UI в консоли синхронизатора - это только для аварийных ситуаций и отладочных работ. Его "членораздельное" развитие и сопровождение не планировалось и не планируется.
Система может работать вообще безо всякого пользовательского скрипта, загружаемого в синхронизатор. В этом случае питоновское клиентское приложение (отдельный процесс) модифицирует поля в БД, используя модуль api.py или непосредственно средствами redis-py. Клиентское приложение может быть написано и не питоне. В этом случае оно должно использовать API самой редиски. Для соответствующего языка.
Для упрощения (можно сказать - "утоньшения" :) клиентского приложения предусмотрены загружаемые пользовательские скрипты, написанные на небольшом подмножестве языка Python. Такая работа особенно удобна для удаленной работы и/или нестабильном соединении с малинкой. В этом случае задача простейшего клиентского приложения заключается в:
1) конвертировании пользовательского скрипта при помощи утилиты conv.py,
2) компиляции пользовательского скрипта в байт-код,
3) загрузке байт-кода в поле uscript БД,
4) установке поля usinit БД в "неноль" и,
5) через некоторое время, установка поля mode в БД в значение, соответствующее, начальному (ненулевому) режиму работы установки.
Далее весь процесс будет происходить автоматически. Если, конечно, в каждом режиме пользовательского скрипта будут предусмотрены автоматическое его окончание и переход в следующий режим. После этого, можно рвать соединение, закрывать клиента или использовать его просто для контроля параметров. Пример загрузки пользовательского скрипта можно посмотреть в файле lsync.py функция loadUSF(). Ее можно использовать в клиенте с минимальными изменениями.
Пользовательский скрипт должен содержать последовательно следующие секции:
1. Список режимов (выражения Mode(...))
2. Список определений пользовательских переменных (имя = ...)
3. Список определений пользовательских функций (def имя(...))
4. Список безусловных и условных выражений для переключения режимов и обработке аварийных ситуаций (if ...).
Да и еще, в результате наших недавний обсуждений, было решено добавить список алиасов в начало скрипта. Так что теперь появится и 0-я секция - словарь алиасов.
Понятно, что, при таком подходе, UI клиентского приложения полностью отдан на откуп пользователю. Это может быть GUI, TUI или вообще какой-нибудь черт лысый... Никаких ограничений.
Итак, мы видим, что программных средств для работы с установкой вполне достаточно и не требует каких-либо модификаций синхронизатора со стороны разработчика клиентских приложений.
Кроме того, для пользователей-программистов, представляющих организацию железа, существует и непосредственный режим работы с железом при помощи экземпляров классов-оберток всех инсталлированных в крейт и хабы устройств. Объекты генерируются автоматически при импорте модуля lite.py.
Редиска и синхронизатор в этом режиме работы не нужны. После импорта lite.py в пространстве имен приложения доступен словарь сгенерированных объектов с именем obj. Этот словарь выводится на консоль при импорте. Ключ (hard-ключ) устройства в этом словаре представляет собой строку и выглядит так: addr_ch_fc, где addr - шестнадцатеричный адрес устройства на шине i2c, ch - номер канала (актуален для датчиков в хабах, а если каналов нет, то ставится затычка - 8) и fc - шестнадцатеричный код типа устройства. Понятно, что после импорта lite.py работать с железом можно как в ручном режиме, так и в автоматическом. Работать просто. Например, вот такой умозрительный фрагмент:
from lite import *
...
мой_ТЭН = obj['13_8_A3'] # Имена на unicode в старших релизах питона вполне допустимы
хаб = obj['15_8_A5']
T_в_царге = obj[15_2_28] # Датчик DS18B20 подключен ко второму каналу хаба
...
мой_ТЭН.on() # Включили нагрев на максимум
...
хаб.conv(); хаб.update()
if T_в_царге > 65.0:
мой_ТЭН.val = 600.0 # Перешли на рабочую мощность
...
мой_ТЭН.off() # Выключили нагрев и ушли
...
Как видим, в таком режиме тоже несложно работать. Но, наверное, таки не для непрограммистов. Понятно, что, на базе импортированных классов пользователь может создавать свои классы и объекты, используя весь арсенал питоновских механизмов наследования классов и перегрузки методов. Ну и ественно, что при таком подходе, тоже нет никаких ограничений на UI.
