Комментарии 24
а для ZigBee такое есть?
Мы не делали. Да и не видели.
Есть XBee, но это именно шилд для Arduino. Мы же не хотели делать просто шилд — это не практично (особенно для устройств на батарейках). Z-Uno — автономное устройство, не требующее Arduino.
Кстати, из Z-Uno легко шилд сделать (с любым протоколом связи: UART, SPI, I2C,...), а вот наоборот — никак…
Есть XBee, но это именно шилд для Arduino. Мы же не хотели делать просто шилд — это не практично (особенно для устройств на батарейках). Z-Uno — автономное устройство, не требующее Arduino.
Кстати, из Z-Uno легко шилд сделать (с любым протоколом связи: UART, SPI, I2C,...), а вот наоборот — никак…
Я все про свое, можно сделать девайс в машину в OBD2 разъем и если Z-Uno видит в CAN шине, что 2 раза моргнули дальним светом, отправить по Z-Wave команду открыть ворота.
Я такое делал прямо в фаре — ставил туда датчик Fibaro Universal Sensor. Но это оказалось не очень удачным решением из-за сложности установки (питание брал из одного места, а с фары снимал «мигания») и температурных условий под капотом — провода не долго прожили.
Да, считывание по CAN было бы круче — нужно делать CAN адаптер по Z-Uno.
Да, считывание по CAN было бы круче — нужно делать CAN адаптер по Z-Uno.
Z-Uno дорогая очень. 57 евров против 12 за NodeMCU на немецком Амазоне. От чего такая цена складывается? Я бы использовал, но получается на той же NodeMCU я смогу за туже цену сделать 5 и более девайсов (если покупать в Китае по 2 евра).
Увидел раскладку по формированию цены в другом посте https://geektimes.ru/company/zwave/blog/268602/,
Но, что интересно, цена себе стоимостных затрат (оцененная в 19$) дальше чудесным образом для «распространения» продукта на рынке обозначилась уже в 60$ (в три раза больше)
Но, что интересно, цена себе стоимостных затрат (оцененная в 19$) дальше чудесным образом для «распространения» продукта на рынке обозначилась уже в 60$ (в три раза больше)
Все относительно, вы сравниваете с технологиями, где устройства нужно самому разработать. А Z-Uno все таки из мира профессиональных коммерческих систем автоматизации. И без Z-Uno например, интегрировать климатическую систему, или систему вентиляции может стоить 100000р, а с Z-Uno в 10000 можно уложиться.
Вот вот. Z-Uno не для любителей, потому, что дорого. Чем рисковать, покупать Z-Uno за дорого, которую я могу и убить в ходе эксперементов, я лучше куплю что то вроде ESP8266, сам напишу скетч или залью что то вроде DeviceHive и интегрирую в тот же Z-Way, благо это делается легко.
Крупные же производители железа могут позволить себе купить отладочные комплекты, которые у них уже возможно уже и есть и будут использовать лучше саму z-wave микросхему напрямую, а не втыкать в свое устройство Z-Uno со своей ненужной обвзякой.
Остаются только «штучные» заказы. Вроде добавить партии кондиционеров z-wave интерфейс. И забыть.
Крупные же производители железа могут позволить себе купить отладочные комплекты, которые у них уже возможно уже и есть и будут использовать лучше саму z-wave микросхему напрямую, а не втыкать в свое устройство Z-Uno со своей ненужной обвзякой.
Остаются только «штучные» заказы. Вроде добавить партии кондиционеров z-wave интерфейс. И забыть.
Z-Uno для множества пользователей, у кого уже есть большая сеть, и хочется дополнить её, включив нестандартный датчик. Ну, первую тысячу «штучных» мы продали ;) Так что дела идут неплохо.
Думаю, нет большого смысла обсуждать «дорого», «штучно»,… рынок всё покажет — в конечном счёте цена определяется спросом. Здесь же я о программировании писал, о подходе. А все опять закричали «Z-Wave — дорого».
Думаю, нет большого смысла обсуждать «дорого», «штучно»,… рынок всё покажет — в конечном счёте цена определяется спросом. Здесь же я о программировании писал, о подходе. А все опять закричали «Z-Wave — дорого».
Да тут чуда нет. Маржа (надо же себя мотивировать, платить сотрудникам), налоги (18% НДС + налоги с маржи), маржа каналу, который продаёт (это кстати почти 50% от розницы!), сертификации (знаете сколько FCC стоит? мы его подаём скоро).
Короче, собрать на коленках прототип — одно, а довести его до 1000 клиентов — совсем другое. А знаете себестоимость NodeMCU? ;)
Ну и главный ответ про цену — количество штук: чем популярней протокол, тем больше ожидаемые продажи, тем больше заказ, тем меньше цена.
И кстати, сам игрался в NodeMCU через год после её выхода — сырое и унылое г… для домашних игр. Лишь сейчас появляется стабильность, и то так себе. Мы же сразу стараемся вложиться в стабильный и качественный софт. Получилось ли, судить Вам.
Короче, собрать на коленках прототип — одно, а довести его до 1000 клиентов — совсем другое. А знаете себестоимость NodeMCU? ;)
Ну и главный ответ про цену — количество штук: чем популярней протокол, тем больше ожидаемые продажи, тем больше заказ, тем меньше цена.
И кстати, сам игрался в NodeMCU через год после её выхода — сырое и унылое г… для домашних игр. Лишь сейчас появляется стабильность, и то так себе. Мы же сразу стараемся вложиться в стабильный и качественный софт. Получилось ли, судить Вам.
Такого довольно много. Xbee c протоколами ZigBee, 802.15, DigiMesh. в версии Programmble там встроенный MCU на CodeWarrior программируется. Еще есть particle.io Photon c WiFi и Electron c 3G… живут месяцами на батарейках. При не частой передачи.
Фишка Z-Wave именно в совместимости с сотнями других устройств. В остальном мы не придумали что-то особенное.
Единственное, чем выделяется Z-Uno, о чём собственно и статья, — это подход к скрещиванию разных бинарных кодов и запуск на одном чипе. Я надеялся, программисты на Хабре смогут оценить идею и подход. Такого я не видел пока.
Единственное, чем выделяется Z-Uno, о чём собственно и статья, — это подход к скрещиванию разных бинарных кодов и запуск на одном чипе. Я надеялся, программисты на Хабре смогут оценить идею и подход. Такого я не видел пока.
Как я понимаю, z-wave — «дорогой и профессиональный»? Чем он принципиально лучше реализации с wifi на 8266? (не пинайте чайника, если что)
Я бы его не назвал дорогим. Посмотрите цены на KNX или даже на EnOcean, всё познаётся в сравнении.
Плюс Z-Wave в том, что устройства совместимы на уровне команд, а не просто сетевом уровне. С WiFi сложно управлять розеткой X с датчика Y. А в Z-Wave эта совместимость уже «из коробки». Ну и работа от батареек нормально реализована — на WiFi это всё криво.
Плюс Z-Wave в том, что устройства совместимы на уровне команд, а не просто сетевом уровне. С WiFi сложно управлять розеткой X с датчика Y. А в Z-Wave эта совместимость уже «из коробки». Ну и работа от батареек нормально реализована — на WiFi это всё криво.
А чем Z-Wave лучше того же ZigBee Home Automation профиля? Z-Wave мене стандартизирован чем 802.15.4 или в общем в чем отличия а то у того же Digi есть свой протокол DigiMesh… и все они вроде похожи Mesh сети профили и тд (разные частоты)
Самый простой ответ: тем, что в Z-Wave прямо сейчас можно купить сотню-две-три уникальных устройств для вашего рынка, а с указанным профилем ZigBee почти ничего. В плане стандартизации Z-Wave точно круче: покрыты все области автоматизации, и это не просто спеки на бумаге — это реальные устройства много лет на рынке.
А ещё, почитайте вот это: https://geektimes.ru/post/280822/ — по сути протокол открыт.
А ещё, почитайте вот это: https://geektimes.ru/post/280822/ — по сути протокол открыт.
Не совсем понятно, почему нельзя использовать для генерации задержек таймер?
Тогда не возникает никаких пустых циклов, когда микроконтроллер ничего не делает.
Тогда не возникает никаких пустых циклов, когда микроконтроллер ничего не делает.
А вы это ардуинщику объясните ;) Они же привыкли к delay(). И мы пытались их не переучивать.
Внутри мы по сути таймер и используем, но на это время нам нужно выйти из под управления пользовательского кода и поработать в нашем коде. А потом вернуться, сделав вид, что ничего и не было такого — т.е. вернуть все состояния. Отсюда и весь цирк.
Внутри мы по сути таймер и используем, но на это время нам нужно выйти из под управления пользовательского кода и поработать в нашем коде. А потом вернуться, сделав вид, что ничего и не было такого — т.е. вернуть все состояния. Отсюда и весь цирк.
Не надо ТАК об Ардуино. Подход в стиле «Blink без Delay» известен давно и вполне популярен.
Так я же не об Ардуино, а о большинстве пользователей Ардуино и их привычках. Если попросить написать Blink, то лишь 1 из ста сделает это с таймерами, и его сочтут психом, т.к. Blink конечно проще с delay().
Вы предлагаете всех лечить, что блинк можно сделать без delay()? Мы же просто решили сделать так, чтоб люди могли пользоваться привычным.
Вы предлагаете всех лечить, что блинк можно сделать без delay()? Мы же просто решили сделать так, чтоб люди могли пользоваться привычным.
Идея выведения обслуживания радио в отдельный поток очень неплоха.
А вы оценивали оверхед от использования С++ по сравнению с С? Насколько все это затратнее?
А вы оценивали оверхед от использования С++ по сравнению с С? Насколько все это затратнее?
Да, оценивали. Мы же в конечном итоге собираем сами весь код С.
Размер кода вырастает существенно. Бывает, раза в 3. Так же появляется несколько промежуточных дополнительных вызовов, что увеличивает расход стека. Но в общем и целом это не критично.
Значительно хуже сказывается, например, использование локальных переменных и передаваемых параметров, которые SDCC не умеет в XDATA заводить, а кидает в стек. Из-за этого многие библиотеки приходится переписывать на некрасивый стиль с глобальными переменными.
Размер кода вырастает существенно. Бывает, раза в 3. Так же появляется несколько промежуточных дополнительных вызовов, что увеличивает расход стека. Но в общем и целом это не критично.
Значительно хуже сказывается, например, использование локальных переменных и передаваемых параметров, которые SDCC не умеет в XDATA заводить, а кидает в стек. Из-за этого многие библиотеки приходится переписывать на некрасивый стиль с глобальными переменными.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы среду Arduino на 8051 натягивали, или ОС на один процесс