Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 37
Ну теперь то OpenZWave разгуляется!
И можно со сканером по подъездам ходить.
Прошу прощения, а можно для обывателя рассказать, чем это «грозит»?
Судя по последним абзацам — особо ничем?
Судя по последним абзацам — особо ничем?
Почему же? Из последнего абзаца следует, что сделать свой стек Z-Wave Вы не сможете, обойдя Сигму.
Но открытие протокола верхнего уровня в добавок к уже открытым двум нижним приведёт к улучшению качества ПО и устройств, к большей конкуренции, а значит хорошо для конечного пользователя. Кроме того Сигма потихоньку снимает клеймо «проприетарный» с Z-Wave, что тоже способствует популярности. В конце концов, какой он проприетарный, если 350 компаний по всему миру сделали более 1500 уникальных устройств?!
Но открытие протокола верхнего уровня в добавок к уже открытым двум нижним приведёт к улучшению качества ПО и устройств, к большей конкуренции, а значит хорошо для конечного пользователя. Кроме того Сигма потихоньку снимает клеймо «проприетарный» с Z-Wave, что тоже способствует популярности. В конце концов, какой он проприетарный, если 350 компаний по всему миру сделали более 1500 уникальных устройств?!
Я очень жду теперь хорошей реализации контроллера Z-Wave для OpenHAB. Особенно нормального конфигуратора
Разрабы поняли, что безнадежно проигрывают новым спецификациям блютуза, и последними конвульсивными усилиями пытаются оживить труп.
Рассмешили. Где же умные розетки Bluetooth, которые похоронят Z-wave?
Боюсь, что ваша желочь безосновательна. Покажите мне хоть 5 устройств для умного дома на BTLE. А я вам покажу тысячу на Z-Wave. BT и Z-Wave очень разные технологии и пока не могут конкурировать, находясь в разных сферах. Физика не даёт им пока схлестнуться.
Что-то не увидел открытия SerialAPI, а это основа для реализации контроллера… непойму какой смысл его вообще скрывать…
Вы правы, эту часть не открыли. Открыли формат команд, передаваемых между устройствами.
А SerialAPI — это фактически доступ к API SDK. Это не открывали. Да оно вам и не нужно. Для реализации контроллера достаточно уметь использовать SendData, а внутри передавать те самые открытые команды. Можете взять Z-Way и поиграться — там можно напрямую SendData использовать и слать любую последовательность.
А SerialAPI — это фактически доступ к API SDK. Это не открывали. Да оно вам и не нужно. Для реализации контроллера достаточно уметь использовать SendData, а внутри передавать те самые открытые команды. Можете взять Z-Way и поиграться — там можно напрямую SendData использовать и слать любую последовательность.
Что такое SendData? Функция в Z-Way? Так я за пару вечеров написал код для приема/отправки пакетов, подтверждения получения, парсер полученных функций. Теперь надо реализовывать сам разбор байтов. В OpenZWave куча хаков, со снифом много отличий, вообще работы куча…
Много чего нужно, чего не открыли. Интереснее SerialAPI, т.к. те кому интересен обмен между устройствами имеет доступ к SDK, что бы разрабатывать это самое устройство :)
Вот хотя бы параметры для FUNC_ID_ZW_ADD_NODE_TO_NETWORK, что значат эти параметры?
ADD_NODE_UNK_1 = 0x40;
ADD_NODE_UNK_2 = 0x80;
Никто дальше OpenZWave я так понимаю не продвинулся в реверсе SerialAPI?
Z-Way на Windows у меня виснет при добавлении первого устройства.
Приходится снифать трафик HomeSeer, я так понимаю у них есть SDK.
Пришла еще Z-Uno, крутая штука, возможно с ней будет проще отлаживать обработку классов команд.
Много чего нужно, чего не открыли. Интереснее SerialAPI, т.к. те кому интересен обмен между устройствами имеет доступ к SDK, что бы разрабатывать это самое устройство :)
Вот хотя бы параметры для FUNC_ID_ZW_ADD_NODE_TO_NETWORK, что значат эти параметры?
ADD_NODE_UNK_1 = 0x40;
ADD_NODE_UNK_2 = 0x80;
Никто дальше OpenZWave я так понимаю не продвинулся в реверсе SerialAPI?
Z-Way на Windows у меня виснет при добавлении первого устройства.
Приходится снифать трафик HomeSeer, я так понимаю у них есть SDK.
Пришла еще Z-Uno, крутая штука, возможно с ней будет проще отлаживать обработку классов команд.
Честно, не очень ясно, зачем реверсить SerialAPI, если есть готовые движки: OZW, Z-Way, родной Z-Ware от Sigma (он для малинки есть — бесплатно!). Хотя если вам нравится Z-Uno, то Z-Way в духе — тоже понравится.
Если речь о платности, то стоимость вашего времени точно зашкалит. Для забавы — да, весело — мы так тоже Z-Way начинали писать ;)
Если речь о платности, то стоимость вашего времени точно зашкалит. Для забавы — да, весело — мы так тоже Z-Way начинали писать ;)
Честно говоря я не думаю, что есть смысл открывать serial API. Вроде как все идет к тому, что обмен будет осуществляться через TCP/IP — Z-Wave over IP — то есть сеть, а не последовательный протокол.
А сам Z-wave контроллер превратится из USB стика в IP — коробку, к которой можно обращаться через сеть Internet.
Это я так понял саму концепцию.
То есть разрабатывать дрова для последовательного порта больше нет смысла.
А сам Z-wave контроллер превратится из USB стика в IP — коробку, к которой можно обращаться через сеть Internet.
Это я так понял саму концепцию.
То есть разрабатывать дрова для последовательного порта больше нет смысла.
Это не совсем так. Действительно ZIPR — это преобразователь Z-Wave <-> TCP/IP. В то время как стик — это Z-Wave <-> COM-порт. Но и со вторым способом можно использовать USB удлинитель по TCP/IP (есть такие проги, по UDP пробрасывают). Думаю, будущее за SerialAPI всё таки, т.к. он удобней для работы локально, а конверторы а облако будут разными.
Так IP интерфейс по сути обертка для SerialAPI.
Открывать нужно для того, что бы можно было свободно реализовывать контроллеры на основе сертифицированных USB-стиков. Ну не нужно мне железо, я хочу только софт писать используя железо которое делают другие.
PoltoS а зачем вы создали свой Z-Way если есть готовые движки? Меня вот не устраивают готовые по разным параметрам — платности, неработоспособностью не различных платформах, глючностью, закрытостью кода и т.д.
Вот к примеру хочу сделать в Arduino получение значения с датчиков и вывод на LCD экран.
Открывать нужно для того, что бы можно было свободно реализовывать контроллеры на основе сертифицированных USB-стиков. Ну не нужно мне железо, я хочу только софт писать используя железо которое делают другие.
PoltoS а зачем вы создали свой Z-Way если есть готовые движки? Меня вот не устраивают готовые по разным параметрам — платности, неработоспособностью не различных платформах, глючностью, закрытостью кода и т.д.
Вот к примеру хочу сделать в Arduino получение значения с датчиков и вывод на LCD экран.
А вам чтоб реализовывать движок на SerialAPI нужно иметь SDK и проходить сертификации. Т.е. в любом случае придётся платить за членство в Альянсе и прочее. Но для разработчиков это копейки на фоне оплаты программистов.
Мы писали свой Z-Way 7 лет назад. С тех пор это один из самых продвинутых движков. Писали, т.к. альтернатив не было. Прошлая версия (когда-то была на Питоне) была вдохновлена проектом Linux MCE (хотя писали всё с нуля, т.к. там код был то ещё Г). Из того же Linux MCE берёт начало OpenZWave. Мы одновременно начинали.
Мы писали свой Z-Way 7 лет назад. С тех пор это один из самых продвинутых движков. Писали, т.к. альтернатив не было. Прошлая версия (когда-то была на Питоне) была вдохновлена проектом Linux MCE (хотя писали всё с нуля, т.к. там код был то ещё Г). Из того же Linux MCE берёт начало OpenZWave. Мы одновременно начинали.
Мне что бы реализовать движок на SerialAPI нужны только образцы устройств и время.
Да, его требуется несколько больше, чем имея документацию.
Никто не говорит о 100% реализации Z-Wave протокола.
Добавление/удаление нод, получение информации с датчиков (бинарный, аларм, мультилевел), отправка команд реле и диммеру (свитч бинарный и мультилевел) уже сделал. Да, есть непонятные поля, но они не критичны, прекрасно работает и без них.
Но видя ситуацию с поддержкой разных сертифицированных!!! устройств в различных контроллерах становится грустно. Даже имея доступ к SDK не получается сделать что бы работало все и из коробки.
Ваш OZW смотрел, он по сути и вдохновил на написание своего кода, т.к. он у меня не смог полноценно добавить ноду, т.к. не проводится интервью.
Да, его требуется несколько больше, чем имея документацию.
Никто не говорит о 100% реализации Z-Wave протокола.
Добавление/удаление нод, получение информации с датчиков (бинарный, аларм, мультилевел), отправка команд реле и диммеру (свитч бинарный и мультилевел) уже сделал. Да, есть непонятные поля, но они не критичны, прекрасно работает и без них.
Но видя ситуацию с поддержкой разных сертифицированных!!! устройств в различных контроллерах становится грустно. Даже имея доступ к SDK не получается сделать что бы работало все и из коробки.
Ваш OZW смотрел, он по сути и вдохновил на написание своего кода, т.к. он у меня не смог полноценно добавить ноду, т.к. не проводится интервью.
OZW не наш.
Отвечу кратко. Мы от многих слышим: «ой как дорого, да мы за месяц сами напишем». Через неделю слышим «почти всё готово — уже розетки и датчики работают». А дальше это «почти всё» занимает год-два на допиливание и тестирование. И это у всех так.
Хороший софт сделать сложно, т.к. протокол очень обширный. И да, для поддержки как новых, так и старых устройств нужно оооочень обо многом подумать — разные версии учесть.
Но я так и не смог понять, зачем частному лицу тратить время на написание своей имплементации SerialAPI, если есть готовые, да ещё и за смешные деньги < 10к₽ (ну, не говорим об удовольствии, которое вы получаете, вновь изобретая колесо).
Отвечу кратко. Мы от многих слышим: «ой как дорого, да мы за месяц сами напишем». Через неделю слышим «почти всё готово — уже розетки и датчики работают». А дальше это «почти всё» занимает год-два на допиливание и тестирование. И это у всех так.
Хороший софт сделать сложно, т.к. протокол очень обширный. И да, для поддержки как новых, так и старых устройств нужно оооочень обо многом подумать — разные версии учесть.
Но я так и не смог понять, зачем частному лицу тратить время на написание своей имплементации SerialAPI, если есть готовые, да ещё и за смешные деньги < 10к₽ (ну, не говорим об удовольствии, которое вы получаете, вновь изобретая колесо).
Имел ввиду AZW конечно же.
Охотно верю, функций в протоколе достаточно много. Но и цели реализовать полную поддержку нет.
На данный момент именно удовольствие движет процессом :)
Охотно верю, функций в протоколе достаточно много. Но и цели реализовать полную поддержку нет.
На данный момент именно удовольствие движет процессом :)
Оооо, AZW — это же прапрапрадед Z-Way ;) Не модульный вообще… Это был proof of concept, проект моего хобби — автоматизировал себе жильё.
Скоро всё упростится — обязательное шифрование S2 сделает такие самоделки бессмысленными. Слишком сложно будет имплементировать S2, а без него не будет смысла. Ведь никто не делает собственные дрова для WiFi, например.
Скоро всё упростится — обязательное шифрование S2 сделает такие самоделки бессмысленными. Слишком сложно будет имплементировать S2, а без него не будет смысла. Ведь никто не делает собственные дрова для WiFi, например.
в OpenZWave вроде есть поддержка шифрования.
S2 — новый вид, который будет обязательным. Плюс он намного сложней с точки зрения реализации. Честно говоря, я даже доку не смог долистать — тоска взяла. А ведь нам его до апреля реализовать нужно… S2 хоть и открытый, но такого уровня сложности проекты уже сложно делать на уровне хобби без коммерческого заказа. У OpenZWave именно с этой частью сложности. Ими многие в мелких проектах пользуются, но серьёзного коммерческого я пока ничего не видел.
Охотно верю, функций в протоколе достаточно много. Но и цели реализовать полную поддержку нет.
Интересно, кому, кроме вас, будет интересен такой урезанный драйвер?
А как в Z-Wave вообще различать несколько сенсоров на одном устройстве?
К примеру Датчик движения от Fibaro, там есть датчик температуры и освещенность.
Так вот от них приходят COMMAND_CLASS_SENSOR_MULTILEVEL со значением температуры и освещенности.
И как их значение привязать к отдельным переменным? Тут хоть можно по типу датчика понять где что.
Но ведь есть устройства, где несколько однотипных датчиков. Как тогда различать где значения какого?
К примеру Датчик движения от Fibaro, там есть датчик температуры и освещенность.
Так вот от них приходят COMMAND_CLASS_SENSOR_MULTILEVEL со значением температуры и освещенности.
И как их значение привязать к отдельным переменным? Тут хоть можно по типу датчика понять где что.
Но ведь есть устройства, где несколько однотипных датчиков. Как тогда различать где значения какого?
Там есть разные sensor types. У меня, например, есть датчик Aeon 5-в-1. Там кроме датчика движения есть еще датчик температуры, влажности, освещенности, заряд батареи. Все они класса Multilevel.
В итоге в OpenHAB прописывается нужный тип и он сам распихивает значения по переменным
В итоге в OpenHAB прописывается нужный тип и он сам распихивает значения по переменным
Number sensor_1_temp "Temperature [%.1f °F]" {zwave="2:command=sensor_multilevel,sensor_type=1"}
Number sensor_1_humidity "Humidity [%.0f %%]" {zwave="2:command=sensor_multilevel,sensor_type=5"}
Number sensor_1_luminance "Luminance [%.0f Lux]" {zwave="2:command=sensor_multilevel,sensor_type=3"}
Contact sensor_1_motion "sensor [MAP(motion.map):%s]" {zwave="2:command=sensor_binary,respond_to_basic=true"}
Number sensor_1_battery "Battery [%s %%]" {zwave="2:command=battery"}
Я про тип сенсора написал, речь о том, когда несколько сенсоров одного типа на устройстве…
Они все одного типа: sensor_multilevel. Но есть еще один атрибут, по которому их и различают в драйвере.
Какой атрибут? SensorType у обоих датчиков температуры будет = 0x01. Как же их различить?
Дам авторитетный ответ ;)
Когда-то в SensorMultilevel можно было возвращать только одно значение. Если хочется несколько, то нужно было делать каналы через MultiChannel. Начиная с версии SensorMultilevel V5 добавили возможность возвращать несколько видов сенсоров (разных!) через один класс (без каналов). Это сильно упростило программирование мултисенсоров.
Однако для реализации нескольких одинаковых типов датчиков (например, температуры) всё как и прежде — несколько каналов.
Как классический пример канально-ориентированного датчика — Z-Uno — один канал = один тип. Это сильно упрощает понимание. Например, даже для датчиков температуры + влажность в Z-Uno создаётся два канала с Sensor Multilevel в каждом. Хотя и можно было запихнуть в один. Но вот для нескольких температурных точно придётся разносить по каналам.
Когда-то в SensorMultilevel можно было возвращать только одно значение. Если хочется несколько, то нужно было делать каналы через MultiChannel. Начиная с версии SensorMultilevel V5 добавили возможность возвращать несколько видов сенсоров (разных!) через один класс (без каналов). Это сильно упростило программирование мултисенсоров.
Однако для реализации нескольких одинаковых типов датчиков (например, температуры) всё как и прежде — несколько каналов.
Как классический пример канально-ориентированного датчика — Z-Uno — один канал = один тип. Это сильно упрощает понимание. Например, даже для датчиков температуры + влажность в Z-Uno создаётся два канала с Sensor Multilevel в каждом. Хотя и можно было запихнуть в один. Но вот для нескольких температурных точно придётся разносить по каналам.
Спасибо, как раз только запустил Z-Uno, оказывается она только под старую Ардуину, а на более новых версиях не работает :(
Вообщем так и увидел, даже 1 температурный SensorMultilevel шлется в классе MultiChannel.
Я так понимаю можно до 10 каналов использовать.
Вообщем так и увидел, даже 1 температурный SensorMultilevel шлется в классе MultiChannel.
Я так понимаю можно до 10 каналов использовать.
Да, Z-Uno поддерживает до 10 каналов.
Поддержку более новых Arduino IDE будем делать в новом году
Поддержку более новых Arduino IDE будем делать в новом году
К сожалению на вашем форуме зарегистрироваться не могу, пишу тут:
что-то сломалось в 2.1.3 версии и перестал работать MultiChannel, соответственно, при наличии нескольких каналов с одинаковым типом контроллеру приходят результаты только первого такого канала :(
Опция MultiChannel в меню конечно включена. В файле описания платы есть описка, но ее исправление не повлияло на работу. Сброс NVM не помог.
что-то сломалось в 2.1.3 версии и перестал работать MultiChannel, соответственно, при наличии нескольких каналов с одинаковым типом контроллеру приходят результаты только первого такого канала :(
Опция MultiChannel в меню конечно включена. В файле описания платы есть описка, но ее исправление не повлияло на работу. Сброс NVM не помог.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Протокол Z-Wave становится открытым