воот... спасибо, возьму за основу, коль решусь делать на "рассыпухе".
Это то, на тему чего я уже давно и неспешно думаю, но не хочу :) Во-первых, у меня "плоховато" с операционниками - в детстве не поигрался, а сейчас чуть не с нуля разбираюсь, но почти не использую (потому и не освоил до сих пор). Даже понять, как правило, могу. И что-то подобное нарисовать, всего с парой-тройкой ошибок (Proteus / LTSpice спасают).
Собс-но не хочу именно по причине аналоговой части на "рассыпухи". Да - понятно, да - деталей немного. Но возня с наладкой пока отталкивает, ибо "для себя и совсем не срочно", а работа не ждёт...
ЗЫ: Вроде, видел схему на какой-то другой INA под это дело, но давно и не нашёл. Наверно потому и периодически ищу готовое, вместо "сесть и нарисовать самому" :)
Явной схемки нет. Хочу мониторить 12В батарею на (например) охранно-пожарном БП. Ну или чем-то от meanwell. Они разные и сразу сказать, что там как сделано, невозможно. И доп. условие - одавать это дело по "цифре" в одноплатник или что-то похожее с минимальным доп. обвесом и размерами.
Судя по их схемам, там "+" АКБ общий с выходом, а "-" бывает по-разному, но что-то типа полевика обычно там есть (например DRC-40A - схема заряда и котроля в "-" батареи https://static.chipdip.ru/lib/335/DOC011335221.pdf).
Красиво. Подробно. Не хватает дополнительного акцента, что это работает только в системах, где "-" общий...
А вот, кто бы мне подсказал подобный чип для мониторинга без общего минуса. Типичное - бесперебойник 12В, у которого "минус" батареи коммутируется полевиком и не является общим с цепью питания. Пока идея с питанием INA от той же АКБ с гальванической развязкой, но уж слишком хлопотно для домашних поделок, попроще бы чего
Если есть РУТ, можно поставить программный ограничитель заряда - год "несвежий" Mi-5 работает и не пухнет. Ну или народ городит внешнюю схему отключения: берётся "киоск", умеющий отдавать наружу процент заряда батареи (в моём случае был HabPanel, вроде, и WallPanel) - по MQTT получаем заряд и через внешнее реле включаем/отключаем зарядку в диапазоне 30-70 примерно.
Согласен. Но это уже детали реализации, навроде кольцевого буфера в EEPROM для экономии ресурса ячеек.
Тут или версию конфига+совместимость в парсинге оного (множим-копим старый код), или делить конфиг на части - сеть отдельно, остальное отдельно, или просто плевать и конфигурить заново после перепрошивки - зависит от задач.
Мои датчики на ESP живут с SPIFFS, на которой веб страницы, бинарный конфиг ESP и отдельно датчиков - но там всё равно веб+mqtt+wifi+файловый менеджер - оправдано. И да, при прошивке есс-но настройки не теряются (а давно ли я менял структуру конфига? лет 5 назад кое-где...)
Дык, и у меня микроконтроллерная часть в качестве хобби. Хоть и с самопальными платами и прошивками. Но, как-то, "для себя" требуются оба направления, а они слегка разные по подходу в реализации.
Узнал давно. Фирма заинтересовалась где-то весной, когда стало понятно, что Шнайдер - таки всё, а делать что-то надо %) С тех пор и стенд сделали, и (думали что) спалили модуль-другой, и проекты начинаем считать потихоньку. Весна придёт - поглядим.
Тут вопрос, в какую тему копать - автоматика в терминах "контроллеров" - WB в данном случае (полноценный linux), или МИКРО-контроллеров - две большие разницы. Хотя и к "большим" контроллерам, точнее софту, есть те же претензии...
Что не (на самом деле - тоже "да") надо экономить в "большом" контроллере через его конфигуратор, требует вдумчивого чтения мануалов на "железо" - в т.ч. чипы, - на "полевых" устройствах.
Для данной статьи хватило бы микроконтроллера из "базовых" ардуин - ATmega168/238 (Pro mini etc). Esp8266 избыточен совсем (wifi же тут не используется, а в ATmega168, и правда, есть настоящий EEPROM). Ну, пришлось бы рассказать про FreeModbus и её настройку под ардуину, но это отдельная увлекательная тема...
Про хранение В ДАННОМ СЛУЧАЕ (!) - нет EEPROM, FRAM, etc... ЕМНИП, EEPROM в esp8266 эмулировалась через 2 страницы FLASH с контролем корректности предыдущего сохранения, но могу ошибаться. И размер страницы, как бы не 1024 байт. Т.е. минимум 2048 байт "отъедается" на хранение 3-5 переменных. Про FS вообще молчу :) как хранилище web страниц для WiFi с возможностью закачки новых извне - да, а хранить настройки - бешеный overkill (там хранить-то 2-5-10 параметров), ну да - место-то пока есть...
делаем структуру с тем, что храним (для текстовых данных - фиксированная длина строки) чтобы не мудрить с логикой считывания
инициализируем её в коде значениями по-умолчанию
сохраняем её в, пусть, "EEPROM" (в данном случае - всё равно - FLASH), только если что-то поменялось. И, возможно, с задержкой в 5-60сек после последнего изменения - если юзер что-то меняет много где (но это уже изыски). Сохранение через write(... sizeof(struct config_struct)). Не знаю, может и .put подойдёт - ардуину в чистом виде уже лет 10 не пользовал, не помню. Максимум - PlatformIO + почти-С...
при старте также читаем блоком всю структуру (есс-но не напрямую в текущий конфиг). По-хорошему, в конце структуры хранить какой-то вид CRC - если не совпало, игнорим прочитанное
при старте в SafeMode - НЕ читаем конфиг и пользуемся значениями по-умолчанию
Если требуется хранить показания счётчиков - отдельная тема с циклическим буфером или внешней FRAM памятью - компромисс между умиранием памяти, ценой, наличием доп. модулей FRAM и частотой сохранения данных
Про опрос датчиков уже ответил @Winnie_The_Pooh , но добавлю - даже в мануалах к упоминаемым BMP180/280/DS18B20/etc указано, что частый опрос приводит к разогреву датчика вплоть до 1-2°С. Ибо опрос (тут, обычно...) запускает вычисление. Тем более с готовыми ардуиновскими библиотеками, которые не спрашивают по-готовности, а, как правило, принудительно опрашивают датчик и ждут ответа (кстати, ещё одно место косяка с модбасом - пока I²C не ответит - будет "висеть", учитывая как подвисает I²C именно в esp8266, это тоже может стать сюрпризом). Правильный подход:
а) спрашивать не чаще, чем это действительно надо
б) можно спрашивать чаще и хранить локально среднее, но без фанатизма
в) максимально использовать данные на датчик - настраивать частоту измерения в самом датчике и не спрашивать его чаще, чем это время
г) время измерения выбирать максимальное в пределах задачи. Например, температура помещения вряд ли нужна чаще раза в 1-5-10 минут - так и не надо его дёргать чаще 0.5-2.5-5 минут с усреднением. Или даже в 1-5-10 - в зависимости от задачи..
д) в модбас отдавать сохраненное значение, не привязывая чтение датчика к запросу от модбас-а (наверно, эта библиотека так и делает, не пользовался - не знаю)
Как -то так. Без претензий на абсолютную истину, но на основе собственных поделок для дома и автоматизации "больших" зданий.
ЗЫ: Любые рацпредложения выслушаю с удовольствием. Хоть и почти "забил" на esp8266 в угоду STM32 для домашних поделок, но идеология никуда не девается ))
Вроде бы и "+". Вроде бы и популяризация, но несколько бросившихся в глаза ляпов - тянут на жирный "-". Так что ограничусь замечаниями. Каюсь, половину пролистал невнимательно, ибо см. замечания :).
За WB (ради него и затевалось же, правда?) - спасибо. В свете нынешней доступности контроллеров, всё более актуально.
1. Указание типа значений uint16_t как бы намекает на 16 бит или 2 байта (а не 4) - из записи EEPROM (то, как оно хранится внутри - другая история)
2. У ESP8266 нет EEPROM. Она эмулируется через FLASH
3. Аналогично с файловой системой - она тоже живёт во FLASH. И "насиловать" её ещё и лишней записью всякого JSON - ну, такое себе... Кстати, а зачем вообще хранить локальные настройки в человеко-читаемом виде? Их же никто, кроме контроллера не видит
5. Если сенсор измеряет раз в секунду, зачем дёргать его раз в 10мс? Мало того, что лишний разогрев датчика, так ещё и будем мешать работать тому же modbus-у. На 9600-то, может и успеет, а быстрее - возможны сюрпризы
Базу хранит с тегами и тех. инфой, превью хранит отдельными файлами 180х180 и 360х360 (хз, можно ли отключить часть). Остальное "как есть" в файлах. Теги умеет вписывать в файлы, по-умолчанию - отключено.
Несколько чудны́м образом и небыстро (через рескан файлов) - видимо, хранит хеш файла и повторное добавление вызывает поиск в базе "потерянных" и перепривязку найденного на старое место в дереве.
Что будет, если были изменены тэги "извне" не скажу, но мелькало где-то, что сравнивается только содержимое картинки.
Это традиционный вопрос хранения бэкапов. Хоть где-то хранить надо обязательно.
Там другой нюанс:
сменили диск/ОС/ - слетели привязки по путям. Не все программы могут "подхватить" файловую структуру на новом месте и привязать её к БД
сменили версию программы - старая база перестала читаться, а старой версии софте - не предусмотрено :)
но есть и плюс у БД - гораздо быстрее искать/фильтровать по параметрам (у меня это как дата, так и до десятка тегов на особо хитрые фото)
Резюмируя - хранить в осмысленном дереве по датам/событиям/пленкам/и т.п. Теги писать в файлы (непосредственно или .xmp рядом). Использовать софт, читающий это дело в БД, позволяющий искать по тегам и записывать их обратно. Делать бэкапы БД/превью хоть куда - облако, другой диск, ...
Я, например, раз пять "терял" базу при переездах между дисками и дистрибутивами :)
@PereslavlFoto В Shotwell 0.29.3+ (вновь) заявляют распознавание и детекцию лиц, но что-то они лет пять уже это "заявляют". Всё не соберусь поставить бету и попробовать, если "взлетит" на Intel - там OpenCV определенной версии надо...
В порядке предположения: потому что дебилы-монтажники прикрутили алюминиевую гильзу к медной шине (практика показывает - "они всегда так делают" - насмотрелся...) и гальванопара так или иначе "доела" соединение, а осталось только то, что через стальную шайбу и не менее стальной болт, который ещё не "доели" :))
в этом и прикол - в дополнителных настройках "receive-only" и оно, "кагбэ™" не удаляется. проверено. но бывают какие-то косяки, потому плюнул на "автоматику" и вернулся к rsync-у (линукс/андроид)...
UPD: Залез посмотреть - это _в получателе_ в "Advanced/Folder/options/ -- ignore delete" называется
НО! Аккуратно с ним надо (повторюсь, кому-то отвечал уже...) - он может "внезапно" потереть половину файлов на устройстве, которое предполагалось "архивом" - по-умолчанию "send-only / receive-only" отключено.
ЗЫ: пользовал для синхрона фоток с телефона и отказался именно из-за вот таких внезапных потерь, когда удаляешь на телефоне... теперь rsync с опцией "не трогать существующие" и нулевой размер файла для "удаляемых" в архиве...
А главное - найти что у них, что на "внутреннем" сайте почти ничего невозможно... И такой беспредел творится не один год :(( "Поиск - обновление софта Х" - нет таких записей... "Система скачивания - сохраненная ссылка Х" - ага, вот оно... И уже там можно поискать подробней... из пары-тройки сотен двоящихся предложений... Не говоря о том, что сайт раз в квартал-полгода переделывают и 2/3 сохраненных ссылок начинают вести в никуда...
Да дохнут они. Причем рандомно от 3 месяцев до года из одной купленной партии… Пару лет назад менял штук 6 за год с пары одноламповых светильников… Причем, чаще начинает просто моргать и бесить, чем совсем сдыхает (лежит пара таких трупов — лень было ехать в леруа)…
(upd) Расковырял только что такой труп — там совсем другая схема. Так что ещё и лотерея с тем, что там внутри окажется — учитывайте дату выпуска и партию.
Чёт как-то заморочено выглядит… Надо будет вчитаться после праздников
Временно заставил работать google charts + google spreadsheet, но это онлайн и непонятно, что будет после второй сотни запросов :)
Таки вернее предложение den_rad — сгородить на qrcode (возможно плюс PIL для добавления текстовой расшифровки, если он сам не умеет) Заодно питон вспомню, пока забывать не начал %)
А вот, может, кто подскажет оффлайн генератор qr кодов для изготовления наклеек.
В идеале — принимающий таблицу LibreOffice или какой-нить текстовый файл и выдающий лист с как-то оформленными кодами (типа QR + текст). Linux/windows… не 1С, не MSOffice :)
… а то уже начинаю коситься на скрипты inkscape, но не хотелось бы
воот... спасибо, возьму за основу, коль решусь делать на "рассыпухе".
Это то, на тему чего я уже давно и неспешно думаю, но не хочу :) Во-первых, у меня "плоховато" с операционниками - в детстве не поигрался, а сейчас чуть не с нуля разбираюсь, но почти не использую (потому и не освоил до сих пор). Даже понять, как правило, могу. И что-то подобное нарисовать, всего с парой-тройкой ошибок (Proteus / LTSpice спасают).
Собс-но не хочу именно по причине аналоговой части на "рассыпухи". Да - понятно, да - деталей немного. Но возня с наладкой пока отталкивает, ибо "для себя и совсем не срочно", а работа не ждёт...
ЗЫ: Вроде, видел схему на какой-то другой INA под это дело, но давно и не нашёл. Наверно потому и периодически ищу готовое, вместо "сесть и нарисовать самому" :)
Явной схемки нет. Хочу мониторить 12В батарею на (например) охранно-пожарном БП. Ну или чем-то от meanwell. Они разные и сразу сказать, что там как сделано, невозможно. И доп. условие - одавать это дело по "цифре" в одноплатник или что-то похожее с минимальным доп. обвесом и размерами.
Судя по их схемам, там "+" АКБ общий с выходом, а "-" бывает по-разному, но что-то типа полевика обычно там есть (например DRC-40A - схема заряда и котроля в "-" батареи https://static.chipdip.ru/lib/335/DOC011335221.pdf).
Красиво. Подробно. Не хватает дополнительного акцента, что это работает только в системах, где "-" общий...
А вот, кто бы мне подсказал подобный чип для мониторинга без общего минуса. Типичное - бесперебойник 12В, у которого "минус" батареи коммутируется полевиком и не является общим с цепью питания. Пока идея с питанием INA от той же АКБ с гальванической развязкой, но уж слишком хлопотно для домашних поделок, попроще бы чего
Если есть РУТ, можно поставить программный ограничитель заряда - год "несвежий" Mi-5 работает и не пухнет. Ну или народ городит внешнюю схему отключения: берётся "киоск", умеющий отдавать наружу процент заряда батареи (в моём случае был HabPanel, вроде, и WallPanel) - по MQTT получаем заряд и через внешнее реле включаем/отключаем зарядку в диапазоне 30-70 примерно.
Согласен. Но это уже детали реализации, навроде кольцевого буфера в EEPROM для экономии ресурса ячеек.
Тут или версию конфига+совместимость в парсинге оного (множим-копим старый код), или делить конфиг на части - сеть отдельно, остальное отдельно, или просто плевать и конфигурить заново после перепрошивки - зависит от задач.
Мои датчики на ESP живут с SPIFFS, на которой веб страницы, бинарный конфиг ESP и отдельно датчиков - но там всё равно веб+mqtt+wifi+файловый менеджер - оправдано. И да, при прошивке есс-но настройки не теряются (а давно ли я менял структуру конфига? лет 5 назад кое-где...)
Дык, и у меня микроконтроллерная часть в качестве хобби. Хоть и с самопальными платами и прошивками. Но, как-то, "для себя" требуются оба направления, а они слегка разные по подходу в реализации.
Узнал давно. Фирма заинтересовалась где-то весной, когда стало понятно, что Шнайдер - таки всё, а делать что-то надо %) С тех пор и стенд сделали, и (думали что) спалили модуль-другой, и проекты начинаем считать потихоньку. Весна придёт - поглядим.
:) так в это и главный плюс статей - вдруг, кто ответит, что всё ващще фигня и надо по-другому. А у людей - мысль!©
Тут вопрос, в какую тему копать - автоматика в терминах "контроллеров" - WB в данном случае (полноценный linux), или МИКРО-контроллеров - две большие разницы. Хотя и к "большим" контроллерам, точнее софту, есть те же претензии...
Что не (на самом деле - тоже "да") надо экономить в "большом" контроллере через его конфигуратор, требует вдумчивого чтения мануалов на "железо" - в т.ч. чипы, - на "полевых" устройствах.
Для данной статьи хватило бы микроконтроллера из "базовых" ардуин - ATmega168/238 (Pro mini etc). Esp8266 избыточен совсем (wifi же тут не используется, а в ATmega168, и правда, есть настоящий EEPROM). Ну, пришлось бы рассказать про FreeModbus и её настройку под ардуину, но это отдельная увлекательная тема...
Пробую ответить.
Про хранение В ДАННОМ СЛУЧАЕ (!) - нет EEPROM, FRAM, etc... ЕМНИП, EEPROM в esp8266 эмулировалась через 2 страницы FLASH с контролем корректности предыдущего сохранения, но могу ошибаться. И размер страницы, как бы не 1024 байт. Т.е. минимум 2048 байт "отъедается" на хранение 3-5 переменных. Про FS вообще молчу :) как хранилище web страниц для WiFi с возможностью закачки новых извне - да, а хранить настройки - бешеный overkill (там хранить-то 2-5-10 параметров), ну да - место-то пока есть...
делаем структуру с тем, что храним (для текстовых данных - фиксированная длина строки) чтобы не мудрить с логикой считывания
инициализируем её в коде значениями по-умолчанию
сохраняем её в, пусть, "EEPROM" (в данном случае - всё равно - FLASH), только если что-то поменялось. И, возможно, с задержкой в 5-60сек после последнего изменения - если юзер что-то меняет много где (но это уже изыски). Сохранение через write(... sizeof(struct config_struct)). Не знаю, может и .put подойдёт - ардуину в чистом виде уже лет 10 не пользовал, не помню. Максимум - PlatformIO + почти-С...
при старте также читаем блоком всю структуру (есс-но не напрямую в текущий конфиг). По-хорошему, в конце структуры хранить какой-то вид CRC - если не совпало, игнорим прочитанное
при старте в SafeMode - НЕ читаем конфиг и пользуемся значениями по-умолчанию
Если требуется хранить показания счётчиков - отдельная тема с циклическим буфером или внешней FRAM памятью - компромисс между умиранием памяти, ценой, наличием доп. модулей FRAM и частотой сохранения данных
Про опрос датчиков уже ответил @Winnie_The_Pooh , но добавлю - даже в мануалах к упоминаемым BMP180/280/DS18B20/etc указано, что частый опрос приводит к разогреву датчика вплоть до 1-2°С. Ибо опрос (тут, обычно...) запускает вычисление. Тем более с готовыми ардуиновскими библиотеками, которые не спрашивают по-готовности, а, как правило, принудительно опрашивают датчик и ждут ответа (кстати, ещё одно место косяка с модбасом - пока I²C не ответит - будет "висеть", учитывая как подвисает I²C именно в esp8266, это тоже может стать сюрпризом). Правильный подход:
а) спрашивать не чаще, чем это действительно надо
б) можно спрашивать чаще и хранить локально среднее, но без фанатизма
в) максимально использовать данные на датчик - настраивать частоту измерения в самом датчике и не спрашивать его чаще, чем это время
г) время измерения выбирать максимальное в пределах задачи. Например, температура помещения вряд ли нужна чаще раза в 1-5-10 минут - так и не надо его дёргать чаще 0.5-2.5-5 минут с усреднением. Или даже в 1-5-10 - в зависимости от задачи..
д) в модбас отдавать сохраненное значение, не привязывая чтение датчика к запросу от модбас-а (наверно, эта библиотека так и делает, не пользовался - не знаю)
Как -то так. Без претензий на абсолютную истину, но на основе собственных поделок для дома и автоматизации "больших" зданий.
ЗЫ: Любые рацпредложения выслушаю с удовольствием. Хоть и почти "забил" на esp8266 в угоду STM32 для домашних поделок, но идеология никуда не девается ))
Вроде бы и "+". Вроде бы и популяризация, но несколько бросившихся в глаза ляпов - тянут на жирный "-". Так что ограничусь замечаниями. Каюсь, половину пролистал невнимательно, ибо см. замечания :).
За WB (ради него и затевалось же, правда?) - спасибо. В свете нынешней доступности контроллеров, всё более актуально.
1. Указание типа значений uint16_t как бы намекает на 16 бит или 2 байта (а не 4) - из записи EEPROM (то, как оно хранится внутри - другая история)
2. У ESP8266 нет EEPROM. Она эмулируется через FLASH
3. Аналогично с файловой системой - она тоже живёт во FLASH. И "насиловать" её ещё и лишней записью всякого JSON - ну, такое себе... Кстати, а зачем вообще хранить локальные настройки в человеко-читаемом виде? Их же никто, кроме контроллера не видит
4. Не помню, в какой части ардуины, но где-то там есть встроенная функция yield(), отдающая остатки времени внутреннему планировщику. Переопределять её как-то неаккуратненько ©. Мало ли, что потребуется
5. Если сенсор измеряет раз в секунду, зачем дёргать его раз в 10мс? Мало того, что лишний разогрев датчика, так ещё и будем мешать работать тому же modbus-у. На 9600-то, может и успеет, а быстрее - возможны сюрпризы
Прям опять про shotwell :)
Базу хранит с тегами и тех. инфой, превью хранит отдельными файлами 180х180 и 360х360 (хз, можно ли отключить часть). Остальное "как есть" в файлах. Теги умеет вписывать в файлы, по-умолчанию - отключено.
Из того, что сейчас под рукой:
18050 фото и 46 видео на 186Гб
4 копии БД по 10-12Мб
2.1Гб превьюшек
Ну, упомянутый shotwell это умеет.
Несколько чудны́м образом и небыстро (через рескан файлов) - видимо, хранит хеш файла и повторное добавление вызывает поиск в базе "потерянных" и перепривязку найденного на старое место в дереве.
Что будет, если были изменены тэги "извне" не скажу, но мелькало где-то, что сравнивается только содержимое картинки.
Это традиционный вопрос хранения бэкапов. Хоть где-то хранить надо обязательно.
Там другой нюанс:
сменили диск/ОС/ - слетели привязки по путям. Не все программы могут "подхватить" файловую структуру на новом месте и привязать её к БД
сменили версию программы - старая база перестала читаться, а старой версии софте - не предусмотрено :)
но есть и плюс у БД - гораздо быстрее искать/фильтровать по параметрам (у меня это как дата, так и до десятка тегов на особо хитрые фото)
Резюмируя - хранить в осмысленном дереве по датам/событиям/пленкам/и т.п. Теги писать в файлы (непосредственно или .xmp рядом). Использовать софт, читающий это дело в БД, позволяющий искать по тегам и записывать их обратно. Делать бэкапы БД/превью хоть куда - облако, другой диск, ...
Я, например, раз пять "терял" базу при переездах между дисками и дистрибутивами :)
@PereslavlFoto В Shotwell 0.29.3+ (вновь) заявляют распознавание и детекцию лиц, но что-то они лет пять уже это "заявляют". Всё не соберусь поставить бету и попробовать, если "взлетит" на Intel - там OpenCV определенной версии надо...
В порядке предположения: потому что дебилы-монтажники прикрутили алюминиевую гильзу к медной шине (практика показывает - "они всегда так делают" - насмотрелся...) и гальванопара так или иначе "доела" соединение, а осталось только то, что через стальную шайбу и не менее стальной болт, который ещё не "доели" :))
нет, не удалятся.
в этом и прикол - в дополнителных настройках "receive-only" и оно, "кагбэ™" не удаляется. проверено. но бывают какие-то косяки, потому плюнул на "автоматику" и вернулся к rsync-у (линукс/андроид)...
UPD: Залез посмотреть - это _в получателе_ в "Advanced/Folder/options/ -- ignore delete" называется
У syncthing есть "send-only" опция...
НО! Аккуратно с ним надо (повторюсь, кому-то отвечал уже...) - он может "внезапно" потереть половину файлов на устройстве, которое предполагалось "архивом" - по-умолчанию "send-only / receive-only" отключено.
ЗЫ: пользовал для синхрона фоток с телефона и отказался именно из-за вот таких внезапных потерь, когда удаляешь на телефоне... теперь rsync с опцией "не трогать существующие" и нулевой размер файла для "удаляемых" в архиве...
А главное - найти что у них, что на "внутреннем" сайте почти ничего невозможно... И такой беспредел творится не один год :(( "Поиск - обновление софта Х" - нет таких записей... "Система скачивания - сохраненная ссылка Х" - ага, вот оно... И уже там можно поискать подробней... из пары-тройки сотен двоящихся предложений... Не говоря о том, что сайт раз в квартал-полгода переделывают и 2/3 сохраненных ссылок начинают вести в никуда...
(upd) Расковырял только что такой труп — там совсем другая схема. Так что ещё и лотерея с тем, что там внутри окажется — учитывайте дату выпуска и партию.
Временно заставил работать google charts + google spreadsheet, но это онлайн и непонятно, что будет после второй сотни запросов :)
Таки вернее предложение den_rad — сгородить на qrcode (возможно плюс PIL для добавления текстовой расшифровки, если он сам не умеет) Заодно питон вспомню, пока забывать не начал %)
В идеале — принимающий таблицу LibreOffice или какой-нить текстовый файл и выдающий лист с как-то оформленными кодами (типа QR + текст). Linux/windows… не 1С, не MSOffice :)
… а то уже начинаю коситься на скрипты inkscape, но не хотелось бы