Сообщений в теме: 79

[Карен]

Логи

С интерфейсом калибровки завершили, теперь будем прикручивать логи. Для чего нам логи? Во-первых просто чтоб было. Во-вторых мониторинг - оно всегда полезно, посмотреть как меняется pH в аквариуме в течение суток, как реагирует на дозирование, проветривание комнаты и всякое такое. 

 

Для хранения логов у нас на плате стоит отдельный чип EEPROM 64 килобайт (=65536 байт). Прикинем какой длины лог туда влезет. Для хранения величин pH с точностью до сотых (скажем от pH = 0.00 до 14.00) требуется 2 байта. До тысячных - тоже два байта. Получается, что в чип памяти влезет 65536 / 2 = 32768 измерений pH.  

 

Но вообще-то просто просто писать данные в лог смысла нет, нужна привязка ко времени. Здесь в голову приходят два решения:

 

1) Записываем время старта логгирования и дальше пишем, скажем, с частотой 1 измерение в минуту. А дальше, программа рисующая график, будет знать, что измерение номер 60  - час прошел, номер 70 - час и 10 минут... Оно бы все хорошо, но где гарантии, что не будет пропусков измерений (например отключали прибор на время, процессор перезагрузился не вовремя - хотя такого с этими процессорами не бывает, но все же). Не нравится мне этот метод.

 

2) Для каждого измерения параллельно записываем время (и дату) измерения. Плюсы - правильный график можно будет нарисовать даже если были пропуски в измерениях и даже если измерения были через разные промежутки времени. Минусы - требуется лишняя память. Во сколько байт можно утрамбовать год+месяц+число+час+минуты? Вообще-то в шесть. Многовато. Тогда делаем такой финт - пишем не текущую дату, а время в минутах прошедшее с некоей стартовой точки, дата которой запоминается. Тогда все влезает в два байта.  В итоге в наш чип влезет 32768 / 2 = 16384 измерений pH. Если делать 1 измерение в минуту, то хватит на 11 с лишним дней непрерывной записи. Нам оно выше крыши.

 

Итак, имеем возможность раз в минуту непрерывно писать в лог в течение 11 дней.

 

А что делать, если логгер работает дольше (включили и не выключаем)? Если дольше, то будем перезаписывать самые старые данные - в контроллере всегда будут данные за последние 11 дней (а более старое, если надо, автоматом скидывается на комп и плюсуется к предыдущим данным). 

А как программа узнает по цепочке данных где у нас старые, а где новые данные? Маркируем старшим битом в логе времени (у меня сейчас нет цели сделать смысл сказанного понятным - я просто показываю некоторую нетривиальность и увлекательность процесса). Дальше по смене бита находим границу между старыми и новыми данными. А как искать эту смену бита в 16 тысячах измерений в общем-то не быстром чипе? Перебором упаримся, поэтому реализуем алгоритм бинарного поиска, скорость которого мало зависит от размера массива...

 

Короче - это все не сложно и уже реализовано. Осталось только прикрутить к интерфейсу (пока не сделал) чтобы оно было прозрачно для пользователя, без всего того мудрежа, о котором писал выше. Но для отладки, для собственных нужд, чтоб не тупить если будут ошибки в моем коде, написал инструмент для просмотра дампа памяти чипа, чтоб глазами видеть правильно ли туда все что надо пишется, вот на это весь день и угрохал. Выглядит он так, в окончательной публичной версии программы наверное уберу, чтоб не смущать простых пользователей.

 

[Дмитрий57]

Логи

С интерфейсом калибровки завершили, теперь будем прикручивать логи. Для чего нам логи? Во-первых просто чтоб было. Во-вторых мониторинг - оно всегда полезно, посмотреть как меняется pH в аквариуме в течение суток, как реагирует на дозирование, проветривание комнаты и всякое такое. 

 

Для хранения логов у нас на плате стоит отдельный чип EEPROM 64 килобайт (=65536 байт). Прикинем какой длины лог туда влезет. Для хранения величин pH с точностью до сотых (скажем от pH = 0.00 до 14.00) требуется 2 байта. До тысячных - тоже два байта. Получается, что в чип памяти влезет 65536 / 2 = 32768 измерений pH.  

 

