• View
• Edit
• History
• Print

PlumbingControllerBackup

Конфигурация узлов и моделей BLE Mesh

Постановка задачи.

Чем мы хотим управлять и что хотим контролировать:

1. Управлять, разумеется, мы может только вентилями.
2. У нас есть следующие датчики: протечки, давления, температуры и счетчики расхода воды.
3. Если к устройству подключены 5-ти проводные вентили, то мы можем определять их неисправность.

Для управления вентилями, разумеется, проще использовать Generic On/Off сервер. Датчики и диагностику вентилей хотелось бы реализовать в Sensor сервере, но тут имеется проблема: в списке Device Property ID спецификации BLE Mesh отсутствуют сенсор протечки и счетчик расхода. Добавлять кастомные параметры совсем не хочется, а вот остаться в рамках спецификации хочется. Поэтому, после небольшого мозгового штурма, было принято волевое решение добавить два Vendor Specific сервера: Volume Consumption Server и Leak Sensor Server. Диагностику вентилей можно повесить на Health Server, код 0x32 (Mechanism Jammed Error).

Предлагается управлять не каждым вентилем в отдельности, а организовать их в группы: ввод холодной воды, ввод горячей воды, полотенцесушитель и бойлер. Таким образом, для управления вентилей, вместо 6 элементов в узле можно обойтись 4-мя. Также, запрет одновременного открытия групп бойлера и ввода горячей воды будет в этом случае выглядеть более логичным, нежели какая-то абстрактная карта запретов. Можно, также, объединить группу полотенцесушителя и ввода горячей воды, и сократить количество элементов узла до 3-х, но я все-же хочу оставить возможность управлять полотенцесушителем отдельно, на тот случай, если мне понадобится время от времени его отключать.

Таким образом, конфигурация узла видится следующим образом:

1. MAIN, Health Server, Generic Battery Server, Leak Sensor Server, Generic OnOff Server, Sensor Server, Volume Consumption Server
2. Generic OnOff Server, Sensor Server, Volume Consumption Server
3. Generic OnOff
4. Generic OnOff

В первом (главном) узле, помимо управления вентилем ввода холодной воды, будут серверы состоянии резервной батареи питания (Generic Battery Server) и общий сервер для всех датчиков протечки. Изначально, когда я предполагал использовать для датчиков протечки Sensor Server, для каждого датчика должен был выделяться отдельный элемент узла, но, поскольку у нас будет вендорный сервер, то его протокол будет поддерживать список датчиков, и элемент нужен будет только один.

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

В сервере Health планируется отображать следующие параметры:

• Низкое/высокое значение напряжения линии питания.
• Статус батарей (на всякий случай, так как есть сервер батареи).
• Механическая неисправность вентиля - одна ошибка на все вентили. Для уточнения, с каким вентилем проблема, придется подойти к устройству.
• Повреждение датчика протечки (будет дублироваться в вендорном сервере Leak Sensor) - одна ошибка на все датчики.
• Так как у нас есть пищалка и символьный дисплей, то можно реализовать и Attention.

Vendor Volume Consumption (0xc0ffff)

Сообщения

• VOLUME_CONSUMPTION_GET = 0x00
• VOLUME_CONSUMPTION_STATUS = 0x01

VOLUME_CONSUMPTION_GET

Запросить значение счетчика расхода объема.

VOLUME_CONSUMPTION_STATUS

Значение счетчика расхода объема.

Vendor Leak Sensor (0xc1ffff)

Сообщения

• LEAK_SENSOR_GET = 0x00
• LEAK_SENSOR_STATUS = 0x01

LEAK_SENSOR_GET

Запросить статус всех датчиков протечки или одного конкретного.

Если поле LEAK_SENSOR_INDEX отсутствует, то возвращается статус всех датчиков протечки. Таким образом, можно получить их общее количество.

LEAK_SENSOR_STATUS

LEAK_SENSOR_STATUS представляет собой массив элементов длиною 2 байта, которые представляют собой статус датчиков протечки.