Программа для программирования knx
As a fieldbus for building automation, KNX is the successor of the EIB, BatiBus and EHS fieldbuses. Technologically, KNX is a compatible enhancement of the EIB, extended to include important configuration mechanisms and transmission media.
Scope of CODESYS KNX
- Integrated configurator for I/O channels in the CODESYS Development System
- Integrated I/O driver
- KNXnet/IP protocol stack in form of a runtime system component for CODESYS Control
- Data exchange function with the ETS configuration system
Available products and related datasheets:
Benefits
- Unique solution for connecting a freely programmable controller / PLC to the KNX building protocol
- Easy data exchange with the ETS configuration system: CODESYS users work in CODESYS, ETS users work in ETS.
- Intelligent update and merge mechanism between CODESYS and ETS
- Flexible engineering of building input and output data including functionalities like the visualization in a web browser displayed on tablets or smartphones
- Gateway function between KNX and other protocols like BACnet ® , Modbus or OPC UA
- New possibilities in building automation by combining room and HVAC automation
KNX Integration in CODESYS
Howtoget
Screenshots
CODESYS Group | We software Automation. to software
[ˈsɒftwɛər]
transitive verb
__softwared/softwaring
: to develop software
// to software automation: to develop software for automation purposes
The CODESYS Group is the manufacturer of CODESYS, the leading hardware-independent IEC 61131-3 automation software for developing and engineering controller applications.
CODESYS ® is a registered trademark.
В прошлом веке люди только мечтали о том, чтобы можно было дистанционно управлять электрикой и электроникой в доме. Но сейчас это стало реальностью благодаря системе «Умный дом». Под этим словосочетанием понимают способ автоматизации домашнего быта путем объединения всех электроприборов и бытовой техники в доме в единую экосистему. Сегодня в мире существует несколько признанных стандартов построения данной системы. Про один из них мы и поговорим далее.
Устройство для измерения и показа различных метеорологических параметров: температуры, влажности, давления
Система домашних устройств, способных выполнять действия и решать некоторые повседневные задачи без участия человека
- KNX — децентрализованная система. Это значит, что при необходимости можно заменить любой компонент, почти не оказывая влияния на остальные. В частности, нет централизованного контроллера, который бы управлял всеми устройствами.
- Система не привязана к конкретному вендору. Можно выбирать любое оборудование, исходя из потребностей, бюджета и эстетических предпочтений. Как правило, взаимосвязи между устройствами разных производителей прописываются без каких-либо проблем.
- В любой момент систему можно расширять и улучшать. Например, если изначально были установлены кнопочные выключатели, при возникновении потребности и возможности можно заменить их на сенсорные.
Исполнительные устройства (актуаторы) — управляемые реле разнообразного назначения.
Сенсоры — кнопки, выключатели, термостаты, погодные станции.
Системные устройства — блоки питания, линейные соединители и прочее.
Программный инструмент для проектирования и настройки интеллектуальных домашних и строительных систем управления с системой KNX не зависит от производителя оборудования.
ETS — программное обеспечение, которое работает на компьютерах под управлением Windows.
1. Запускаем программу ETS 5 и создаем новый проект.
2. Создаем комнату, в которой будет располагаться оборудование.
3. Нажатием на кнопку Add Devices» открываем каталог оборудования. Поиск оборудования в каталоге можно осуществлять по артикулу или серии устройства.
4. С помощью этой системы будет осуществляться управление освещением и розеточными группами. Поэтому добавляем актуатор, который будет подключать/отключать все эти группы, и рум-контроллер, который будет посылать команды на управляющее устройство. Чтобы добавить оборудование в комнату, нужно перетянуть его в соответствующее поле из каталога.
Чтобы на примере показать работу с KNX-устрйоствами мы взяли оборудование:
- Контроллер Wiren Board 6.7.
- Модуль расширения WBE2-I-KNX.
- Термостат KNX Albrecht Jung A2178.
- Выключатель двухканальный ABB US/U2.2 Universal-Schnittstelle, 2fach.
- Блок питания KNX Mean Well KNX-20E-640.
- Компьютер с ОС Windows.
Подготовка
Контроллер
Подключение контроллера Wiren Board к шине KNX с помощью модуля WBE2-I-KNX, установленного в разъём MOD1
- Установите и настройте модуль расширения WBE2-I-KNX.
- Подключите шину KNX на клеммы модуля. Например, модуль установлен в разъем MOD1, значит шину нужно подключить к разъёму mod_out_1 по схеме: положительный провод на клемму O1, отрицательный — клемма O3.
- Подключите на шину блок питания KNX и термостат.
- Включите питание — светодиоды на термостате начнут мигать примерно раз в секунду (1Гц).
Компьютер
Установка ETS5 — архив с программой
Теория KNX
Адресация
Про групповые адреса и телеграммы читайте на странице KNX.
Примеры групповых адресов:
- Выключатели с адресами 0.0.1 и 0.0.2
- Реле с адресом 0.0.5
Реализация в контроллере Wiren Board
Сервис wb-mqtt-knx получает и отправляет телеграммы через knxd и модуль расширения WBE2-I-KNX.
Обнаружение KNX-устройства
Обычно адрес нового устройства на шине неизвестен.
Но его легко обнаружить:
- Из документации на термостат видно, что есть кнопка L и светодиод K, в нормальном режиме скрытые под регулятором.
- Нажимаем отвёрткой кнопку — светодиод начнёт мигать, сигнализируя от том, что устройство перешло в режим программирования.
- В программе ETS5 переходим Системная шина → Диагностирование → Индивидуальные адреса → Режим программирования и нажимаем кнопку Старт.
- После того, как устройство будет найдено — нажмите кнопку Стоп, чтобы не занимать шину.
Фрагмент инструкции на термостат KNX Albrecht Jung
Окно поиска устройств в режиме программирования
Найдено устройство с адресом 15.15.255
Диагностика неисправностей
В процессе обнаружения устройств, ETS5 отправляет в KNX-шину телеграммы, которые можно отследить. Для этого нужно подписаться на топик /devices/knx/controls/data :
Также для диагностики можно вывести телеграммы из шины с помощью knxtool:
Ещё можно управлять светодиодом K из ETS5, для этого перейдите в меню Системная шина → Диагностирование → Индивидуальные адреса → Проверка индивидуального адреса
Создание проекта
Новый проект
Создадим в программе ETS5 проект.
Если это первый проект на этом компьютере, то нужно скачать и импортировать базу устройств:
- Скачайте базу устройств по с сайта производителя.
- Распакуйте архив и импортируйте нужные устройства.
После установки базы устройств:
- Создайте новый проект, для этого нажмите кнопку с зелёным плюсом «+».
- Укажите произвольное имя проекта.
- В разделе Топология оставьте TP (Twisted Pair).
Всё, у нас есть автоматически созданное «здание», которе называется так же как проект.
Файл базы устройств
Кнопка создания нового проекта
Форма создания нового проекта
Устройство
Физическое размещение — это этаж, комната или строение.
Добавим новую комнату:
- В окне Задания, нажмите на стрелку рядом с названием функции.
- Из открывшегося списка выберем пункт Комнаты.
- Далее нажмите на кнопку Добавить комнату и введите наименование.
Теперь, когда у нас есть физическое размещения для устройства (комната), мы можем добавить само устройство:
По алгоритму выше, добавьте второе устройство — выключатель. Он сразу есть в каталоге ETS5 и скачивать базу не нужно. Ему назначим адрес 1.1.5
Теперь в проекте есть два устройства.
Взаимодействие контроллера Wiren Board с KNX устройствами
Настройка в ETS
В нотации KNX принято индивидуальные адреса записывать через точки, а групповые — через слеши, поэтому:
- Добавьте для канала A устройства US/U2.2 индивидуальный адрес 1.1.5 .
- Создайте новый групповой адрес 1/1/55 .
Конфигурирование канала А как кнопки
Создание группового адреса
После настройки загрузите модуль в прикладную программу и проверьте, что при замыкании входа A отправляются телеграммы на указанный выше групповой адрес:
То же самое вы сможете наблюдать при мониторинге шины в ETS.
Настройка в контроллере Wiren Board
Здесь мы рассмотрим пример, дополнительную информацию смотрите в описании сервиса wb-mqtt-knx.
Настраиваем устройство в веб интерфейсе:
- Device ID будет именем устройства, то есть частью пути к MQTT топику
- Title - именем окна в Devices, произвольное
- Control ID - именем канала устройства
- Title именем канала в Devices, произвольное
В Devices групповой адрес контрола можно узнать, если навести курсор мыши на его название.
Взаимодействие с правилами
Изменение состояния контрола 1.1.5/SwitchA можно использовать для управления любыми устройствами, подключенными к контроллеру, в том числе и другими KNX устройствами.
Допустим, нужно включать и выключать выход A1 контроллера Wiren Board в зависимости от состояние контрола 1.1.5/SwitchA, тогда правило на wb-rules будет примерно таким:
Правило будет вызываться при любом изменении контрола (при приходе телеграммы) и устанавливать устройство wb-gpio/A1_OUT (выход A1) в состояние, указанное в телерамме.
Информация в статье устарела Выставочный демо-стенд WB-KNX. Создан, как пример использования контроллера Wiren Board с модулем KNX. Стенд оснащен оборудованием с разными шинами и протоколами, объединяя их в одну систему через контроллер WB6.
Диммер HDL M/D06.1, Релейный модуль GIRA 2152 00/I01
Панельки HDL P03.2-A и MPT14.1
Контроллер WB6, релейный модуль WBIO-DO-R10A-8, модули входов WBIO-DI-DR-8 и WBIO-DI-HVD-8, датчик температуры DS18B20
Modbus устройства WB-MDM2, WB-MR3LV/S, WB-MRGB
Блок питания KNX Berker
Состав
Оборудование KNX
1) Панелька HDL MPT14 Controller (HDL-M/MPT14.1 v1.0-1)
2) Панелька HDL Panel 3 Rocker Controller (HDL-M/P03.2-A v.HDL-V1.2-6)
3) Диммер HDL M/D06.1
4) Релейный модуль GIRA 2152 00/I01
5) Блок питания KNX Berker
Оборудование WB
2) KNX Module for WB6 (WBE2-I-KNX) (вставлен в разъем MOD1 контроллера WB6)
Modbus оборудование
Порт RS485-1 (115200 8n2)
Другое оборудование
1) Блок питания faraday 12w/12-24v/din (2шт)
2) Датчик температуры DS18B20
3) Индикаторы 220v (2шт)
4) Лампы накаливания (2шт)
5) Выключатели звонкового типа (2шт)
6) Светодиодная лента RGB
Описание
Основная идея стенда - показать взаимодействие между устройствами с разными протоколами. И то, что контроллер Wiren Board 6 может расширить уже существующую автоматизацию на KNX другими более дешевыми устройствами. Либо наоборот, если Вам захотелось добавить в проект красивую KNX панельку, при этом остальное оборудование работает по modbus. Далее подробно рассмотрим настройку стенда и написание правил.
Настройка контроллера
Для начала настроим модули Wirenboard. Для этого в web-интерфейсе переходим в раздел Configs → Hardware Modules Configuration И выбираем установленные модули. В нашем случаеː
Internal slot 1 - Вставлен KNX Module for WB6 (WBE2-I-KNX), выбираем "WBE2-I-KNX: KNX/EIB TP-UART"
External I/O module 1 - подключен модуль WBIO-DO-R10A-8 Relay Module, выбираем "WBIO-DO-RxA-8: 8 Channel Relay I/O module"
External I/O module 2 - подключен модуль WBIO-DI-DR-8 I/O Module, выбираем "WBIO-DI-DR-8: Digital inputs (dry contact) I/O module"
External I/O module 3 - подключен Модуль наличия 220В (WBIO-DI-HVD-8), выбираем "WBIO-DI-HVD-8: High Voltage Digital Inputs I/O module"
После этого нажимаем кнопку "Save".
Настраиваем modbus устройства. Для этого в web-интерфейсе переходим в раздел Configs → Serial Device Driver Configuration и задаем нужные параметры. Как это сделать можно посмотреть в документации к устройствам, здесь подробно об этом писать не буду.
Следующим шагом будет установка и настройка программ для работы с KNX. А именноː Knxd - Для взаимодействия с шиной KNX, KnxTool - для отладки, WB-KNXD-CONFIG - для удобной настройки KNXD через веб-интерфейс контроллера, MQTT_KNX - для взаимодействия движка правил (Движок правил wb-rules) c Knxd. Для установки всех программ разом введите команду в консольː
После установки программ в web-интерфейсе переходим в раздел Configs → KNXD Configuration для настройки KNXD.
"Driver (-b, --layer2)" - В этом поле нужно указать драйвер и путь к устройству. В нашем случае указываем ncn5120:/dev/ttyKNX1
"EIB address (-e, --eibaddr)" - задаем EIB адрес нашему контроллеру 1.1.255
"Client-addrs (-E, --client-addrs)" - указываем диапазон адресов, которые будут выдаваться EIB клиентам 1.1.5:50
"Discovery (-D, --Discovery)" - Ставим галку, что бы контроллер отвечал на запросы поиска.
"Tunnelling (-T, --Tunnelling)" - Ставим галку
"Routing (-R, --Routing)" - Ставим галку
"Server (-S, --Server)" - Тоже ставим галку, что бы включить EIBnet/IP multicast сервер на контроллере
"Custom name of the server" - Произвольное имя сервера. Впишем WirenboardKNX
"Server address" - Оставим именно этот адрес, что бы сервер автоматически определялся в ETS5ː 224.0.23.12:3671
Остальные настройки на данный момент нам не интересны. Сохраняем изменения нажав кнопку "Save". На этом закончим настройку контроллера и перейдем к настройке KNX устройств через ETS5.
Настройка KNX устройств через ETS5
Далее нужно выбрать интерфейс. Заходим во вкладку Системная Шина → Соединения → Интерфейсы. Здесь во вкладке "Показать интерфейсы" отображаются автоматически найденные по бродкаст адресу интерфейсы. Если интерфейсы не определились автоматически, то во вкладке "Сконфигурированные интерфейсы" можно нажать кнопку "добавить" → "IP Tunneling" и справа ввести IP адрес контроллера с запущенным KNXD, указав порт 3671 и нажать кнопку "выбрать".
После этого возвращаемся в вкладку "Обзор" и создаем новый проект (или импортируем уже готовый, если имеется). В новом проекте создаем комнату и называем на пример "KNX стенд". Нажимаем на комнату → Добавить → Устройство. Откроется вкладка каталога устройств. В нашем случае необходимых устройств в каталоге нет. Их нужно импортировать из специального файла, который распространяет производитель (HDL). Необходимые файлы можно найти на гугл диске компании HDL. Находим нужные файлы и импортируем их в ETS5, после чего добавляем нужные устройства в комнату KNX стенд.
Далее настраиваем каждое устройствоː задаем индивидуальный адрес, включаем необходимые функции и присваиваем им групповые адреса. Если необходимо связываем устройства групповыми адресами между собой. Полный процесс настройки описывать так же нет смысла. Для каждого устройства он индивидуальный. Ниже я оставлю ссылку на проект и все используемые для этого проекта файлы.
Как только все устройства настроены, адреса заданы - выбираем в верхнем меню → Ввод в эксплуатацию → Загрузка → Полная загрузка → Следуя указаниям на экране нажимайте на кнопки "Режима загрузки" на устройствах для загрузки программ.
KNX is a very common building automation protocol which runs on dedicated 9600-baud wire as well as IP multicast. knxd is an advanced router/gateway which runs on any Linux computer; it can talk to all known KNX interfaces.
STOP if you install on Debian
Debian packaging has been moved to the debian branch. Please use that branch (by way of git checkout debian ) if you're following some (outdated …) installation instructions for Debian, Ubuntu or their derivatives.
This version should be OK for general use.
Check the Wiki page for other version(s) to use.
- ETS programming may or may not work out of the box. You might need to use the single filter in front of your KNX interface.
Daemon configuration differs depending on whether you use systemd. If "systemctl status" emits something reasonable, you are.
If you use Linux and systemd, the configuration file is /etc/knxd.conf . Socket activation is used for the default IP and Unix sockets (port 6720 and /run/knx, respectively). If not, the location of your configuration file depends on your init system.
In knxd or knxd.conf , KNXD_OPTS can be set to either the legacy command line arguments, or the location of the new .ini (e.g. KNXD_OPTS=/etc/knxd.ini )
New ".ini" configuration file
knxd is typically started with "knxd /etc/knxd.ini".
The file format is documented in "doc/inifile.rst". You might want to use the program "/usr/lib/knxd_args" to create it from previous versions' command-line arguments.
The default Unix socket is /run/knx . Old eibd clients may still use /tmp/eib to talk to knxd. You need to either change their configuration, or add "-u /tmp/eib" to knxd's options. (This was the default for "-u" before version 0.11.)
New Features since 0.12
- speed up CGI initial setup (a lot)
- support another USB interface
- found another uninitialized variable
- Fixed two problems with the "pace" filter that resulted in excessive delays.
- knxd's udev rules were lost in the Debian branch. Restored (to systemd subdir).
- Fix a memory leak in the FT12 driver
- fix the console rule in README
- Cleanup: remove debian packaging, will be in a separate branch
There is a new "retry" filter which controls closing and re-opening a misbehaving driver. This filter is implicitly auto-inserted in front of a driver.
Internal: Driver errors are now signalled with "stopped(true)" instead of "errored" which reduces code duplication.
Default timeout for EMI acks increased to 2 seconds Some USB interfaces manage to be abysmally slow Also hopefully-fixed USB retry and shutdown handling so that the "retry" filter can do its work.
Replies from devices in programming mode are no longer retransmitted to the originating interface.
Tags no longer use a leading 'v'.
udev rule for SATEL USB interface
- There are no longer separate --enable-tpuarts and --enable-tpuarttcp options. Instead, you control both with --enable-tpuart. (This is the default anyway.)
includes a translator (knxd_args) from options to config file
All settings are still usable via the command line
Complete stack refactored
You may now use global filters.
USB handling updated
Most device-specific drivers are now split into a top part which translates KNX packets to wire format (usually CEMI), and a bottom part which transmits/receives the actual data. This enables extensive code sharing; knxd also can use TCP connections instead of actual serial devices.
Startup sequencing fixed: KNX packets will not be routed until all interfaces are ready.
Also, systemd will not be signalled until then.
Configuration options to not start, or start and ignore failures of, specific interfaces
knxd will now retry setting up an interface
use libfmt for sane and type-safe formatting of error and trace messages
packet-level "logging" calls in various drivers have been removed
logging packets is now done with the new "log" filter
Logging of complete packets (inconsistently bit 1, 2, or 8 of the tracing mask) has been removed
This also applies to global packet logging.
Complain loudly (and early) if knxd needs -E / client-addrs=X.Y.Z:N
knxd can restart links when they fail, or start to come up.
Interfaces are now either used normally, or in bus monitor mode. This is set in the configuration file / on the command line. There is no longer a way to switch between these modes; "knxtool busmonitor" will no longer change the state of any interface.
Queuing and flow control
Previously, all drivers implemented their own queueing for outgoing packets, resulting in duplicate code and hidden errors.
In v0.14, the main queueing system will pace packets for the slowest device. If you don't want that, use the "queue" filter on the slow device(s).
All queues in individual drivers have been removed.
EMI handling refactored
This eliminated some common code, found a couple of bugs, and lets us use a common logging module (controlled by bit 0 of the tracing mask) for comprehensive packet debugging.
knxd was rewritten to use libev instead of pthsem.
knxd now supports multiple interfaces, back-ends, and KNX packet filters.
For a (german only) history and discussion why knxd emerged, please also see: eibd(war bcusdk) Fork -> knxd
When in doubt, please check out the branch corresponding to your Linux distribution's flavor, and read this section there.
This part covers "manual" installation.
If you would like to submit patches for Mac OSX or Windows, go ahead and create a pull request, but please be prepared to maintain your code.
Adding a TPUART USB interface
Therefore, you do this:
Run udevadm info --attribute-walk /sys/bus/usb/drivers/cdc_acm/*/tty/ttyACM0 .
We're interested in the third block. It contains a line ATTRS=="busware.de" . Note the KERNELS=="something" line (your something will be different).
Of course you need to replace the something with whatever udevadm displayed. An example file should be in /lib/udev/rules.d/ .
Run udevadm test /sys/bus/usb/drivers/cdc_acm/*/tty/ttyACM0 .
verify that /dev/knx1 exists and belongs to "knxd":
add -b tpuarts:/dev/knx1 to the options in /etc/knxd.conf .
If you have a second TPUART, repeat with "ttyACM1" and "knx2".
You'll have to update your rule if you ever plug your TPUART into a different USB port. This is intentional.
Adding any other USB interface
These interfaces should be covered by the udev file knxd installs in /lib/udev/rules.d . Simply use -b usb: to talk to it, assuming you don't have more than one.
Adding a TPUART serial interface to the Raspberry Pi
On the Raspberry Pi 2 and 3 the console is /dev/ttyAMA0. The udev line is:
On the Raspberry Pi 4 the console is on /dev/ttyACM0. The udev line is:
This rule creates a symlink /dev/knx1 which points to the console. The knxd configuration will use that symlink.
On the Raspberry Pi 2 and 3 you need to disable the serial console. Edit /boot/cmdline.txt and remove the console=ttyAMA0 entry. Then reboot.
On the Raspberry Pi 3, the serial console is on ttyAMA1 by default. However, that is a software-driven serial port – the single hardware serial interface is used for Bluetooth on the Pi3. Varying CPU speed causes this port to be somewhat unreliable. If this happens, disable Bluetooth by adding
to /boot/config.txt , run systemctl disable hciuart , and reboot. The TPUART module is now back on ttyAMA0 .
Migrating to 0.14
If you build knxd yourself: install the libfmt-dev package, if possible.
The knxd build process will try to download and build libfmt when that package is not present.
knxd is now configured with a .ini-style configuration file.
The old way of configuring knxd via a heap of position-dependent arguments is still supported.
You can use /usr/lib/knxd_args to emit a .ini file that corresponds to your old list of arguments.
Not configuring client addresses is now a hard error. Knxd will no longer multiplex its clients onto its own address.
knxd will not start routing any packets unless startup is successful on all interfaces.
This means that it is now safe to use "socket activation" mode with systemd. Previously, knxd might have lost the initial packets.
knxd can now attach filters to a single interface, or to the core (i.e. all packets get filtered).
Tracing no longer logs the actual decoded contents of packet. If you need that, use a "log" filter appropriately.
knxd now transmits data synchronously, i.e. individual drivers no longer buffer data for transmission. If you don't want that, use the "queue" filter on slow interfaces.
Migrating to 0.12
If you build knxd yourself: install the libev-dev package. You no longer need the pthsem packages.
You may need "-B single" in front of any "-b ipt:" or "-b usb:", esp. when you need to program a device; normal use is often not affected. knxd emits a warning
Message without destination. Use the single-node filter ('-B single')?
when it detects mis-addressed packets.
You need "-e"; knxd no longer defaults to address 0.0.1.
You need "-E" if you want to allow clients to connect (options -u -i -T). As that's almost always the case, knxd will print a warning if this option is missing.
If you use knxtool's management tools (any command with "progmode" or whose name starts with 'm'), please open an issue because knxd currently does not support these commands.
Migrating from eibd
Before you build knxd: remove any traces of the old eibd installation from /usr/local , or wherever you installed it.
The order of arguments is now significant. Among the "-D -T -R -S" arguments, -S must occur last. Arguments which modify the behavior of an interface must be in front of that interface. Global arguments (e.g. tracing the datagram router) must be in front of the "-e" option.
The 'groupswrite' etc. aliases are no longer installed by default. To workaround, you can either add /usr/lib/knxd to your $PATH , or use knxtool groupswrite .
If you use Debian Jessie or another systemd-based distribution, /lib/systemd/system/knxd.socket is used to open the "standard" sockets on which knxd listens to clients. You no longer need your old -i or -u options.
knxd's Unix socket should never have been located in /tmp ; the default is now /run/knx . You can add a "-u /tmp/eib" (or whatever) option if necessary, but it's better to fix the clients.
- Any contribution is very welcome
- Please use Github and create a pull request with your patches
- Please see SubmittingPatches to correctly Sign-Off your code and add yourself to AUTHORS ( tools/list_AUTHORS > AUTHORS )
- Adhere to our coding conventions. The git archive includes a helpful .vimrc file if you use VIM.
Compensation – personal statement
KNX development is not a simple matter and requires both time and dedicated hardware for tests. The ETS software isn't exactly cheap, either, and there is no free replacement. (I'd like to change that.)
Thus, wearing my hat as the (current) main author, I (Matthias Urlichs) would like to ask you to consider contributing to knxd's development.
Читайте также: