1 2 3 4 5 6 7 8 9 10 0/10 0,00оценок: 0

Умный дом на шине CAN

Тема в разделе "Умный дом", создана пользователем asasl, 08.12.15.

  1. asasl
    Регистрация:
    04.04.09
    Сообщения:
    55
    Благодарности:
    2

    asasl

    Живу здесь

    asasl

    Живу здесь

    Регистрация:
    04.04.09
    Сообщения:
    55
    Благодарности:
    2
    Адрес:
    Москва
    Умный дом на шине CAN
    Недавно начал проект УД на шине CAN.
    Шину выбирал исходя из простоты и надежности, многие микропроцессоры сейчас имеют контроллер данной шины. Каждый контроллер - мастер, коррекция ошибок производится автоматически.
    В архитектуре предусмотрены как радио-удлинители шины, так и оконечный контроллеры связанные беспроводно с общей шиной.
    В качестве сервера управления и сценариев будет неплохо зарекомендовавший себя OpenHab на Raspberry PI, собранную для надежности в кластере.
    Присоединяйтесь к проекту, одному в разумное время мне его не потянуть. Многое уже сделано.

    https://sites.google.com/site/cansmarthouse/targets
     
    asasl , 08.12.15
    #1 + Цитировать
  2. lingvo
    Регистрация:
    25.11.15
    Сообщения:
    657
    Благодарности:
    123

    lingvo

    Живу здесь

    lingvo

    Живу здесь

    Регистрация:
    25.11.15
    Сообщения:
    657
    Благодарности:
    123
    Что значит
    ? Вы уже реализовали это решение?
    По CAN - какой протокол сверху? Свой, ни с чем не совместимый?

    Как пользователь CANа с 10-и летним стажем, и у которого есть не один десяток уже разработанных и выпускающихся плат модулей для него, которые можно просто взять и поставить в УД 1-в-1, скажу, что по моему скромному мнению не стоит применять эту шину в умном доме. Да надежная, да простая (на первый взгляд), но не для данных применений.
    Я не вижу будущее у нее, хотя бы потому, что ни один консорциум не стандартизировал ее для УД. Например CANopen - профили для всего, чего можно есть, а для УД нет. То есть только вы один будете поддерживать и развивать свою систему и модули для нее, если решитесь на это.
    Вопрос, стоит ли овчинка выделки?

    С другой стороны от беспроводных решений вы все равно не избавитесь, так зачем городит огород?
     
    lingvo , 08.12.15
    #2 + Цитировать
  3. asasl
    Регистрация:
    04.04.09
    Сообщения:
    55
    Благодарности:
    2

    asasl

    Живу здесь

    asasl

    Живу здесь

    Регистрация:
    04.04.09
    Сообщения:
    55
    Благодарности:
    2
    Адрес:
    Москва
    А зачем его с чем-то совмещать? Большого смысла не вижу...

    Так в чем минусы? Я их не вижу, подскажите, мне очень интересен ваш опыт...
     
    Последнее редактирование: 08.12.15
    asasl , 08.12.15
    #3 + Цитировать
  4. asasl
    Регистрация:
    04.04.09
    Сообщения:
    55
    Благодарности:
    2

    asasl

    Живу здесь

    asasl

    Живу здесь

    Регистрация:
    04.04.09
    Сообщения:
    55
    Благодарности:
    2
    Адрес:
    Москва
    Да, опробовал на виртуальных машинах. Все работает.
     
    asasl , 08.12.15
    #4 + Цитировать
  5. Mycraft
    Регистрация:
    14.03.15
    Сообщения:
    597
    Благодарности:
    427

    Mycraft

    Умный дом на KNX

    Mycraft

    Умный дом на KNX

    Регистрация:
    14.03.15
    Сообщения:
    597
    Благодарности:
    427
    Адрес:
    Берлин
    Хмм тоже прочитал и вот думаю зачем велосипед изобретать...возьмите какое-нибудь решение которое уже было распространенно на УД и просто добавьте туда свои усилия...на Том же Raspberry есть различные попытки использовать его для УД
     
    Mycraft , 08.12.15
    #5 + Цитировать
  6. asasl
    Регистрация:
    04.04.09
    Сообщения:
    55
    Благодарности:
    2

    asasl

    Живу здесь

    asasl

    Живу здесь

    Регистрация:
    04.04.09
    Сообщения:
    55
    Благодарности:
    2
    Адрес:
    Москва
    Raspberry Pi будет использоваться как сервер сценариев и веб-сервер, а в качестве контроллеров использовать надо контроллеры с RTOS, иначе кроме глюков ничего не будет...
     
    asasl , 08.12.15
    #6 + Цитировать
  7. lingvo
    Регистрация:
    25.11.15
    Сообщения:
    657
    Благодарности:
    123

    lingvo

    Живу здесь

    lingvo

    Живу здесь

    Регистрация:
    25.11.15
    Сообщения:
    657
    Благодарности:
    123
    Во первых, чтобы не изобретать протокол. Во вторых, чтобы иметь возможность подключать сторонних производителей.

    По первому - исходя и из вашей топологии сети - у вас может быть несколько CAN шин, да еще и с гейтвеями на радио и RS232. Если вы читали ISO 11898 и реально работали с CAN, то не могли не заметить, что без применения протоколов более высокого уровня вы сможете создать только одношинную сеть с несколькими устройствами. Дальше вам придется изобретать что-то вроде велосипеда:
    - как распределить адресное пространство между всеми устройствами, старыми и новыми, если CAN оперирует ID для сообщений, а не для узлов.
    - как легко добавлять новые сообщения и новые данные на шину без перепрошивки всех устройств.
    - какой формат передачи информации, если это будет не просто числа, а текст, например
    - как организовать передачу через радио и другим протоколам, если CAN подразумевает подтверждение доставки сообщений всеми узлами битом Ack.
    и еще несколько проблем. В итоге вы придете либо к стандартному протоколу высшего уровня - например CANopen, либо изобретете свой (последнее потребует от вас минимум несколько месяцев усилий, а то и год) Причем в последнем случае будет несколько итераций, когда вы выкинете все и начнете все с нуля. Текущие пользователи вашего "умного дома" будут этому не рады.

    По второму - вы хотите разрабатывать все самостоятельно - от управляемых реле, до выключателей, гейтвеев и панелей управления? Это серьезный труд и надо рассчитывать, что вы будете производить и продавать это оборудование сериями, а не просто хобби. Иначе это не окупится и будет гораздо дешевле покупать что-то готовое.

    Минусы в том, что кабель. Это во первых.
    Во вторых CAN - это один длинный кабель с короткими ответвлениями и терминаторами на концах, то есть его надо протянуть одним куском по всей квартире/доме и не забыть ни одну точку, потому что потом подключить новый узел в сеть будет сложно.
    Для УД гораздо лучше топология кабеля по виду звезды - например тот-же Ethernet. То есть коммуникация точка-точка со свичами. Тогда вы тянете все кабеля в одну/две точки, и потом не сложно будет добавить новый узел без изменения топологии сети.
    В-третьих - и это связано с самим протоколом - я не видел пока решений из коробки на этом протоколе, или каких-то спецификаций каких-то консорциумов. KNX, HDL, Lonworks, Modbus и прочие на RS-485 - пожалуйста, а CAN нету.
    А я искал - так как сам являюсь производителей различных CAN штучек, но для другой области, где CAN - де-факто стандарт и хотел с минимальными переделками и опытом выйти на этот рынок со своим оборудованием. Но понял, что лезть со своим протоколом в чужой монастырь не стоит.
     
    lingvo , 08.12.15
    #7 + Цитировать
  8. lingvo
    Регистрация:
    25.11.15
    Сообщения:
    657
    Благодарности:
    123

    lingvo

    Живу здесь

    lingvo

    Живу здесь

    Регистрация:
    25.11.15
    Сообщения:
    657
    Благодарности:
    123
    Для сценариев тоже реальное время нужно. Иначе можно долго ждать. Удаленным контроллерам вообще операционка не нужна.

    ПС. Забыл еще. Распределенная vs централизованная модель управления.
    Хоть CAN и задуман был как мультимастер - т. е. каждый узел может передавать, когда захочет, контроль коллизий и т. д. не рассчитывайте на то, что и на более высоком уровне вы будете использовать мультимастер (например выключатель самостоятельно отдает команды реле и т. д.) Кроме головной боли в конфигурации и программировании это ничего хорошего вам не принесет. Практически все стандартные протоколы высокого уровня - СANopen, DeviceNET и пр. в конце концов имеют один мастер-контроллер, для которого CAN шина - это нечто вроде портов расширения ввода-вывода. Т. е. он получает состояния датчиков с шины CAN, обрабатывает информацию и посылает команду исполнительным устройствам, подключенным к той-же шине.
    Так гораздо проще. Благодаря низкой задержке и тому же мультимастеру на низком уровне, задержка передачи команд будет минимальной. Конфигурация и программирование тоже простыми - узлы I/O - тупые контроллеры без какой-либо логики. Вся управляющая программа крутится на одном компьютере и легкое протоколирование - все события так или иначе проходят через одно место (в хорошем смысле) :)
     
    lingvo , 08.12.15
    #8 + Цитировать
  9. asasl
    Регистрация:
    04.04.09
    Сообщения:
    55
    Благодарности:
    2

    asasl

    Живу здесь

    asasl

    Живу здесь

    Регистрация:
    04.04.09
    Сообщения:
    55
    Благодарности:
    2
    Адрес:
    Москва
    Несколько - это много, в моем случае минимум несколько десятков.
    Маршрутизация между шинами написана и работает.
    Контроль коллизий в современных микроконтроллерах реализован.

    RTOS сильно упрощает написание real time приложений и уменьшает кол-во ошибок.
    Весит же килобайт 5-6 всего. Попробуйте Chibios, намного ускорит работу.

    Никто не мешает иметь несколько шин CAN.
    CAN для УД удобнее: длиннее и гораздо менее потребляющий...

    Не особо-то и сложно. Главное не залазить в большие скорости, которые в нашем случае не нужны. 125 кбит/с достаточно для передачи 500 событий в секунду (при 20% загрузке шины), это немалая цифра. Во вторых каждый контроллер при необходимости может выступать 1wire мастером для пары десятков малых slave контроллеров, если вдруг надо сделать ветку...
     
    Последнее редактирование: 08.12.15
    asasl , 08.12.15
    #9 + Цитировать
  10. lingvo
    Регистрация:
    25.11.15
    Сообщения:
    657
    Благодарности:
    123

    lingvo

    Живу здесь

    lingvo

    Живу здесь

    Регистрация:
    25.11.15
    Сообщения:
    657
    Благодарности:
    123
    Удачи!
    Вот тут есть один товарищ, который тоже на CANе УД реализовывает. Может быть с ним скорешуетесь.
    http://electronix.ru/forum/index.php?showtopic=123840&st=60
     
    lingvo , 08.12.15
    #10 + Цитировать
  11. asasl
    Регистрация:
    04.04.09
    Сообщения:
    55
    Благодарности:
    2

    asasl

    Живу здесь

    asasl

    Живу здесь

    Регистрация:
    04.04.09
    Сообщения:
    55
    Благодарности:
    2
    Адрес:
    Москва
    Спасибо! Обязательно с ним спишусь.
     
    asasl , 08.12.15
    #11 + Цитировать
  12. X13dev
    Регистрация:
    29.05.13
    Сообщения:
    193
    Благодарности:
    47

    X13dev

    Живу здесь

    X13dev

    Живу здесь

    Регистрация:
    29.05.13
    Сообщения:
    193
    Благодарности:
    47
    Адрес:
    Германия
    А может Вы к нам?
    Уже имеется работающая серверная часть: GUI, Web server, PLC, MQTT server.
    Устройства подключаются по MQTT-SN от IBM.
    Реализованы PHY для UART, LAN ENC28J60, RF CC1101 и RF RFM12
    Примеры конфигураций:
    Config Controller [PHY1 ] PHY2 DIO PWM AIN TWI UART
    A1CN12 ATMega328p [RF CC1101 ] - 14 2 9 1 1
    A1En12 ATMega328p [LAN ENC28J60 ] - 14 2 9 1 1
    A1ES12 ATMega328p [LAN ENC28J60 ] UART 12 2 9 1 -
    A1Rn11 ATMega328p [RF RFM12 ] - 14 2 9 1 1
    A1SC12 ATMega328p [UART ] RF CC1101 12 2 9 1 -
    A1Sn12 ATMega328p [UART ] - 18 4 9 1 -
    A1SR11 ATMega328p [UART ] RF RFM12 12 2 9 1 -
    A3SC12 ATMega1284p [UART ] RF CC1101 13 3 3 1 -
    A3Sn12 ATMega1284p [UART ] - 18 5 3 1 -
    A4En12 ATMega2560 [LAN ENC28J60 ] - 60 13 12 1 4
    A4ES12 ATMega2560 [LAN ENC28J60 ] UART 58 13 12 1 3
    A4Sn12 ATMega2560 [UART ] - 62 13 12 1 3
    S2En12 STM32F051R [LAN ENC28J60 ] - 44 NC 16 NC 2
    S2SC12 STM32F051R [UART ] RF CC1101 42 NC 16 NC 1
    S2Sn12 STM32F051R [UART ] - 46 NC 16 NC 1
    S2SR12 STM32F051R [UART ] RF RFM12 42 NC 16 NC 1
    S3En12 STM32F103R [LAN ENC28J60 ] - 34 NC 16 NC 2
    S3Sn12 STM32F103R [UART ] - 36 NC 16 NC 1

    Если добавите сюда CAN будет вообще хорошо.
     
    X13dev , 09.12.15
    #12 + Цитировать
  13. asasl
    Регистрация:
    04.04.09
    Сообщения:
    55
    Благодарности:
    2

    asasl

    Живу здесь

    asasl

    Живу здесь

    Регистрация:
    04.04.09
    Сообщения:
    55
    Благодарности:
    2
    Адрес:
    Москва
    А для чего вам CAN? Для связи модулей или для работы с внешними устройствами с поддержкой, например, CANopen? Просто это совсем разные задачи.
     
    asasl , 09.12.15
    #13 + Цитировать
  14. X13dev
    Регистрация:
    29.05.13
    Сообщения:
    193
    Благодарности:
    47

    X13dev

    Живу здесь

    X13dev

    Живу здесь

    Регистрация:
    29.05.13
    Сообщения:
    193
    Благодарности:
    47
    Адрес:
    Германия
    Иногда в произвольном месте нужны пара входов/выходов или I2C сенсор. Ставить в таком месте модуль с LAN избыточно, а поскольку питание всё равно вести надо - можно и линию связи на соседнюю пару повесить. Да и подешевле такие модули должны быть.
     
    X13dev , 09.12.15
    #14 + Цитировать
  15. asasl
    Регистрация:
    04.04.09
    Сообщения:
    55
    Благодарности:
    2

    asasl

    Живу здесь

    asasl

    Живу здесь

    Регистрация:
    04.04.09
    Сообщения:
    55
    Благодарности:
    2
    Адрес:
    Москва
    Такое у нас уже сделано на STM32F103. LAN будет избыточен всегда практически для УД. А чем вам не нравится в качестве сервера OpenHAB?
     
    asasl , 09.12.15
    #15 + Цитировать

Смотрите также