Протокол Z-Wave становится открытым

    Недавно были опубликованы в открытом доступе спецификации протокола Z-Wave, одного из самых популярных протоколов в домашней автоматизации. Нет, это не утечка, а осознанный шаг компании Sigma Designs, владельца протокола Z-Wave. На сегодняшний день Z-Wave используется внутри десятков миллионов умных домов, и открытие спецификации стандарта явно пойдёт на пользу популярности Z-Wave.



    В нашей старой статье мы описывали, как протокол Z-Wave раскладывается на модель уровней OSI. Ещё в 2012 года физический и канальный уровни протокола Z-Wave вошли в стандарт Международного Союза Электросвязи под ITU-T G.9959. Эти уровни отвечают непосредственно за передачу данных по радио эфиру, описывают используемые частоты, способы кодирования и адресации. Однако, все уровни выше оставались закрытыми, для получения доступа к документации было необходимо подписывать соглашение о неразглашении и покупать комплект разработчика. Нередко это становилось препятствием для компаний, которые планировали делать собственное ПО для управления устройствами Z-Wave (т.е. им даже кит разработчика не был нужен).

    Например, такие известные проекты как OpenZWave или OpenHAB (точнее его Z-Wave биндиг) были основаны на реверс-инжиниринге протокола Z-Wave, а не на спецификации. Это, конечно, приводило к кривым или неполным имплементациям.

    Кроме того пользователи не могли понять, кого винить в неверной работе устройства с контроллером: производителя устройства или производителя контроллера. В логи посмотреть можно, но разобрать их и понять, соответствует ли пакет из логов спецификации или нет, было невозможно.

    Теперь всё изменилось! Любой может свериться с официальной спецификацией и даже внести свои предложения и замечания. Открытие спецификации Z-Wave — это сильная заявка протокола на доминирование в сфере домашней автоматизации и Internet of Things. Возможно, Z-Wave таки станет универсальным языком взаимодействия для умных устройств и приложений в домохозяйствах.

    Но вернёмся к реалиям. Что же нам тут Sigma Designs опубликовали?


    Были полностью открыты все описания Классов Команд (Command Class), а так же описания Классов Устройств (Device Class). Первые описывают, как формируется каждая отдельная команда, какой байт и бит в пакете данных что означает, как его интерпретировать. Вторые описывают специфику интерпретации некоторых Классов Команд в зависимости от типа устройства. Например, класс Switch Multilevel для диммера — это яркость, а для устройства управления жалюзи — это положение ламелей. Фактически, это полное описание языка общения между устройствами и «фразеологизмов». Это и есть самое интересное из всего опубликованного.

    Открытая спецификация включает в себя описание недавно анонсированного нового уровня шифрования в Z-Wave, названного S2. Этот уровень превосходит используемый повсеместно на данный момент (его теперь называют S0) как по производительности, так и по безопасности.

    Кроме того были открыты описания Z/IP (Z-Wave over IP) — надстройки поверх TCP/IP для передачи пакетов Z-Wave. Z/IP позволяет заворачивать пакеты Z-Wave в TCP или UDP с последующей передачей и анализом на облачном сервере. Поверх Z/IP был сделан Z-Ware — middleware, предоставляющий более высокий уровень абстракции над Z-Wave. На практике что Z/IP, что Z-Ware никто особо не использовал. Все популярные контроллеры: RaZberry/Z-Way, Fibaro, Vera, OpenHAB, Domoticz имеют собственные уровни абстракции и API для работы по HTTP (т.е. поверх TCP/IP). Т.е. здесь мы увы ничего особо интересного не получили.

    Всё это доступно на специальном сайте zwavepublic.com

    Отметим, что всё это не отменяет необходимости как и прежде сертифицировать каждое новое устройство Z-Wave для проверки соответствия протоколу и совместимости с другими устройствами. Более того, новые средства автоматического тестирования стали более строгими и разносторонними.

    Зачем Sigma Designs это сделали?


    Ну, очевидно, все давно этого просили. Закрытие протокола — не самая хорошая идея по многим причинам.

    Безопасность
    Сокрытие лишь увеличивает количество дыр, уменьшая количество глаз, проверивших спеки и код. Открытие протокола Z-Wave — признак зрелости схем безопасности протокола.

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

    Многофункциональность
    Зная о доступных в протоколе «фишках», пользователи будут призывать производителей делать «продвинутые» устройства.

    В конце концов, Sigma Designs зарабатывает на продаже чипов и лицензии, заложенной в его стоимости, и лишнее ограничение на «вход в технологию» явно не способствует продажам. Странно, что решение это зрело так долго.

    Наверняка ведь что-то утаили?


    Ага, утаили ;)

    Увы, в открытый доступ не попали сетевой и транспортный уровни, описывающие маршрутизацию, ретрансляции, подтверждения. Именно эти уровни покрыты множеством патентов Sigma Designs и обеспечивают стабильность работы больших сетей Z-Wave.

    Уверен, случившееся открытие большей части протокола приведёт к популяризации Z-Wave во всём мире.

    » Оригинальная новость тут.
    Поделиться публикацией
    Комментарии 37
      0

      Ну теперь то OpenZWave разгуляется!

        0
        Верно. скорее всего разработчики OZW, как и команда OpenHAB перепишут свои куски «с нуля».
        +1
        И можно со сканером по подъездам ходить.
          0
          А это и ранее можно было делать ;) К тому же базовые команды уже давно были известны — см. всё тот же Open Z-Wave, например. Хотя теперь это сложнее — всё больше и больше устройств с шифрованием.
          0
          Прошу прощения, а можно для обывателя рассказать, чем это «грозит»?
          Судя по последним абзацам — особо ничем?
            0
            Почему же? Из последнего абзаца следует, что сделать свой стек Z-Wave Вы не сможете, обойдя Сигму.

            Но открытие протокола верхнего уровня в добавок к уже открытым двум нижним приведёт к улучшению качества ПО и устройств, к большей конкуренции, а значит хорошо для конечного пользователя. Кроме того Сигма потихоньку снимает клеймо «проприетарный» с Z-Wave, что тоже способствует популярности. В конце концов, какой он проприетарный, если 350 компаний по всему миру сделали более 1500 уникальных устройств?!
            0
            Я очень жду теперь хорошей реализации контроллера Z-Wave для OpenHAB. Особенно нормального конфигуратора
              +1
              Встречался в сентябре с одним из главных разрабов OpenHAB. Они планируют теперь радикально переписать весь биндинг Z-Wave, добавив сразу S2. Хотя это займёт много времени. Пока у них и шифрования даже нет. В этом OpenHAB сильно отстает.
              –1
              Разрабы поняли, что безнадежно проигрывают новым спецификациям блютуза, и последними конвульсивными усилиями пытаются оживить труп.
                +1
                Рассмешили. Где же умные розетки Bluetooth, которые похоронят Z-wave?
                  0
                  Боюсь, что ваша желочь безосновательна. Покажите мне хоть 5 устройств для умного дома на BTLE. А я вам покажу тысячу на Z-Wave. BT и Z-Wave очень разные технологии и пока не могут конкурировать, находясь в разных сферах. Физика не даёт им пока схлестнуться.
                  +1
                  Что-то не увидел открытия SerialAPI, а это основа для реализации контроллера… непойму какой смысл его вообще скрывать…
                    –1
                    Вы правы, эту часть не открыли. Открыли формат команд, передаваемых между устройствами.

                    А SerialAPI — это фактически доступ к API SDK. Это не открывали. Да оно вам и не нужно. Для реализации контроллера достаточно уметь использовать SendData, а внутри передавать те самые открытые команды. Можете взять Z-Way и поиграться — там можно напрямую SendData использовать и слать любую последовательность.
                      +1
                      Что такое 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, крутая штука, возможно с ней будет проще отлаживать обработку классов команд.
                        –1
                        Честно, не очень ясно, зачем реверсить SerialAPI, если есть готовые движки: OZW, Z-Way, родной Z-Ware от Sigma (он для малинки есть — бесплатно!). Хотя если вам нравится Z-Uno, то Z-Way в духе — тоже понравится.

                        Если речь о платности, то стоимость вашего времени точно зашкалит. Для забавы — да, весело — мы так тоже Z-Way начинали писать ;)
                          0
                          Честно говоря я не думаю, что есть смысл открывать serial API. Вроде как все идет к тому, что обмен будет осуществляться через TCP/IP — Z-Wave over IP — то есть сеть, а не последовательный протокол.
                          А сам Z-wave контроллер превратится из USB стика в IP — коробку, к которой можно обращаться через сеть Internet.
                          Это я так понял саму концепцию.
                          То есть разрабатывать дрова для последовательного порта больше нет смысла.
                            0
                            Это не совсем так. Действительно ZIPR — это преобразователь Z-Wave <-> TCP/IP. В то время как стик — это Z-Wave <-> COM-порт. Но и со вторым способом можно использовать USB удлинитель по TCP/IP (есть такие проги, по UDP пробрасывают). Думаю, будущее за SerialAPI всё таки, т.к. он удобней для работы локально, а конверторы а облако будут разными.
                              0
                              Так IP интерфейс по сути обертка для SerialAPI.
                              Открывать нужно для того, что бы можно было свободно реализовывать контроллеры на основе сертифицированных USB-стиков. Ну не нужно мне железо, я хочу только софт писать используя железо которое делают другие.

                              PoltoS а зачем вы создали свой Z-Way если есть готовые движки? Меня вот не устраивают готовые по разным параметрам — платности, неработоспособностью не различных платформах, глючностью, закрытостью кода и т.д.

                              Вот к примеру хочу сделать в Arduino получение значения с датчиков и вывод на LCD экран.
                                0
                                А вам чтоб реализовывать движок на SerialAPI нужно иметь SDK и проходить сертификации. Т.е. в любом случае придётся платить за членство в Альянсе и прочее. Но для разработчиков это копейки на фоне оплаты программистов.

                                Мы писали свой Z-Way 7 лет назад. С тех пор это один из самых продвинутых движков. Писали, т.к. альтернатив не было. Прошлая версия (когда-то была на Питоне) была вдохновлена проектом Linux MCE (хотя писали всё с нуля, т.к. там код был то ещё Г). Из того же Linux MCE берёт начало OpenZWave. Мы одновременно начинали.
                                  0
                                  Мне что бы реализовать движок на SerialAPI нужны только образцы устройств и время.
                                  Да, его требуется несколько больше, чем имея документацию.
                                  Никто не говорит о 100% реализации Z-Wave протокола.
                                  Добавление/удаление нод, получение информации с датчиков (бинарный, аларм, мультилевел), отправка команд реле и диммеру (свитч бинарный и мультилевел) уже сделал. Да, есть непонятные поля, но они не критичны, прекрасно работает и без них.

                                  Но видя ситуацию с поддержкой разных сертифицированных!!! устройств в различных контроллерах становится грустно. Даже имея доступ к SDK не получается сделать что бы работало все и из коробки.

                                  Ваш OZW смотрел, он по сути и вдохновил на написание своего кода, т.к. он у меня не смог полноценно добавить ноду, т.к. не проводится интервью.
                                    0
                                    OZW не наш.

                                    Отвечу кратко. Мы от многих слышим: «ой как дорого, да мы за месяц сами напишем». Через неделю слышим «почти всё готово — уже розетки и датчики работают». А дальше это «почти всё» занимает год-два на допиливание и тестирование. И это у всех так.

                                    Хороший софт сделать сложно, т.к. протокол очень обширный. И да, для поддержки как новых, так и старых устройств нужно оооочень обо многом подумать — разные версии учесть.

                                    Но я так и не смог понять, зачем частному лицу тратить время на написание своей имплементации SerialAPI, если есть готовые, да ещё и за смешные деньги < 10к₽ (ну, не говорим об удовольствии, которое вы получаете, вновь изобретая колесо).
                                      0
                                      Имел ввиду AZW конечно же.

                                      Охотно верю, функций в протоколе достаточно много. Но и цели реализовать полную поддержку нет.

                                      На данный момент именно удовольствие движет процессом :)
                                        0
                                        Оооо, AZW — это же прапрапрадед Z-Way ;) Не модульный вообще… Это был proof of concept, проект моего хобби — автоматизировал себе жильё.

                                        Скоро всё упростится — обязательное шифрование S2 сделает такие самоделки бессмысленными. Слишком сложно будет имплементировать S2, а без него не будет смысла. Ведь никто не делает собственные дрова для WiFi, например.
                                          0
                                          в OpenZWave вроде есть поддержка шифрования.
                                            0
                                            S2 — новый вид, который будет обязательным. Плюс он намного сложней с точки зрения реализации. Честно говоря, я даже доку не смог долистать — тоска взяла. А ведь нам его до апреля реализовать нужно… S2 хоть и открытый, но такого уровня сложности проекты уже сложно делать на уровне хобби без коммерческого заказа. У OpenZWave именно с этой частью сложности. Ими многие в мелких проектах пользуются, но серьёзного коммерческого я пока ничего не видел.
                                          0
                                          Охотно верю, функций в протоколе достаточно много. Но и цели реализовать полную поддержку нет.

                                          Интересно, кому, кроме вас, будет интересен такой урезанный драйвер?
                                            0
                                            А я никому и не предлагаю :)
                        0
                        А как в Z-Wave вообще различать несколько сенсоров на одном устройстве?
                        К примеру Датчик движения от Fibaro, там есть датчик температуры и освещенность.
                        Так вот от них приходят COMMAND_CLASS_SENSOR_MULTILEVEL со значением температуры и освещенности.
                        И как их значение привязать к отдельным переменным? Тут хоть можно по типу датчика понять где что.
                        Но ведь есть устройства, где несколько однотипных датчиков. Как тогда различать где значения какого?
                          +1
                          Там есть разные sensor types. У меня, например, есть датчик Aeon 5-в-1. Там кроме датчика движения есть еще датчик температуры, влажности, освещенности, заряд батареи. Все они класса Multilevel.
                          В итоге в 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"}
                            0
                            Я про тип сенсора написал, речь о том, когда несколько сенсоров одного типа на устройстве…
                              0
                              Они все одного типа: sensor_multilevel. Но есть еще один атрибут, по которому их и различают в драйвере.
                                0
                                Какой атрибут? SensorType у обоих датчиков температуры будет = 0x01. Как же их различить?
                                  +1
                                  Дам авторитетный ответ ;)

                                  Когда-то в SensorMultilevel можно было возвращать только одно значение. Если хочется несколько, то нужно было делать каналы через MultiChannel. Начиная с версии SensorMultilevel V5 добавили возможность возвращать несколько видов сенсоров (разных!) через один класс (без каналов). Это сильно упростило программирование мултисенсоров.

                                  Однако для реализации нескольких одинаковых типов датчиков (например, температуры) всё как и прежде — несколько каналов.

                                  Как классический пример канально-ориентированного датчика — Z-Uno — один канал = один тип. Это сильно упрощает понимание. Например, даже для датчиков температуры + влажность в Z-Uno создаётся два канала с Sensor Multilevel в каждом. Хотя и можно было запихнуть в один. Но вот для нескольких температурных точно придётся разносить по каналам.
                                    0
                                    Спасибо, как раз только запустил Z-Uno, оказывается она только под старую Ардуину, а на более новых версиях не работает :(
                                    Вообщем так и увидел, даже 1 температурный SensorMultilevel шлется в классе MultiChannel.

                                    Я так понимаю можно до 10 каналов использовать.
                                      0
                                      Да, Z-Uno поддерживает до 10 каналов.

                                      Поддержку более новых Arduino IDE будем делать в новом году
                                        0
                                        К сожалению на вашем форуме зарегистрироваться не могу, пишу тут:
                                        что-то сломалось в 2.1.3 версии и перестал работать MultiChannel, соответственно, при наличии нескольких каналов с одинаковым типом контроллеру приходят результаты только первого такого канала :(

                                        Опция MultiChannel в меню конечно включена. В файле описания платы есть описка, но ее исправление не повлияло на работу. Сброс NVM не помог.
                                          0
                                          Поспешил с претензиями, все работает :)
                                          Оказывается для нужно немного по другому формировать список каналов для COMMAND_CLASS_MULTI_CHANNEL_ASSOCIATION :)

                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                        Самое читаемое