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, да, контроллер будет расположен прямо на интернет шлюзе) просто наживая кнопки в клиенте или используя фразы в телеграме.

Мини реле на 10А



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

Еще раз, что же здесь особенного, если в кратце:
1) Управление по шине RS485 с протоколом схожим с MODBUS RTU (управление, чтение показаний, настройка)
2) Потребление тока самой реле снижено в 2 раза (кроме процесса включения)
3) Управление через кнопку, выключатель или сенсор.
4) Подключаемый датчик температуры DS18B20 (без разъема, как и кнопка припаивается на плату)
5) Функционал термореле (автоматическое включение и выключение в зависимости от режима работы и температуры)
6) Датчик тока
7) Отключение по порогу тока.
8) Питание от 9 до 24 вольт.
9) Коммутируемый ток - реле на 10А, напряжение до 250В
10) Очень маленькие размеры, помещается во многие подрозетники, даже в некоторые удлинители.

Ну и конечно комплексное программное обеспечение, бесплатное, с широкими возможностями.

Текущая задача...

Пока отложил разработку димера и переключился на утилиту настроки устройств своей серии, вот скриншот:


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

Основная задача утилиты, как было сказано ранее - предоставить возможность настройки устройства перед эксплуотацией.
Эта утилита будет поддерживать все мои устройства и будет выполнять все возможные операции над ними.
Основным требованием будет непосредственное подключение шины к компьютеру, к примеру все через тот-же USB RS-485 свисток

Кстати вот так он выглядит:

Основы технические и не только...

И так, как я писал ранее, по поводу своих устройств, в основе лежит проводное решение.
Основанное на стандарте RS-485 (https://ru.wikipedia.org/wiki/RS-485).

Т.е. мы имеем шину, на которую параллельно подключаем все устройства.
Шина представляет из себя широко распространенный кабель UTP2 (две витые пары).
В принципе можно использовать и любой другой кабель с 4-мя жилами.
Но витую можно пробросить на сотни метров.
Но я с такими расстояниями не работал, нет у меня дома даже 100 метрового коридора.

Шина состоит из двух линий RS-485(а и b) и питания (+ и -).
Напряжение должно быть постоянным в пределах от 6.5 до 15 вольт.
Необходимый ток зависит от количества устройств на шине и от их потребления.
В среднем устройство потребляет около 0.010-0.030А.
Исключение составляют устройства имеющие потребитель, например силовое реле (но не все).

В данном решении используется широко известный протокол Modbus со всеми его недостатками.
К примеру, на шине может существовать только один мастер и он поочередно опрашивает все устройства.

Collapse )

В этой концепции пожалуй самое слабое место - это отсутствие гальванической развязки устройств на шине, но ставить на каждое устройство DC-DC преобразователь и трехканальные оптопары дорого.
Дешевле взять шлюз RS-485 <-> RS-485 с гальванической развязкой для группы устройств.
К тому же он будет выполнять разграничение по логической части.
Я считаю, что такой узел нужно ставить на группу приборов, например на все приборы в каждой комнате.
Если, к примеру, Вам затопят зал и вода попадет в силовую управляемую розетку, то в крайнем случае у Вас выгорят все устройства в пределах комнаты.
Да и в конце концов, это же конструктор, Вы можете использовать к примеру WiFi RS-485 какой-нибудь шлюз или RS-485 модем.

Если смотреть в общем, то для организации системы Вам потребуется:
1) Набор устройств, при этом я планирую поддерживать железки сторонних производителей, в том числе и китайские варианты (вопрос только в разработке библиотек под эти устройства)
2) USB-RS485 преобразователь, либо любой другой преобразователь в RS485 (в этом случае, возможно, мне потребуется разработать под него библиотеку)
3) Кабель, желательно UTP2
4) Блок питания от 6.5 до 15 вольт постоянного напряжения
5) Компьютер, на который Вы установите приложение-контроллер. Это приложение будет непосредственно собирать информацию и управлять Вашими устройствами
(а при доступе в интернет - будет передавать данные на сервер).
Компьютер может быть в принципе любой, главное чтобы он поддерживал Java.
Требование на порты исходит только от выбранной Вами схемы подключения устройств.
К примеру, если шина подключена в Ethernet RS-485 шлюз, то на стороне компьютера Вам необходим будет либо Ethernet порт или Wi-Fi.
А возможно у Вас USB RS485 китайский свисток, тогда Вам нужен будет только USB порт.

А еще:
Еще Вам потребуется бесплатный клиент на компьютер, на котором Вы сможете как смотреть показания устройств, управлять ими, так и настроить полностью всю схему подключения устройств.

Для удобства управления я разрабатываю приложение похожее на пульт для мобильных Android устройств.

Также есть утилита предоставляющая показания по всем Вашим устройствам для программ типа MRTG.
И скорее всего скоро добавлю в нее возможность управления устройствами.


Как я говорил ранее, сделано многое, но предстоит сделать гораздо больше.
И, учитывая что это хобби, то кормить семью я вынужден другими делами, что конечно съедает большинство времени.
Поэтому дорабатывать его я буду еще очень долго, однако я считаю, что пришло время готовить документацию.

Как я планирую зарабатывать на проекте?
1) Я планирую выпустить две версии мобильного приложения. Одна будет бесплатная но с ограничением по количеству доступных устройств. Вторая платная, но без ограничений.
2) У меня есть несколько своих недорогих устройств, некоторые из которых уже прошли этап прототипирования. Планирую их продавать на том же ебее.
3) На сервере основная часть сервисов будет бесплатна.
Но расширенная часть будет стоить небольших денег, к примеру туда скорее всего войдут такие вещи как: больший объем хранения показаний, расширенная статистика, информирование по СМС, а может быть даже GSM голосовое информирование - было бы желание и время.
Кстати вполне реально сделать опрос электро/водо/тепло счетчиков с автоматической передачей показаний в ресурсную компанию.
4) Расширение набора поддерживаемых устройств - что-то я буду вводить бесплатно, за что-то, мне кажется, люди будут готовы скинутся на небольшую сумму.


Позже я опишу как компоненты системы, так и мои устройства с их фичами.