Category: компьютеры

Category was added automatically. Read all entries about "компьютеры".

Гидропоника

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

Здесь я опишу возмодности проекта и что именно я буду делать на первых шагах.



И так, у меня есть модули для различных датчиков качества воды, типа такого:

Еще есть дозаторы типа (или даже проще, один двигатель, без логики):

Ну и нужен свет.




Казалось бы что проще? Берем ардуино, качаем с сайта производителя https://atlas-scientific.com документацию по протоколу, реализуем его на ардуино (либо даже берем готовую библиотеку, наверное она где-то есть)
И все делаем сами, т.е. сценарии, информирование, удаленный доступ, сбор статистики и прочее, прочее, прочее.

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

Для работы конкретно с вышеописанными устройствами я могу использовать мини компьютер с шиной I2C, либо любой другой компьютер с большим набором UART (например USB-UART устройства).
На этом компьютере будет работать Java контроллер, он будет выполнять все взаимодействие с устройствами, в том числе и выполнять различные сценарии. Данные контроллер будет передавать серверу, а тот их отдавать клиентам и агрегировать.

Мне незачем знать API/протокол EZO устройств, они уже реализованы в проекте (кроме дозатора, об этом позже).

Точно также обстоят дела и с другими устройствами, например управление светом, датчик открытия двери и прочее.
Теоретически я их всех могу подключить к мини компьютеру через GPIO. Но что делать с обычными компьютерами?
Можно прикупить китайских железяк и подключить их по USB к примеру.

Но я пойду другим путем. Жаль, сейчас нет железок под рукой, фото будут позже.
Я возьму решение от Dipex. Мы разработали множество различных модулей.
Среди них есть модули специально для EZO модулей, есть USB шлюз с шиной DipexBus, есть мини компьютер с платой расширения DipexBus, есть специальный модуль для диммирования светодиодных ламп со стабилизацией по току. У нас много железяк, и некоторые специально разрабатывались для данной задачи.

Да, DipexBus проприетарная, но и ее протокол мне не нужен, все в проекте. Мне не за чем работать с DIpex модулями напрямую, так же как и с EZO модулями напрямую.

В итоге, я подключаю USB-DipexBus шлюз в любой компьютер или использую мини компьютер с платой расширения I2C-DipexBus. К нему подключаю EZO Dipex модули (в любом количестве) вставляю в них EZO модули и подключаю датчики. Также на шину подключаю Dipex LED диммер, DIpex IO модули и прочее.

Вот в качестве примера (только здесь другие модули и без корпуса):
photo_2020-05-20_18-30-39.jpg

Таким образом я объединяю DipexBus'ом все свои датчики и исполнительные устройства. Шина реализована на RS485 с поддержкой до 128 устройств.

По поводу дозатора. Мы не стали использовать дозаторы от atlas-scientific, у нас обычные дозаторы (двигатель на 18 вольт) которые управляются отдельным многоканальным модулем Dipex. Библиотеки дозатора atlas-scientific в проекте нет, но его можно добавить при желании.

Теперь программная часть.

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

Клиент - отображение показаний, управление устройствами и настройка сценариев и проекта.
Он может работать через сервер или напрямую (если клиент и контроллер находятся в локальной сети)

Т.е. регистрируюсь и описываю проект через клиента.
Здесь все достаточно просто. Dipex устройства умные, автоматически распознаются и прописываются в системе.

TODO: позже добавлю здесь видео.


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

Либо можем работать через сервер, и здесь варианты:
В данном случае нам нужен итоговый результат. Т.е. показания устройств, статистика, возможность изменять налету проект и сценарии.
Все это можно сделать через аналогичный API (также использует клиент).
Сервер поддерживает несколько подключений, через которые можно использовать API:
- внутренний бинарный протокол (можно предоставить Java библиотеку с его реализацией)
- голый TCP с JSON
- HTTP с JSON
- WebSocket c JSON
Документация будет доступна после написания.

Кроме этого, управлять и собирать показания можно через так называемые точки входа - Telegram, Алиса, email, HTTP и прочее. Методы работы специфичны для каждой точки доступа. Документация также будет доступна после написания.



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

Пока все, буду обновлять по необходимости.