Но вообще-то просто просто писать данные в лог смысла нет, нужна привязка ко времени. Здесь в голову приходят два решения:

 

1) Записываем время старта логгирования и дальше пишем, скажем, с частотой 1 измерение в минуту. А дальше, программа рисующая график, будет знать, что измерение номер 60  - час прошел, номер 70 - час и 10 минут... Оно бы все хорошо, но где гарантии, что не будет пропусков измерений (например отключали прибор на время, процессор перезагрузился не вовремя - хотя такого с этими процессорами не бывает, но все же). Не нравится мне этот метод.

 

2) Для каждого измерения параллельно записываем время (и дату) измерения. Плюсы - правильный график можно будет нарисовать даже если были пропуски в измерениях и даже если измерения были через разные промежутки времени. Минусы - требуется лишняя память. Во сколько байт можно утрамбовать год+месяц+число+час+минуты? Вообще-то в шесть. Многовато. Тогда делаем такой финт - пишем не текущую дату, а время в минутах прошедшее с некоей стартовой точки, дата которой запоминается. Тогда все влезает в два байта.  В итоге в наш чип влезет 32768 / 2 = 16384 измерений pH. Если делать 1 измерение в минуту, то хватит на 11 с лишним дней непрерывной записи. Нам оно выше крыши.

 

Итак, имеем возможность раз в минуту непрерывно писать в лог в течение 11 дней.

 

А что делать, если логгер работает дольше (включили и не выключаем)? Если дольше, то будем перезаписывать самые старые данные - в контроллере всегда будут данные за последние 11 дней (а более старое, если надо, автоматом скидывается на комп и плюсуется к предыдущим данным). 

А как программа узнает по цепочке данных где у нас старые, а где новые данные? Маркируем старшим битом в логе времени (у меня сейчас нет цели сделать смысл сказанного понятным - я просто показываю некоторую нетривиальность и увлекательность процесса). Дальше по смене бита находим границу между старыми и новыми данными. А как искать эту смену бита в 16 тысячах измерений в общем-то не быстром чипе? Перебором упаримся, поэтому реализуем алгоритм бинарного поиска, скорость которого мало зависит от размера массива...

 

Короче - это все не сложно и уже реализовано. Осталось только прикрутить к интерфейсу (пока не сделал) чтобы оно было прозрачно для пользователя, без всего того мудрежа, о котором писал выше. Но для отладки, для собственных нужд, чтоб не тупить если будут ошибки в моем коде, написал инструмент для просмотра дампа памяти чипа, чтоб глазами видеть правильно ли туда все что надо пишется, вот на это весь день и угрохал. Выглядит он так, в окончательной публичной версии программы наверное уберу, чтоб не смущать простых пользователей.

Screenshot_1.jpg

А sqlLite + sd карта мк не тянет?

[jusupoff]

Если подумать, то размер лога на еепром в 64кБ можно увеличить почти в два раза с учетом вашего ТЗ.
Метку времени писать не для каждого измерения, а чуть иначе:
Измерили, записали в память рН (два байта), а следом за ним время. Можно позволить себе записать реальное - все шесть байт. Если следующее измерение прошло через минуту, то поверх старой метки пишем рН, а новую метку сдвигаем вправо на два байта. Таким образом считам, что все данные до метки были правильными и шли ровно через одну минуту.
Если был перерыв в записи (несовпадение записанной метки и реальной) - старую метку времени не стираем, а следом за ней пишем новое значение рН и новую метку (6 байт).
В итоге в еепром будет практически только запись значений рН по два байта и несколько меток времени.
Время можно идентифицировать, например, старшими битами.
На компе этот массив разобрать будет не сложно.

[aquanavt]

