MajorDoMo

Ну что, поехали. Ось Windows XP 32.
Для построения сети Z-Wave был использован вот такой стик
Изображение

А интересно можно ли стик склонировать, чтоб поэксперементировать?

sergejey писал(а):можно ли стик склонировать

Да вот наврятли. Конечно не боги горшки обжигали, но думаю что в данном случае от покупки не уйти. Даже если повторить железо, без прошивки никуда. А она, наверное, вовсе не открытая. Но в инете цены сильно отличаются. Если ничего не напутали, то получается от 2 до 5 килорублей. Так то Z-Wave оборудование вообще ну очень дорогое. За идею что ли цена так завышена... Но поиграться то хочется

sergejey писал(а):так что если будут проблемы, будем решать совместно

А так и придется. Я пока в этом направлении мало что знаю, но капать могу долго и усердно Перед обзором на следующее железо, все же придется немного разобрать тему использования данных датчиков Z-Wave в MDM. Сейчас у меня для теста создан отдельный класс. В нем объект датчика движения с его свойствами.


И, внимание, при изменении свойства Level запускается метод LevelChanged


Код метода


Все упрощено до безобразия, чтобы было проще понять и разобраться. А что нам вообще нужно? Нам нужно во первых наличие в MDM объекта с текущими свойствами датчика. Это есть. И во вторых - сигнал о изменении свойства объекта, чтобы запустить свои цепочки проверок и действий. С этим пока грабли. Ближе к делу: Линкуем свойства объекта датчика и смотрим что будет. Помним, что при изменении свойства Level запустится наш метод LevelChanged.


Теперь немного опытов и теории: Замечено, что датчик присылает одновременно все свои свойства. То есть, при движении он так же обновляет свойство температуры и яркости. Также по задумке z-Wave датчик периодически просыпается (например каждые 5 минут) и сообщает свои свойства. Это весьма полезно для сбора таких параметров как температура и яркость освещения, но, одновременно с этим идет и обновление свойства движения. 0 будет обновлен на 0 если никого нет. Это как бы и ничего, но все равно вызовет срабатывание метода LevelChanged. А вот это уже нехорошо. Конечно можно создавать свойства и хранить там предыдущее значение, но это вариант ходить домой через крышу. И еще одно наблюдение: Когда датчик замечает движение, я слышу сразу два уведомления подряд. Значит каким то образом статус обновляется два раза. А почему? Вероятно надо посмотреть на взаимодействие сервера Z-Wave и MDM.
Наверное теперь вопрос уже именно к Сергею.
1. Где это все происходит.
2. Есть ли какие то логи.
3. Смогу ли я сам там что то посмотреть или сделать
Понятно что на 3 Вы мне наврятли ответите. Но мне хотя бы в целом узнать, что там такое.
Так же я еще вообще смутно представляю понятие Ассоциации. Если управлять сетью только в Z-Wave сервере, то там, например, в выключателях можно указывать исполнительные устройства, которым будут отправляться команды. Но у некоторых устройств (например датчик температура+влажность), там я вижу эти раздельные свойства. А у датчика движения такого нет. НО! у них разные производители.
В общем, чтобы смело двигаться дальше, надо поточнее понять работу этого механизма получения данных. Пишите кто что знает. Кидайте действительно полезные ссылки. Будем собирать инфу.

Bagir писал(а):Наверное теперь вопрос уже именно к Сергею.
1. Где это все происходит.
2. Есть ли какие то логи.
3. Смогу ли я сам там что то посмотреть или сделать
Понятно что на 3 Вы мне наврятли ответите. Но мне хотя бы в целом узнать, что там такое.

1. Это происходит при опросе устройства. Если конкретно говорить о том, где идёт обновление связанного свойства, то это файл ./modules/zwave/zwave.class.php строки начиная с 535: теоретически код можно заменить на такой и тогда будет идти обновление только при изменении значения: но тут логическая проблема -- что если это периодический опрос температуры и важно знать какой она была на указанный момент, даже если она не изменилась? собственно поэтому и указанный метод вызывается при каждой установке свойства, даже если само значение не изменилось. как вариант, в самом методе проверять совпадает ли новое значение с предыдущем и только при отличии производить какие-то действия

2. логов работы zwave не ведётся, можно только через xray смотреть последние вызовы метода или добавлять что-то в лог через debmes и через тот же xray его смотреть.

3. всё в ваших руках ))