P.S. По поводу пожеланий, я постараюсь найти время и выполнить ваше пожелание (например написать документацию по API). Но при одном условии - Вам действительно нужна эта документация (чтобы я не писал ее в пустую сейчас)

Update 03.01.2021

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

Ранее я не раз говорил, что мое решение представляет из себя конструктор, т.е. мой конечный клиент либо интегратор, либо самоделкин (DIY любитель).

Клиент, который я предоставляю, является основным инструментом для интегратора. Пользователь тоже может им пользоваться, но для пользователя он будет слишком громоздким и не совсем удобным.
Зачем пользователю такой клиент, если ему нужно просто включать свет в паре комнат?

Конкретно для пользователя я сделал точки входа. Например точку входа Телеграмм или Алиса, где пользователь может управлять устройствами гораздо удобнее. Также были созданы виджеты под Android, которыми я сам пользуюсь очень часто (моя жена пользуется телеграмом и ее вполне это устраивает). Возможно в этом году я стану разработчиком под ios и у нас появится клиент и виджеты под iphone.

Но, в рамках данной задачи (гидропоники), для специалистов я бы создал специальный веб проект, где были бы выведены многочисленные графики, сгруппированы показания, выведены специальные элементы модификации проекта (параметров устройств и сценариев).
API открытое, этим проектом может заняться сторонняя компания, а можно обратиться в Dipex Group - они могут разработать дизайн, WEB портал и разместить его в своем ЦОД'е.

core5277, логирование

Сразу несколько изменений.

  Ранее логирование было вынесено в виде драйвера, при этом часть кода находилась в ядре.
Скорость UART логирования в порт(BAUDRATE) была 115200, что сулило большие проблемы так как при передаче октета прерывания запрещались.
Удобство было не очень, например часто приходилось писать конструкции вида:

LDI YH,high(_CORE5277_TEXT_STARTED)|0x80 ;ROM
LDI YL,low(_CORE5277_TEXT_STARTED)
MCALL CORE5277_LOG



Теперь так:
1) В основном файле проекта необходимо объявить LOGGING_PORT:
.SET    LOGGING_PORT                            = (PORTC<<4)|PC0
  После чего, в инициализации ядра произойдет подгрузка файла с функционалом для логирования и инициализация логирования.
  Если LOGGING_PORT не объявлять, то файл подгружен не будет, но все метки для логирования будут также доступны, и мы сэкономим сотни байт ПЗУ.

2) Скорость UART для логирования теперь 460800. При передачи байта прерывания также запрещаются, но теперь на передачу байта требуется ~22 микросекунды. Таймер к примеру тикает каждые 50 микросекунд. Т.е. в теории времени вполне достаточно для логирования и прерываний.

3) Добавлены процедуры логирования символа, байта, слова, строки, строки из ПЗУ.
Теперь предыдущий пример выглядит так:
LOG_ROM _LOGSTR_CORE_STARTED

4) В процессе монитор - процедура позволяющая логировать состояние задач и ядра. К приеру, при перезагрузки контроллера, если включено логирование, мы получим вот такой дамп:

---COREDUMP:
TID:01 STA:00 RAM:0000.00 STK:0000.00 VRS:00000000000000000000000000000000
TID:02 STA:84 RAM:03E1.13 STK:0B13.00 VRS:00000000000000000000000000000000
TID:03 STA:84 RAM:03F4.39 STK:0C21.00 VRS:00000000000000000000000000000000
TID:04 STA:84 RAM:0000.00 STK:0CE5.00 VRS:05040000000000000000000000000000
TID:05 STA:84 RAM:0000.00 STK:0DB9.00 VRS:04000000000000000000000000000000
TID:06 STA:84 RAM:0000.00 STK:0E5E.00 VRS:D0041201139E4A042D80000000000000
TID:07 STA:84 RAM:042D.13 STK:0F31.00 VRS:16252412062006000000000000000000
TID:08 STA:00 RAM:0000.00 STK:0000.00 VRS:00000000000000000000000000000000
TID:09 STA:03 RAM:0000.00 STK:08A4.1B VRS:53503A303846430D0A00200000000000
TID:0A STA:03 RAM:0000.00 STK:0889.17 VRS:00000000000000000000000000000000
TID:0B STA:00 RAM:0000.00 STK:0000.00 VRS:00000000000000000000000000000000
TID:0C STA:03 RAM:0000.00 STK:08BF.1B VRS:00000000000000000000000000000000
TID:0D STA:00 RAM:0000.00 STK:0000.00 VRS:00000000000000000000000000000000
TID:0E STA:00 RAM:0000.00 STK:0000.00 VRS:00000000000000000000000000000000
TID:0F STA:03 RAM:0440.0C STK:0872.1E VRS:00000000000000000000000000000000
TID:10 STA:00 RAM:0000.00 STK:0000.00 VRS:00000000000000000000000000000000
TID:11 STA:00 RAM:0000.00 STK:0000.00 VRS:00000000000000000000000000000000
TID:12 STA:00 RAM:0000.00 STK:0000.00 VRS:00000000000000000000000000000000
TID:13 STA:00 RAM:0000.00 STK:0000.00 VRS:00000000000000000000000000000000
TID:14 STA:00 RAM:0000.00 STK:0000.00 VRS:00000000000000000000000000000000
TID:15 STA:00 RAM:0000.00 STK:0000.00 VRS:00000000000000000000000000000000
TID:16 STA:00 RAM:0000.00 STK:0000.00 VRS:00000000000000000000000000000000
TID:17 STA:00 RAM:0000.00 STK:0000.00 VRS:00000000000000000000000000000000
---DONE


В нем видно:
- номер задачи и ее состояние,
- адрес выделенной динамической памяти и ее размер,
- адрес стека и его размер ,
- дамп 16 байт переменных.

Пока так, потом будет больше полезной информации.

Вот кстати, как пример, часть кода монитора:
...
    LOG_ROM _LOGSTR_COREDUMP
    LDI LOOP_CNTR,0x01
_LOG_COREDUMP__TASK_LOOP:
    LOG_ROM LOGSTR_NEW_LINE

    MOV TEMP,LOOP_CNTR
    LOG_ROM _LOGSTR_TID
    MCALL LOG_BYTE
    LOG_ROM LOGSTR_SPACE

    MOV TEMP,LOOP_CNTR
    MCALL _CORE5277_TASK_HEADER_GET

    LDD TEMP,Z+_CORE5277_TASK_STATE
    LOG_ROM _LOGSTR_STATE
    MCALL LOG_BYTE
    LOG_ROM LOGSTR_SPACE

    LDD TEMP_H,Z+_CORE5277_TASK_RAM_OFFSET+0x00
    LDD TEMP_L,Z+_CORE5277_TASK_RAM_OFFSET+0x01
    LDD TEMP,Z+_CORE5277_TASK_RAM_SIZE
    LOG_ROM _LOGSTR_RAM
    MCALL LOG_WORD
    LOG_ROM LOGSTR_DOT
    MCALL LOG_BYTE
    LOG_ROM LOGSTR_SPACE
    ...



update:
  У драйвера нет собственного стека, он работает в стеке вызванной задачи. В мониторе STK драйвера указывает на точку входа в драйвер после инициализации. Различить драйвер от задачи можно по старшему биту в STA.

core5277, продолжение

Небольшое обновление.

Я столкнулся с критической ошибкой в своем ядре. Пришел к выводу, что метод резервирования памяти драйвера(при его инициализации) работает не корректно. Из-за этой причины я не могу закончить пару драйверов.
Поэтому пришлось увеличить заголовок задачи с 10 байт до 13, и приступить к реализации динамического выделения памяти(мелочь, а приятно). Здесь как обычно, ничего нового, просто еще один велосипед. Запланировано три метода ядра - переопределение объема выделенной памяти(изменение размера), выделение дополнительной памяти и освобождение эннного количества байт. При этом, задача или драйвер всегда будет знать сколько памяти ему выделено из заголовка задачи/драйвера. Ну и теперь задача тоже сможет выделять себе память.

Я еще у меня в руках модуль Dipex'а  SIM868 с переферией:
- 1x DS18B20
- 2x I2C EEPROM(вроде на 32KB каждая)
- 1x RS232
- 1x I2C DS3231(часы реального времени)
- 1x RS485
- BK-868 v2.1(2x SIM модуль)