Если подумать, то размер лога на еепром в 64кБ можно увеличить почти в два раза с учетом вашего ТЗ.
Метку времени писать не для каждого измерения, а чуть иначе:
Измерили, записали в память рН (два байта), а следом за ним время. Можно позволить себе записать реальное - все шесть байт. Если следующее измерение прошло через минуту, то поверх старой метки пишем рН, а новую метку сдвигаем вправо на два байта. Таким образом считам, что все данные до метки были правильными и шли ровно через одну минуту.
Если был перерыв в записи (несовпадение записанной метки и реальной) - старую метку времени не стираем, а следом за ней пишем новое значение рН и новую метку (6 байт).
В итоге в еепром будет практически только запись значений рН по два байта и несколько меток времени.
Время можно идентифицировать, например, старшими битами.
На компе этот массив разобрать будет не сложно.

Кроме того, если достаточно хранить сотые (я так понял, из-за неточности калибровочных растворов особого смысла в тысячных и нет?)  и нужно упаковать еще сильнее, то можно и для значения PH писать только дробную часть - и один бит оставить на маркер смены целого значения PH (например 8.00 -> 7.99). Если еще сильнее заморочиться, то 7 битов даст еще и запас для защиты от дергатни PH  - типа 8.00 -> 7.99 -> 8.00 -> 7.99.

То есть при точности до сотых можно метки измерений PH уложить в 1 байт и таким образом будет довольно много дней в истории в логах.

[jusupoff]

Циклическую запись можно организовать как вы предложили, можно в еепром писать аздрес последней записи, чтобы не бегать поиском по всем 64 килобайтам.
Не знаю, есть ли в этой АТмега свой еепром, если да - можно его использовать. Или выделить в внешней 256-512 байт под запись последнего адреса. И писать тоже циклически, так как запись будет частая, а ячейки памяти еепром имеют конечное число циклов стирания-записи.

[jusupoff]

Если еще подумать... С учетом того, что рН не скачет, как коза по горам, а меняется (обычно) плавно, то вместо записи нового значения рН - записывать дельту (изменение) от предыдущего значения. Тут может хватит 5-6 бит. А старшие биты использовать для идентификации этих данных. Если новое значение больше дельта, то пишем полностью значение рН, а потом опять дельту.

[aquanavt]

А sqlLite + sd карта мк не тянет?

На таких чипах очень мало памяти (оперативной) . То есть классический SQLite вряд ли вообще удастся запустить. Но можно собрать имитацию, которая с самыми минимальными опциями будет работать на таком малом количестве памяти. При этом надо понимать, что как таковых самых интересных штук типа SQL, индексов и т.д. в принципе не будет (опять же в силу минимального объема памяти).

 

Таким образом:
+ : Удобный интерфейс для логгирования - но через C API вместо SQL. Практически неограниченный размер логов. Можно в любой среде полученный файл открыть и работать с ним через SQL.

- : Сложнее становится плата. Количество доступной памяти сильно уменьшится после загрузки библиотеки -  тут еще неясно, сколько ее потребуется на обслуживание остальных функций девайса. Кастомный сериализатор / десериализатор в/из формат(а), предложенный выше, можно написать за несколько часов вместе с тестами - т.е. временная экономия несущественна.

А на клиенте (приложение для MS Windows) возможно имеет смысл в SQLite просто для удобства хранения, выборки и нормализации данных (тут субъективно)

[aquanavt]

Если еще подумать... С учетом того, что рН не скачет, как коза по горам, а меняется (обычно) плавно, то вместо записи нового значения рН - записывать дельту (изменение) от предыдущего значения. Тут может хватит 5-6 бит. А старшие биты использовать для идентификации этих данных. Если новое значение больше дельта, то пишем полностью значение рН, а потом опять дельту.

Таким образом в целом протокол команд можно сделать таким:

1. вариант

1 бит: тип команды (0: запись времени / 1: запись значения PH)
2 бит: тип данных. Тут, похоже, только для PH это применимо: 0: запись дельты, 1: запись полного значения. Хотя, если нужно, можно и поддержку смены интервала между тестами сделать. тогда 0: запись временной метки, 1: запись интервала в секундах между измерениями / логами.

 

далее в зависимости от 1-2 бита вычисляется длина фрейма, это будет либо 1 байт для записи дельты PH, 2 байта для записи PH (11 бит вполне хватит для записи сотых), 1-2 байта для записи интервала логгирования, ну и несколько байт для записи точного времени (этих команд будет очень мало или вовсе не будет, можно не заморачиваться и не экономить)

 