Bagir писал(а):Так же я еще вообще смутно представляю понятие Ассоциации. Если управлять сетью только в Z-Wave сервере, то там, например, в выключателях можно указывать исполнительные устройства, которым будут отправляться команды. Но у некоторых устройств (например датчик температура+влажность), там я вижу эти раздельные свойства. А у датчика движения такого нет. НО! у них разные производители.
В общем, чтобы смело двигаться дальше, надо поточнее понять работу этого механизма получения данных. Пишите кто что знает. Кидайте действительно полезные ссылки. Будем собирать инфу.

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

Ассоциация нужна для привязки устройств друг к другу. Например Выключатель, датчик движения <-> лампочка, реле, итд

Очень нужная функция и МД тут не причём. Кстати она убирает многие проблемы. Например: Выключенный сервер, ускоряет работу (т.к. не нужно обрабатывать через скрипты). Также там есть понятие GlobalEvant, он нужен например когда у вас сработает датчик протечки воды. Будут срабатывать силовые блоки на мигание (Мигают все лампочки). А также срабатывает сирена.

Bagir посмотрите пожалуйста личку

sergejey писал(а):Это происходит при опросе устройства. Если конкретно говорить о том, где идёт обновление связанного свойства, то это файл ./modules/zwave/zwave.class.php строки начиная с 535:

Вот спасибо! php файл, ну тут то можно и по мучатся.

sergejey писал(а):но тут логическая проблема

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

У меня тоже на Fibaro Dimer были глюки по включению. То есть приходило в систему значение включения, а потом выключения - при нажатии включения. Всё списывал на глючный димер.

Пока не пользуюсь ZWave - т.к. димер совсем сгорел.
Вот думаю продолжать ZWave или смотреть в сторону Noolite

Я еще при выборе Z на этот пульт повелся http://rus.z-wave.me/manuals/show?sku=ZMR_KFOB
Вот только пока не знаю как его с MDM использовать. А точнее даже не смотрел толком. В сети его зарегистрировал, но в MDM вижу только состояние его батарейки. В выходные доберусь до него.

Долго думал, как все же быть в MDM с объектами для Z устройств. Тут надо учесть, что как правило, в Z устройстве сразу по 2-4 разных датчика + статус батареи. Но в то же время хотелось бы сохранить идеологию, когда для каждого датчика есть свой объект в соответствующем классе. Это удобно, т.к. позволяет легко переключиться на другое железо не перетряхая горы кода. Но если расщепить Z устройство на объекты его разных датчиков, то как быть с батареей? Создать еще объект под название "просто батарейка"? Ну как то мне так не нравится...
Еще надо учесть, что при срабатывании по событию, и/или по времени, Z устройство обновляет в MDM сразу ВСЕ свои статусы и данные. Такое обновление данных, даже если они не изменялись, очень нужно, например для снятия температуры, но совершенно бесполезно, например для статуса движения или открытия двери. Более того, это обновление данных запустит проверку наших условий и реакцию на изменение, а нам это не нужно. В этом случае нам нужна реакция только на изменения данных.
Можно нахудожничать в файле zwave.class.php, сделав изменения под свои разные задачи. Но это заведомо узкая и темная тропинка. Мое мнение - код MDM должен оставаться как можно менее измененным, чтобы потом разные участники форума не сравнивали посудомойку со стиральной машиной.
Как уйти от всех заморочек, не трогать код в файле и оставить объекты в стандартных классах?
Пока что я нашел только одно решение. Создать новый общий связующий класс zWave. В него добавить объекты, по одному на каждое Z устройство. Свойства класса zWave продумать так, чтобы из них можно было набрать ассортимент на любое Z устройство. Теперь о реакции на изменение. Т.к. Z устройства обновляют сразу все свои данные, надо выбрать самое распространенное свойство и по его изменению запускать метод класса, например IncomingData. В этом методе мы уже будем указывать, какому объекту, что, и при каких условиях передавать. Например, свойство температуры всегда отправлять в объект класса tempSensors. А вот движение отправлять в inhouseMovementSensors только при его изменении. Причем нам будет чего и с чем сравнить!, для принятия этого решения. Осталось выбрать свойство, по которому запускать метод. Я выберу Батарейку. Она есть у всех моих устройств. А для исполнительных устройств можно продублировать на свойство статуса.
Зацените идею, и если это полный бред, пишите сразу.

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

Да, такой и есть план. Класс zWave объект Glaz_1 (датчик движения). У него все свойства, которые есть у Z датчика. А при изменении свойства батарейки, запускается привязанный метод IncomingData. Он и раздает данные объектам датчиков других классов. Пока нравится.