Комментарии 39
К слову об i2c тоже думал. Привлекательно выглядит при строительстве или ремонте уложить только двухжильный провод.
Лучше все таки использовать вещи по прямому назначению - I2C предназначен для коммуникаций внутри платы, для вытаскивания "наружу" есть другие интерфейсы, например, тот же RS485.
У меня в серверных температура собирается лет 15 по одному трехпроводному кабелю, на котором несколько датчиков 18b20. Правда и датчики и адаптер USB-i2c c маркировкой "Made in USA".
1Wire это не I2C, первый специально сделан для длинных линий.
Попутал :)
Точно он https://habr.com/ru/articles/529720/
1-wire и i2c существенно отличаются. В i2c есть линия синхронизации тактово частоты а у 1-wire нет. Устройство на удалении получит сигнал синхронизации (SCL) с существенным запозданием, которое будет превышать допустимый порог для работы протокола и данные от удаленного устроства (SDA) будут приходить не сихронизированно с тактовой частото. Тем самым у вас не будет работать передача данных. Это все будет происходить потому что существует физическая задержка в передаче сигнала по проводам.
К слову, для автора первого комментария. I2C требует не 2 провода а 3. SDL, SCL и GND(земля). 1-Wire можно путить по 2 двух проводной схеме с паразитным питанием, но это будет уменьшать скорость передачи, что в принципе может и не критично.
RS-485 так же работает по 3 проводам: A, B, GND. Минус RS-485 в том что нужно ставить устроство которое будет передавать сигнал с устройства в RS-485, но есть готовые платы RS-485<->I2C, RS-485<->UART, RS-485<->SPI.
Устройство на удалении получит сигнал синхронизации (SCL) с существенным запозданием, которое будет превышать допустимый порог для работы протокола
При 100метрах задержка будет 0.6мкс при том что по стандарту 5мкс, вроде, на ответ. Проблема тут в помехозащищённости и самое главное - ёмкости кабеля.
А если говорить про 1wire - у него ровно такие же проблемы с задержками, просто скорость в разы меньше.
Время ожидания в 5ms не связано с данной проблемой. У вас будет рассинхронизация SCL и SDA на каждом бите.
Если интересно почитайте статью: "Extending the SPI bus for long-distance communication". Суть проблемы там раскрыта и приводится пример решения.
Но смысла в этом решении нет если можно выбрать протокол в котором уже заложена возможность передачи на большие растояния, например RS-485.
Не будет рассинхронизации. В приведенной статье упоминается SPI с битовой скоростью 1-20мбит/с. Там да, задержка на 100метровом кабеле будет в ~1 бит на 1мегабите и ~10бит на 10мбит/с.
У i2c стандартная скорость - 100кбит/с - так что задержка <0.1 бита. У 1w скорость порядка 15кбит/с, так что там будет чуть надёжнее.
При 100метрах задержка будет 0.6мкс при том что по стандарту 5мкс, вроде, на ответ. Проблема тут в помехозащищённости и самое главное - ёмкости кабеля.
а какая проблема в емкости кабеля?
Не стоит возлагать на шину I2C больших надежд для передачи данных по длинным линиям.
Она рассчитана на линии 5-10 см.
Еще протоколы передачи данных 99,9% I2C устройств не имеют контроля целостности данных.
Если всё же не послушаете совета, то получите кучу разнообразных проблем возникающих со случайной периодичностью и отсутствием возможности их решить без костылей. Частенько можно даже не заметить, что по шине I2C данные передаются с ошибками.
Применяйте RS-485 с протоколом MODBUS RTU и всё у вас будет хорошо на длинных линиях.
Вообще, I2C применяется для контроля внутри серверных стоек с протоколом SMbus.
Обычно с усилителями шины, насколько я помню.
плюс, это часть VGA интерфейса.
Не передергивайте. Я вам про "самолет АН-2", вы мне про "Airbus".
SMbus - это не тоже самое, что I2C. Из общего у них только трех-проводная шина (SCL, SDA, GND).
SMbus 1.1 имеет Packet Error Checking в протоколе, а I2C нет.
Длина линий передачи в серверной стойке не сравнима с длиной линий в "умном доме". И сами же про усилители (повторители) шины написали.
Преимущества МODBUS RTU поверх шины RS-485 перед шиной I2C:
Дифференциальная шина. Отсюда и повышенная помехоустойчивость.
Контроль ошибок с помощью CRC.
В общем, когда достаточно долго потопчетесь по граблям с I2C, SMbus, то поймете, что не годятся эти шины для передачи данных на длинные дистанции (в "умном доме").
Не надо так горячиться, я уточнил, что i2c все-таки может быть в каком-то виде использована для автоматизации и указал ограничения ее применения (ну, вдруг есть непреодолимое желание попробовать). Если принимать это во внимание, то использование может быть оправданным для небольших расстояний (в качестве примера такого применения я указал SMbus, чтобы не изобретать велосипед).
Не зная структуры, трудно оценить длину сети. Вдруг есть необходимость контроля температуры в шкафу автоматики, например. И даже в этом случае не стоит забывать про усилители, потому что IIC - для связи между микросхемами на плате, как следует из названия.
SMbus - это не тоже самое, что I2C. Из общего у них только трех-проводная шина (SCL, SDA, GND).
Мы с разработчиками спецификации не согласны: "The SMBus and I²C bus are very similar and are generally interoperable". Что касается PEC - это уровень протокола.
Но в целом, я согласен с вами, что RS-485 + Modbus RTU гораздо лучше подходит для целей домашней автоматизации. В том числе, для данного конкретного случая.
подобие I2c применяется и на длинных дистанциях в умном доме. см.Радио 6/2016. Правда для небольших скоростей и небольших данных.
Никто не может запретить людям городить "велосипеды" ради интереса. Я сам подобным занимался не раз. Но обычно домочадцы не готовы долго терпеть провода торчащие от всюду и "умный дом" работающий кое как или сегодня так, а завтра по другому.
Из недостатков шины упомянутой в журнале Радио 6/2016, имеем:
Не совместимая ни с чем другим, что ведет к дороговизне конечных устройств, т.к. каждый их новый тип необходимо разработать и изготовить самостоятельно, а время = деньги. Ситуацию не спасает даже дешевый микроконтроллер, т.к. стоимость комплектующих - это лишь малая часть готового устройства;
Очень низкая скорость обмена данными, ведущая к большим задержкам при передаче состояний от устройств к контроллеру и обратно. В типовом "умном доме" более десятка устройств на шине. Т.е. 80мс * 10 = 800 мс в идеале, а в реале будет больше. Это очень заметная и раздражающая задержка. А контроллер всё равно понадобится рано или поздно т.к. захочется какого нибудь хитрого функционала на который встроенные в конечные устройства скрипты будут не способны.
Серверная стойка она очень компактная, в неё расстояния между связываемыми устройствами измеряется в десятках см. А значит это в рамках того на что расчитан протокол, разве не так?
Серверная стойка не такая уж компактная - если вести провода по кабельным каналам может быть и 5 м.
Надо различать i2c и SMbus - физически это шины с аппаратными адресацией и арбитражом на монтажном ИЛИ.
i2c - для обмена между ИМС на плате, более скоростной и с меньшей нагрузочной способностью. При этом протокол определяется устройствами - EEPROM или ADC, например, абсолютно разные. Длина - максимум десятки см (зависит от скорости).
SMbus кроме физических уровней с повышенной нагрузочной способностью содержит описание протокола и формата пакетов, в том числе упомянутый PEC CRC-8. Длина - единицы метров.
Использование чистой i2c для обмена вне платы/системной шины чревато непредсказуемыми граблями, как справедливо заметил plyatov.
I2C это протокол который обеспечивает передачу бит, более конкретно 8 бит за один frame. Контроль целостности данных это уже следующие уровни. RS-485 точно так же не проверяет целостность данных.
По i2c можно так же передавать MODBUS RTU и другие протоколы более высокого уровня. MODBUS RTU это просто описание последовательности бай в сообщении.
Возвращаясь к i2c, можно без проблем передавать последовательно некоторое кол-во байт, в которых первая часть будет данными а последние N байт контрольной суммой.
Собственно, вы начали разрабатывать SMbus
Можно конечно пользоваться и SMbus, если сильно хочется, что не утерпеть. Но зачем?
Используя же RS485+MODBUS RTU, можно воспользоваться кучей готовых датчиков и исполнительных устройств созданных именно для "умного дома".
А для SMbus еще попробуй найди эти устройства в продаже.
Подозреваю, что следующая статья будет называться "Ремонт полоумной квартиры"
Ну или просто кондиционер на режим "авто провеетривание"
А как вы документируете все, что сделано, как работает и как подключено?
Тут скорее всего несколько моментов стоит обозначить.
Есть общая схема, приводил в статье выше. А есть уже какие-то отдельные девайсы со своими конфигами под каждую комнату. Конфиги храню в Github, схему держу в Obsidian (+excalidraw plugin). Точка входа в понимание общих схем будет Obsidian. А дальше уже по ссылкам перехожу и нахожу нужную ноду. Так же для макеток и электросхем использую EasyEDA.
Туя / Смарт лайф рулят ) ничего не понял но очень интересно)
MH-19 также имеет аналоговый выход, так что можно сразу в компаратор или в оу, а дальше например управлять вентилятором или форточкой
MH-Z19B - годный датчик. Но есть одно но. Он нуждается в периодической калибровке. Калибровка заключается в экспозиции на улице в течении часа. Как это решается в вашем случае совершенно неясно
В заключении статьи писал про SCD41 и отказ от MH-Z19B
еще годнее, но и там "The ASC algorithm assumes that the sensor is exposed to air with CO2 concentrations of 400 ppm at least once per week"
Каким образом тогда коробочные решения в виде датчиков СО2 решают этот вопрос?
коробочные решения могут измерять уровень неведомой фигни и по хитрым китайским формулам пересчитывать уровень этой фигни в TVOC, HCHO, CO, CO2 и PM2.5 одновременно. Кстати, почти так же работают все датчики MQ, только там не пересчет, а кросс-чувствительность ко всей остальной фигне. Как работают правильные коробочные решения с NDIR датчиками без помещения из раз в неделю в чистый воздух - не знаю.
Как от одного датчика дойти до полу-умной квартиры