далее вычитывается фрейм нужной длины, парсится, ну вот и все.

 

таким образом будет очень простой, легко верифицируемый парсер + довольно высокая эффективность хранения данных, приближающаяся к 1 байту на измерение.


2 вариант

тут мы принимаем во внимание то, что PH меняется не сильно и подстраиваем дельту в случае необходимости.
все примерно аналогично варианту 1, только для заголовка 00 (запись дельты) мы пишем в 3 битах длину дельты (1-7 бит без учета знака) и в оставшихся 3/11 битах - количество блоков для хранения записи (может быть кол-во байт, или мультипликатор, и т.д.). ну а далее мы пишем последовательность этих дельт (они все одинаковой длины), пока не достигнем конца блока. далее пишется следующий блок, и т.д. В случае, если приходит новая команда, до конца блока забиваем все нулями, а потом создаем новый блок.

тут смысл в том, что:
1) при частых измерениях малой дельты скажем 3 бита + знак будет достаточно (это +/- 0.07), чтобы кодировать последовательность. Если программа видит, что дельты не хватает - создается новый блок с большей дельтой и все то же самое. Если дельта слишком большая (например к концу блока не менее N измерений подряд не меняется старший бит дельты - тогда новый блок создается с меньшей дельтой)

2) плотность упаковки данных возрастет почти в 2 раза по сравнению с вариантом 1, т.е. грубо говоря в 8 байт данных можно будет упаковать 14 дельт. Что как бы и неплохо.

[jusupoff]

aquanavt,
Этак мы щас поднимем на АТмега нормальное сжатие в архив (это вполне реально с учетом того, что тут запись в еепром раз в минуту).

Эх, АТмега... Чего только не делал на ней для себя. И на асме тоже, когда надо за кажым тактом следить. Был проект ЭКГ с суточной записью на SD-карту (если не поднимать на карте файловую систему, а использовать прямую запись, то там любой меги хватит - десяток команд на иницилизацию, а дальше как с еепром).
Потом пересел на STM32, на Мегу не вернусь.

[jusupoff]

В общем, для лога с вполне понятными исходными данными, при сохранении рН до сотых, с некотрыми извращениями (без алгоритмов архивации), вполне можно уложиться в 1 байт на одно сохранение. Да, потерять 2-5% памяти на всякие метки, в том числе метки времени. Но получим 60к+ измерений в логе. По сравнению с 16384...

[Карен]

Спасибо за комментарии, посмотрю, если и буду ли что менять, то позже, пока оставлю как есть так как 11 дней записи за глаза.

Кроме того, не хочется привязываться к конкретному типу данных (только pH), так как те же логи на том же самом контроллере и на той же прошивке будут использоваться и для записи других данных (освещенность для расчета интеграла освещенности (DLI) за день, температуры и может что еще, то есть любые значения int 16 bit). Вообще, я не сторонник "комбайнов", которые умеют делать много всего разного, но, сказать честно, поднадоел зоопарк прошивок, хочется одну универсальную, переключаемую на разные опции.

Данные по времени при этом будут отъедать меньшую часть EEPROM. К примеру, контроллер мониторящий температуры у меня на участке (там вообще Mega8 стоит, совсем мелкая), пишет в эту же EEPROM кольцевые логи с 15 датчиков, с одним рядом данных по времени (то есть он занимает 1/16 часть EEPROM). Пишет в непрерывном режиме уже полтора года, периодически автоматом скидывая на комп. Температуры за любую дату и время (интервал 10 минут) за это время в наличии. Сказать честно, для pH я не представляю для чего оно надо, но возможность пусть будет.

 

Циклическую запись можно организовать как вы предложили, можно в еепром писать аздрес последней записи, чтобы не бегать поиском по всем 64 килобайтам.

Этот вариант изначально и рассматривался, но мы очень быстро "протрем дырку" постоянной записью метки в переменную по одному и тому же адресу в EEPROM. Что для процессора, что для чипа заявлено 100 тыс операций записи в ячейку. Если писать каждую минуту, то это всего 2 месяца и приехали... Не годится.

 

