Сделал, действительно удаляются топики если публиковать пустые значения. В архиве исполняемые файлы для замены. Изменился только сервер, а конфигуратор остался тот-же.
У меня возникла еще вот какая мысль. Если сервер отвалится, то клиенты об этом не узнают. Может сделать чтобы сервер каждую секунду публиковал топик без сохранения (т.е. без флага Retain) например pp/uptime. Клиенты подписываются на этот топик и если в течении 5 секунд не получаю от топика уведомление, то предупреждают об этом пользователя или обнуляют переменные.
В процессе тестирования обратил внимание, что группа разделов не переключается (те нельзя взять в охрану или снять), в то время как разделы без проблем работают. Это у меня так или у всех?
Также еще есть предложение по улучшению - если на С2000-ПП вывести сообщения от всех блоков (например на данный момент меня интересует вскрытия блока), тк их много, то определить какой именно блок открыт нельзя, в логах просто указывается вскрытие и раздел с описанием ведущий на пульт. Тк нельзя точно определить какой именно прибор был вскрыт. Я обошел это ограничение и создал отдельные разделы в которые помесил сообщения от каждого прибора - в таком случае информация выводится, но все же это костыльное решение - все эти разделы и в пульте висят и глаза мозолят.
Можно ли выводить в журнале событий с какого прибора пришло?
Группы разделов не поддерживаются самим С2000-ПП. А как вы их (группы разделов) пытаетесь взять? Те номера разделов, которые содержатся в самом ПП никак не относятся к разделам пульта, это его собственные разделы. Если брать на охрану раздел ПП, то ПП скорее всего просто берет на охрану входящие в раздел шлейфы и не отправляет раздел на пульт. Это больше для удобства.
Чтобы вывести состояния самих приборов, нужно в конфигурации ПП добавить зоны, у которых номер шлейфа равен нулю, а тип зоны: 3. И задать описание для этой зоны. Тогда в событиях будет больше информации.
Это сделано для каждого прибора и если вывести в один раздел вместе с пультом - то он не показывает какой именно прибор вскрыт, чтобы показывал прибор - нужно для него создать отдельный раздел и сделать его описание. При этом на пульте вне зависимости от создания разделов - показывает какой прибор вскрыт.
Беру в охрану через таблицу разделов по номеру разделов. Те если есть раздел 1 в коротком находятся шлейфа, то да он все шлейфа ставит на охрану или наоборот внимает. Тоже самое я думал провернуть и с группой разделов через таблицу, но не заработало.
А вот как выглядит взлом корпуса у меня. Обратите внимание на столбец “ШС/Рл” в журнале событий. Это в Linux. В конфигурации пульта состояния всех приборов в одном разделе.
За что в конфигураторе отвечает идентификация раздела? Может есть описание программы? У меня он не заполнен, но у вас стоит судя по всему просто дублирование modbus раздела? Все остальное у меня также стоит.
Идентификатор раздела не обязателен, но я всёравно на всякий случай заполняю его в таблице ПП, кто его знает как там внутри ПП обрабатывается его отсутствие. Описания программы нет, но эти таблицы описаны в инструкции на ПП.
Топик pp/uptime пока не добавлял. Просто предложил для обсуждения. Может нужно как-то иначе для умных домов делать?
Все старые топики через УД я не могу получить обновления, у вас retain=false на всех топиках стоит, те они не говорят о своих события вновь подключенным новым клиентам и он их не может выловить, точнее поймать можно только если в этот момент происходит что-то на приборе (например переключилось реле), у меня по крайней мере пока не получается, хотя другие девайсы от других производителей залетают отлично, опыт в этом деле есть. Есть ли возможность добавить retain=true?
16 Замок - что имеется ввиду? Таблица ведь для шлейфов, а не для реле.
3 и 19 это не одно и то же? Если не одно и то же, тогда почему нет окна?
20 не понимаю назначение.
21 - это емкостной? Может его емкостным назвать?
Наверно нужно еще добавить Прибор (события о состоянии прибора). Нужно ведь?
И может я переупорядочу, например чтобы 7 и 17 были рядом?
Да, верно. Здесь я бы хотел уточнить может есть возможность также добавить тип устройства в реле, по тому же принципу топик как в датчиках сделать, и тем кому нужно уже выставят необходимый девайс и получат его сразу в УД. Например такие типы
Да верно одно и тоже, только в HomeKit есть сущность дверь, и она отдельно работает от контакта и нету сущности окна. Поэтому окно не добавил.
Здесь имеется ввиду если болид передает данные со считывателя (статус, ошибку или попытку считывать левой меткой) - то будет идти звонок в дом, те как будто на вызовной панели домофон кто-то позвонил, тем самым через УД можно вызвать всплывающее окно с камеры, и тд.
Да емкостей, объемный - сути не меняет, он так назван в системе УД поэтому я по привычке его обозвал так, можете назвать в терминологии Болида.
Если можно добавить топик и получать с него сообщения, то было бы неплохо.
Поменял, можно тогда на такой варианте остановится.
По состоянию датчика, сейчас датчик в конфигураторе HUB передает статусы: охрану взятие, снятие, контроль и тд, но не передает само состояние датчика (открыто или закрыто).
В УД логика работы такая - датчик все время мониторит состояние и передают его в систему умный дом, даже если если не включена охрана. Если поставить в охрану - и срабатывает датчик то уже подается сигнал проникновения (затопления и тд). Предложение - по датчикам передавать только состояние по примеру реле (0 не сработал, 1 сработал), либо как вариант забирать состояние АЦП если из него можно забрать необходимые данные двух состояний.
В варианте конфигуратора через MQTT можно отследить состояние реле, тк оно имеет значение 0 или 1 (простестировал, работает отлично), а вот в state датчиков передает информация со шлейфа 24/109 и тд - соответсвенно УД не видит его состояние 0 или 1 и считает что они всегда срабатывают тк имеют значения отличные от 0 или 1 и не указанные в шаблоне.
Раздел pp/part/state можно получить при запуске программы в MQTT только сделав такие действия, нажать в разделе MQTT сохранить чтобы топики начали публиковаться, затем остановить и запустить сервер. После чего считываются состояние разделов и передаются топики part в MQTT. Из-за этого при настройке в УД не залетели охранные программы, пришлось какое-то время повозиться и запускать вручную разделы на охрану чтобы поймать MQTT. Предложение: публиковать топики part сразу по умолчанию.
Описание разделов pp/relay/state/descr/ мне не удалось никак получить в MQTT, он не выводится в моем случае вообще.
Я так понимаю разделы брать и ставить на охрану через MQTT не дает сам Болид в целях безопасности? Тк передается только статус, то кнопки управления в УД (их отключить или удалить никак нельзя) по сути ничего не делают, просто бутафория, при нажатии ничего не произойдет. Но статус считывать можно.
Раздел с пультом С2000М также попадает в MQTT и выдает неизвестные сообщения для УД, соотвественно УД все время считает это охранной сигнализацией и показывает что она всегда включена. Предложение - системные разделы с пульта отнести в другой топик не связанный с part чтобы УД не считал его охранным разделом.
За что отвечают 111 - включить контроль, 112 - выключить контроль ? Здесь интересуюсь с целью привязать их в какому-то событию в УД, те сейчас используем только взять/снять (24/109)
В самом датчике также есть характеристики в которые можно записать разные значения, если их забрать из Болида. Например так.
Тип реле добавлю, и остальное тоже, постараюсь сделать на выходных.
ПП не поддерживает СКУД и вряд ли будет поддерживать. Думаю это не отсутствие технической возможности, а именно политическое решение Болида. Поэтому события от считывателя ждать не стоит
Полное состояние в топике /pp/zone/state я оставлю, может пригодится. Но добавлю топик /pp/zone/alarm, в котором будет 0 (отсутствие тревоги) и 1 (тревога).
2…4 Разделы проверю, доделаю.
Здесь могу так же сделать топик /pp/part/alarm
Это для пожарной сигнализации. Снять с охраны нельзя, но можно выключить контроль. При включении контроля оно должно автоматически встать на охрану.
Из АЦП лучше ничего не брать, ненадежно. Лучше я сделаю несколько топиков и расфильтрую нужную информацию по ним. Еще подумаю как это сделать, но пока можно так:
/pp/zone/state - так и остается, все состояния из таблицы состояний Болид.
/pp/zone/active - 0 (снято с охраны или отключено для пожарки) и 1 (на охране).
/pp/zone/alarm - 0 (отсутствие тревоги) и 1 (тревога).
/pp/zone/fault - 0 (отсутствие неисправности) и 1 (неисправность).
/pp/zone/tamper - 0 (отсутствие вскрытия) и 1 (вскрытие корпуса).
/pp/zone/battery - 0 (батарея в норме) и 1 (батарея разряжена/неисправна). Это для блоков питания, приборов и возможно для радиоканальных извещателей.
Ничего не упустил?
В Болиде есть технологические шлейфы (тип шлейфа задается в самом приборе при помощи программы UProg), которые не ставятся на охрану, но в любом случае выдают свое состояние (норма/нарушен). Для единообразия их тоже можно сделать как тревоги, и отображать в топике /pp/zone/alarm. Или для этого сделать отдельный топик? Но удастся ли это использовать в умном доме, ведь будут два топика: active и techno, а в умном доме для этого одно поле ContactSensorState.
Но еще есть охранный шлейф (опция для охранного шлейфа), который даже в снятом состоянии передает свое состояние: “снят с охраны и в норме”/“cнят с охраны и нарушен”. Его можно поставить на охрану и он выдаст полноценную тревогу в случае нарушения. Я выше приводил журнал событий, вот там как раз много событий от объемника, снятого с охраны. Вот непонятно как передать все его состояния. В /pp/zone/alarm попадет от него тревога только после постановки на охрану и нарушения. Непонятно как мониторить его в снятом состоянии. Если для технологических шлейфов делать отдельный топик, то можно было бы туда. Но как это расфильтровать в умном доме? Или сделать нарушение в снятом состоянии тоже тревогой, а умный дом пусть смотрит был ли шлейф на охране чтобы интерпретировать это как тревогу или просто как нарушение. А может не стоит с этим заморачиваться. Это просто для информации.
Принял, ну тогда достаточно получить общую неисправность (например через реле) и пойти посмотреть журнал на HUB.
Хорошо, топик и его название не имеет значение, главное чтобы он передавал состояние датчика как в режиме охраны так и без охраны.
Хорошо, можно выписать несколько значения, это может быт не обязательно 0/1, но и другие цифры но они должны быть постоянными, те определенная цифра в шаблоне можно прописать что является - вскрытием корпуса, еще одна управление звуком приборов (если их оттуда можно забрать)
в УД работает по похожему принципу, ему насколько знаю не важно стоит в охране или нету, ему важно только состояние датчика дым, если оно сработало будет тревога вне зависимости от настроек охраны. Так что думаю в УД эти статусы для пожарки не актуальны.
Да отлично, alarm здесь передает ведь всегда состояние датчика вне зависимости от режимов работы, охраны и тд (те пример как в uprog я включаю АЦП и вижу всегда его состояние) ?
Его я бы оставил как есть, пусть будет просто контактным датчиком, в УД можно создать отдельно виртуальное устройство и завести туда все что угодно и привязать в какому угодно сценарию. Мы делаем шаблон для основных функций чтобы пользователь мог его загрузить и сразу пользоваться, а все кастомизации уже можно потом через контактный датчик прицепить.
Вот здесь как раз важный момент о котором писал выше по /pp/zone/alarm, нужно получать статус с датчиков в любом режиме работы, а каким образом или через какой топик сделать не так важно. Для УД достаточно разделов с охраной и состояния с датчиков.
Вообще для УД по сути не важно сколько разделов и охранных программ заведено, если хотя бы одна из них находится в охране и сработает при этом датчик абсолютно любой, даже не связанный с Болид - он выдаст тревогу. Я попробую протестировать отдельно по комнатам разнести их, может он будет брать в охрану только те датчики что с ним в одной комнате, тогда это хоть как-то решит проблему.
Поэтому делать каждый шлейф - охраной нет смысла (мы можем только забрать с них состояния, ошибки и тд и поместить в характеристики и по ним уже делать авматизации), тогда в УД будет десятки охранных программ, толку от них будет мало тк выдать тревогу сможет совершенно любой датчик в УД.
Если другими вариантами не получится взять состояние датчика в снятом с охраны режиме, то можно выделить в отедельный топик и также разделить их по типу как вы делали выше (те в самом названии топика выдавать в пути его тип).
Здесь нельзя из группы вычитывать какие разделы входят и также брать все шлейфа всех разделов ? К примеру у меня группа разделов Дом в который входят все разделы, собственно эта группа и является основной при поставке на охрану или снятия через считыватель. в УД также есть смысл делать одну общую охранку и все датчики уже ей подчиняются.
У считывателя с приборов - нету состояний для передачи в УД?