Хорошая борда для реализации драйвера выделения внешней памяти(EEPROM), драйвера часов реального времени и работы с SIM модулем посредством AT комманд.
Кстати, по сути, на этой железке будет задйствовано 2 устройства на I2C шине и 4 UART'а, при этом встроенный только один.

Кстати, как оказалось, не так давно на Speccy появилась достойная ОСь - NedoOS и сетевая карта ZXNetUSB.
Куда мир катится? Как с такими решениями Intel, Microsoft и Google будут шпионить за пользователями? Там ведь, даже в процессор шпиона не встроишь.

А что это за плата скрипит?...

А палата эта разрабатывалась для аквариумистов. Пока не готов софт, свое ядро мне сильно в этом поможет.

Плата имеет функционал:
1) Диммер ламп накаливания(220В)
2) 3 канала 220В(вкл/выкл)
3) 3 канала до 24В(для светодиодных ламп, в том числе RGB)
4) Порт подключения датчика температуры ds18b20
5) Цифровой порт подключения. Например для датчика уровня воды
6) Бипер, для звуковой сигнализации
7) Порт расширения для модуля Wi-Fi, Bluetooth и т.д.
8) Часы реального времени
9) Порт расширения, например для клавиатуры и дисплея
10) Порт RS485 для настройки и подключения к проекту 5277.ru(который даст широкий функционал по большинству перечисленных пунктов)

Новый функционал, краткий очерк.

Пока мир сходит с ума, я понемногу починяю примус.

Честно говоря я даже не знаю, что считать новым, а что нет.
К примеру не так давно было решено выделить три модели работы клиента:



1) Облако
2) Прямое подключение к контроллеру
3) Новое - прямое подключение к устройствам.

Немного о третьем варианте.

Скажем так, вы прикупили WiFi розетку, и просто хотите управлять ей с телефона, ну или с компьютера.
Ну так вот, ни надо никакого контроллера или облака, просто Ваш клиент будет работать напрямую с устройствами, без сервера и контроллера. Функционала по минимуму, зато все просото, как работать с пультом от телевизора.

А еще мне попали в руки устройства продающиеся под брендом Xiaomi. Пара разных WiFi розеток, WiFi цветная лампа и Bluetooth датчик температуры и влажности. Все устройства введены в проект и работают. Работают как в локальной сети так и в облаке без серверов Xiaomi.





А еще у меня наконец-то дошли руки до инсталлятора под windows, оно даже работает. Там же лежит apk для Андроида.

Появилась группировка показаний от различных устройств в виде одного виртуального устройства.



Значительно снижена нагрузка на процессор в контроллере, а также пофиксены многие мелкие баги.

И честно говоря хрен знает что еще я забыл сказать. Это не важно, важно то, что я до сих пор вкладываю в свое детище силы и время.


Близится время когда клиент полетит китайцам, производящим всяческое дешевое железо без стоящего ПО.
Будет весело.

МЕТКА: Не забыть закупить попкорна.

P.S. И да, стоит отметить одну важную деталь - начат процесс введения сторонних беспроводных решений. Никаких серьезных проблем не обнаружено(кроме конечно мелких проблем из-за очередной дури 'великих' и 'ужасных' 'производителей')

P.P.S А это так, просто тестовый проект в Технопарке 'Русский'(ДВФУ)

JSON зло

Потоковый парсинг нескольких десятков килобайт JSON на мини компьютере отработал за несколько десятков секунд в режиме процессора OnDemand.

Недавно я задавался вопросом, почему на старом смартфоне(с андроидом 4.4) происходят постоянные сетевые сбои - дело просто в таймауте, который у меня выставлен на 5 секунд.
Просто один только парсинг json'а сжирает гораздо больше времени...

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

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

В итоге я создал свой протокол, который в текстовом виде выглядит как JSON, но передача информации осуществляется чисто в бинарном виде, что значительно упрощает его парсинг.

Новый функционал, сценарии.

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

К примеру:
Я могу создать несколько сценариев, причиной запуска которых будет недоступность контроллера(со стороны сервера).
первый, срабатывает через 3 минуты, его задача проинформировать
второй, срабатывает через 15 минут, его задача перезапустить сеть(как раз на базе нового функционала)
третий, срабатывает через 20 минут, он полностью перезагрузит компьютер с контроллером.

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