Посмотрел сколько по времени занимает бинарный поиск в EEPROM, получилось так:

 

Одно чтение (2 байта int) по рандомному адресу в EEPROM ~ 360 мкс. 

 

Скорость бинарного поиска  = log(n), то есть для лога длинной в половину EEPROM значение будет найдено за 15 тактов. Смотрим анализатором и видим что это действительно так, весь поиск занимает 15 тактов и 6 ms.

И дальше запись даты и данных по разным адресам с ожиданием готовности EEPROM после записи - 4.6 мс. То есть, пробежка поиском по EEPROM занимает практически столько же времени, сколько запись 4-х байт по двум разным адресам. На мой взгляд более чем приемлемо. Особенно учитывая, что чтение/передача данных не критичны к прерываниям (то есть если в процессе произойдет прерывание, это ничего не попортит).

 

Кстати, рассматривая первый скриншот вижу что чтение у меня сделано не оптимально, адрес второго байта посылать в EEPROM  было не обязательно, надо было просто продолжить чтение и время сократится на четверть. То есть на весь поиск по EEPROM уходит столько же времени, сколько на запись 4-х байт по двум адресам, не критично вообще.

 

Всю эту полировку кода я думал делать в конце, но вы сподвигли глянуть что происходит сейчас. 

[Карен]

Ну что, логи пишутся, все нормально. При желании скидываются на комп в виде текстового файла с понятным содержимым и автоматом цепляются к предыдущим записям:

 

Рисовать красивости в программе - не мой конек. Я до сих пор не могу привыкнуть к популярным ныне "рыхлым" интерфейсам, где одна одна кнопка здесь, другая на другом конце экрана, а добраться до третьей надо пальцем пролистать - не мое. Все еще предпочитаю лаконичный спартанский вид. Главное окно программы целиком выглядит так:

 

По графику - у меня не было готовых библиотек или компонентов для рисования графика, поэтому сделал свою отрисовку. Все как положено - двигается мышкой, масштабируется колесиком и все такое. Наводим курсор, появляется вертикальная направляющая (желтая линия на скриншоте) и в появляющемся окошке показывается дата, время и pH в данной точке.  Но это так, технические моменты

 

Теперь, смотрим график pH в моем аквариуме.

 

И видим, что надо что-то делать - ночью падает гораздо сильнее, чем я думал и чем хотелось бы. При включении света растет почти по прямой. Надо будет подумать и решить что делать.

 

А по самому прибору - все просто великолепно и гораздо лучше, чем я надеялся, когда затевал всю эту байду с электроникой. Тут два важных момента.

 

Первое. Помнится тут на форуме были темы, где рассказывали что на выход электрода ставили конденсаторы для сглаживания наводок, фильтрация пиков и еще что-то в этом роде (плохо помню и искать не буду, но что-то такое было), наводки от помп и автодоливов с электрическими контактами... Автодолив у меня, кстати, управляется электродами, никаких наводок вообще ни от чего я не вижу. Абсолютно (!!!) гладкий график.

 

Второе. Здесь спрашивали, для чего нужно большое разрешение электроники и сверхнизкие шумы, если мы все равно не измерим точно (и если нам все равно не надо измерять точно). А вот для чего. Смотрим на графики ниже - увеличен масштаб того же графика, что и выше. Видим такие подъемы pH высотой от двух сотых до 15 тысячных pH. Отрисованы они очень качественно (и плавно), так что сразу ясно, что это не артефакт, а реальность. Это дозирование баллинга, точнее второго его раствора, соды (дозирование в сампе, а замер в дисплее). Точность цифр, как тут правильно говорили, не так важна. То есть, если прибор в этой точке показал 8.3, на деле там может быть чуть больше или меньше, это не так важно. Важно что его разрешающая способность и малошумность позволяет разглядеть небольшие изменения. А дальше уже дело техники, как использовать эту информацию. Мне, к примеру, надо будет пересмотреть расписание дозирования (ну и есть еще кое какие мысли по переменному дозированию соды с едким натром чтобы и кн четко держать и ph ночью не падал.

 

Дальше можно будет посмотреть насколько влияет скиммер, все эти заборы воздуха с улицы, насколько оправданы или нет. Главное что есть прибор, который все малейшие изменения будет ловить. И да, все это с совершенно отстойным pH электродом с али.

 

 

 

[vahegan]

И видим, что надо что-то делать - ночью падает гораздо сильнее, чем я думал и чем хотелось бы. При включении света растет почти по прямой. Надо будет подумать и решить что делать.

...

Видим такие подъемы pH высотой от двух сотых до 15 тысячных pH. Отрисованы они очень качественно (и плавно), так что сразу ясно, что это не артефакт, а реальность. Это дозирование баллинга, точнее второго его раствора, соды (дозирование в сампе, а замер в дисплее).

...

(ну и есть еще кое какие мысли по переменному дозированию соды с едким натром чтобы и кн четко держать и ph ночью не падал.

Карен, я наблюдал ровно тоже самое на GHL. рН сильно падал ночью, и потом рос с момента включения света. Тогда я перерегулировал дозатор, чтобы дозировал только ночью. Пару месяцев дозировал едкий натр и хлорид кальция, потом поменял, и стал дозировать суспензию гидроксида кальция (у меня в отдельной емкости 5% смесь гидроксида кальция с водой, поддерживается в суспензии маленькой помпой течения Джебао, дозирую прямо в аквариум из этой емкости. Туда же гидроксид магния добавляю, но от него раствор существенно гуще становится, хоть процент и маленький, если магний не добавлять, процент гидроксида кальция можно заметно увеличить). Дозирую неравномерно, подбирал индивидуальные дозы в разные часы так, чтобы минимизировать колебания рН. Тоже вижу зубцы на графике рН при дозировании гидроксида (у GHL чувствительность, конечно, намного меньше, чем у твоего мега-прибора, но гидроксид я дозирую прямо в аквариум возде помпы течения, и он, конечно, намного сильнее влияет на рН, чем сода). Содержание углекислого газа в комнате в районе 900-1000ppm., я посчитал, что выводить датчик на улицу особого смысла не имеет. Можно было поставить пенник на рециркуляцию, но я не захотел этого делать, так как считаю, что это уменьшило бы насыщение воды кислородом и понизило бы редокс. После того, как перешел на ночное дозирование щелочи, колебания рН в системе существенно уменьшились, среднее значение рН поднялось, кораллам это пришлось по душе.

[Карен]

А у меня наоборот было, основное дозирование перенесено под вечер,  потому что к вечеру было очень большое проседание КН (озаботился как-то и измерял каждый час). А на pH я тогда вообще не обращал внимания. То есть тут у нас (по крайней мере при большом потреблении баллинга) pH и КН идут в разные стороны и надо решать что важнее держать стабильным.

 

У меня сейчас такая мысль сделать отдельно раствор прокаленной соды (1) и отдельно NaOH (2) в таких концентрациях, чтобы они были эквивалентны по концентрации КН, то есть чтобы для поддержания КН было бы все равно что дозировать, первый или второй раствор. Ну то есть если для поддержания КН в сутки в норме дозируется 100 мл соды, то можно дозировать 100 мл NaOH или 50 мл одного и 50 другого и КН останется стабильным. А дальше контроллер в зависимости от pH  контроллер выбирает 

из какой емкости льем очередную дозу, из емкости с содой или с едким натром. Суммарный объем нам дает регулировку КН, а внутри этого объема имеем возможность регулировать pH.

 

Не уверен, что реализую, надо дополнительную помпу к дозатору прикрутить (очень уж лень), но посмотрим.

[DNK]

А дальше контроллер в зависимости от pH  контроллер выбирает

Очень интересная, и я уверен, полезная идея! Ещё бы повесить это всё на автоматизированный замерятель карбонатки - и было бы просто идеально!

[vahegan]

А у меня наоборот было, основное дозирование перенесено под вечер,  потому что к вечеру было очень большое проседание КН (озаботился как-то и измерял каждый час). А на pH я тогда вообще не обращал внимания. То есть тут у нас (по крайней мере при большом потреблении баллинга) pH и КН идут в разные стороны и надо решать что важнее держать стабильным.

 

У меня сейчас такая мысль сделать отдельно раствор прокаленной соды (1) и отдельно NaOH (2) в таких концентрациях, чтобы они были эквивалентны по концентрации КН, то есть чтобы для поддержания КН было бы все равно что дозировать, первый или второй раствор. Ну то есть если для поддержания КН в сутки в норме дозируется 100 мл соды, то можно дозировать 100 мл NaOH или 50 мл одного и 50 другого и КН останется стабильным. А дальше контроллер в зависимости от pH  контроллер выбирает 

из какой емкости льем очередную дозу, из емкости с содой или с едким натром. Суммарный объем нам дает регулировку КН, а внутри этого объема имеем возможность регулировать pH.

 

Не уверен, что реализую, надо дополнительную помпу к дозатору прикрутить (очень уж лень), но посмотрим.

 

Да, именно, у меня тоже самое, под вечер КН выедается и проседает, и я тоже подумывал, может быть имеет смысл использовать две разные добавки, одна из которых задирает рН, а вторая - нет. Но так и не сподобился попробовать.

[Дмитрий57]

Не уверен, что реализую, надо дополнительную помпу к дозатору прикрутить (очень уж лень), но посмотрим.

Можно же отдельное устройство сделать. Вообще в вашей концепции можно выделить планшет на винде для хаба управления устройствами по блютуз. Написать приложение в которое можно будет подключить дозатор, ph метр и тд, работать оно будет 24/7. Все коммуникации/взаимодействия сделать через хаб. Хаб опрашивает датчики и управляет на основе их помпами, мешалками и тд.

[Карен]

можно выделить планшет на винде для хаба управления устройствами по блютуз. Написать приложение в которое можно будет подключить дозатор, ph метр и тд, работать оно будет 24/7. Все коммуникации/взаимодействия сделать через хаб. Хаб опрашивает датчики и управляет на основе их помпами, мешалками и тд.

Я так начал было делеа в незапамятные времена, по радиоканалу тогда еще (не было ни блютусов ни вайфаев тогда, только ком порт и радиомодули). Не понравилось. Стараешься изолировать интерфейсы разных устройств, но все равно... короче оно слишком много усилий требовало. К тому же у меня дурная привычка забывать свой собственный код, и когда через пару лет надо бывало что-то добавить или убрать много времени уходило на то, чтобы разобраться как все оно у меня устроено. 

 

В итоге, очень давно уже, предпочитаю отдельные устройства не связанные ни хабами, ни чем другим. Планшета нет, у меня в доме три больших компа, один как сервер, один мой, другой жены, все это связано оптикой в 10 гигабитную сеть (описывал когда-то). Любой мой контроллер доступен с любого моего компа, но в одно приложение объединять как раз не моя концепция, для каждого устройства свой ярлычек на рабочем столе. Дозатор в большом аквариуме, дозатор в маленьком, микродозатор там и тут, мониторинг температур на участке - это все отдельные микроприложения, всякие термостаты для работы и колба-качалки и прочее, мне так проще с ними, чем монстриков под один интерфейс или на одну точку доступа привязывать.

[Карен]

Сижу репу чешу, стоит ли озаботиться и температурную компенсацию для pH электрода прикрутить? Если измерять только аквариумную воду, то отклонения в принципе очень небольшие (примерно 0.003 pH на градус цельсия при pH 8 и вдвое выше при pH 9). А вопрос, как оно всегда бывает, чем глубже копаешь, тем сложнее - там все не так просто. А с другой стороны, на плате (конечно же совершенно случайно) уже стоит разъем для термодатчика ... да и код для него в прошивке со старых времен есть... 

[DNK]

А с другой стороны, на плате (конечно же совершенно случайно) уже стоит разъем для термодатчика ... да и код для него в прошивке со старых времен есть... 

Думаю, что стоит. Да ещё и показания температуры вывести бы в лог, для полного счастья - там и байта для записи разницы с последним измерением за глаза - время-то уже пишется.