Безпроводная связь Pasberry Pi + 3 x Arduino

Yaroslav · 2017-01-04 08:28:02

Не имел дела ни с NRF, ни с ESP, ни с Bluetooth.
Да и вообще я новичек в этом деле.
Потому прошу подсказки в какую сторону копать:
Система "умный дом", радиус связи - до 20м.
Необходимо обеспечить двухстороннюю связь.

И сразу вопрос в каком виде будет обеспечиваться эта связь?
Передача в виде String? Данные парсить и складывать в БД?

По замыслу на Raspberry будет touchscreen и приложение для управления
всеми системами.

Nefreemen · 2017-01-04 20:11:34

Вот когда Вы определитесь с "позамыслу", особенно с приложением, тогда и можно о чем то дальше говорить. Не ставьте телегу впереди лошади . Raspberry и тачскрин это просто железяки а не УД .

Остання редакція Nefreemen (2017-01-04 20:14:18)

Yaroslav · 2017-01-04 20:59:16

Как я уже написал: я новичек.
Всю логику на ардуинах написать могу.
С raspberry еще дела не имел, но приблизительно понимаю что оно может.
Пайтон буду осваивать по ходу реализации затеи.
Но вот как это объединить в одну систему пока не понимаю.

Как реализация в виде веб страницы или в виде приложения на пайтон влияет
на выбор железяк для реализации беспроводной связи?

Какой вариант реализации по Вашему мнению лучше?

Буду благодарен за ответы.

Nefreemen · 2017-01-04 22:23:39

А так и влияет , банально...Протоколы . Вы же сами задали этот вопрос . Вот и подумайте, а еще в интернете есть куча информации по данной теме. Кроме это Вы же написали расстояние 20 м а это очень важно (наверное есть стены ) следовательно NRF отпадает (тем более оно Вам надо делать проверку на целостность информации и т.д.?) не потянет, а синезубый тоже вряд ли. Остается ESP. В ее пользу говорит и тот факт что Вы написали что можете написать "всю логику" на Ардуино, то уже по моему логично рассматривать модули ESP. Программирование ESP возможно из Arduino IDE, тем более масса библиотек почти на все случаи жизни.
И еще, я так понял пайтон это Вы имели ввиду Python? Как то привычней читать "питон" .

П.С. Сейчас местные "гринпис" меня прибьют, возможно гвоздями , а Вас проводами обмотают .

Остання редакція Nefreemen (2017-01-04 22:30:43)

Yaroslav · 2017-01-04 23:38:45

Ну вот, я получил ответ куда копать.
Для меня это было не настолько очевидно, спасибо.

У меня еще есть вопросы:
- если мне не достаточно I/O на плате ESP, могу ли я ее приделать к Mega?
- как подружить штатный Wi-Fi Raspberry с ESP?
- ну и будет задача присобачить RS-485 шилд к ESP.
На UNO у меня получается считывать данные с электрического счетчика по rs-485 modbus rtu, но вот как это сделать с ESP?

Но если ответы на эти вопросы требуют жертвоприношений, то пожалуй пока обойдусь.
Пойду в магазин покупать необходимое.

Еще раз спасибо.

Nefreemen · 2017-01-05 01:46:53

1. Можете. У меня работает такое устройство. NoName тоже пробовал аналогичное использование ESP с Pro mini в проекте с катером.
2. А что в Raspberry какой то "особый" WiFi? Как по мне то совместимость WiFi описана самим стандартом .
3. Все что может Arduino может и ESP, даже больше, поскольку объем ОЗУ и флеш значительно больше так же как и частота работы. Единственно чем уступает - это количество gpio, каналов ШИМ и АЦП, отсутствие EEPROM. Большое количество флеш (в некоторых модулях 4 Mb) позволяет с лихвой компенсировать отсутствие eeprom и даже организовать файловую систему. Наличие ФС на борту в свою очередь позволяет сделать довольно неплохой WEB сервер со страничками без каких то сложных телодвижений типа работы с картой SD.

NoName · 2017-01-05 10:15:42

привет
копать в сторону
MQTT (Message Queue Telemetry Transport)
или / и MySQL

и все это должно крутится на
https://eero.com/

Остання редакція NoName (2017-01-05 15:48:56)

Lic Control · 2017-01-05 23:13:53

Почему беспроводная связь?
Намного надежнее проводная связь, например Ethernet. Если это возможно, то схема может быть такая:
Raspberry Pi является основным устройством в котором крутятся все программы, включая Web сервер. Arduino используется только для снятия информации с датчиков, включения реле и/или аналоговых выходов/входов. Хотя Arduino можно и не применять. Например подключать к Raspberry необходимое количество входов/выходов по OneWire или I2C. Учтите, что I2C работает только на малых расстояниях, например в пределах электического щита. OneWire дает дальность до 200 м. При больших расстояниях применяйте соединение по Ethernet, например Arduino Nano + ENC28J60 или Orange Pi Zero и т.д.Сенсорный монитор подключенный к Raspberry далеко не лучше решение. Проще заходить на WEB сервер, который реализован в Raspberry через смартфон, планшет, компьютер. Можно даже со SmartTV!
Некоторые мои разработки в этом направлении можно посмотреть на сайте.
Вот принципиальная схема автоматики освещения на Orange Pi(Raspberry Pi). Для удобства коммутации разработана интерфейсная плата.
Shema
Вот схема автоматики управления системой отопления.
Shema1
В обеих случаях достаточно одного контроллера типа Raspberry Pi. Управление осуществляется через WEB интерфейс. А с применением сервиса типа Weaved получаете и удаленный доступ через Интернет без проброса портов и фиксированного IP.
Если нужно больше - делайте блоки расширений входов/выходов.

Nefreemen · 2017-01-06 01:38:04

Lic Сontrol, у меня есть вопрос. Дело в том что еще на заре своего интереса к системам УД (наверное года два назад ) в поле зрения мне попалась Ваша система, правда она была немножко "скромней" . Еще тогда у меня возник естественный вопрос а что будет с Вашей системой если по каким то причинам "сердце" умрет?

Остання редакція Nefreemen (2017-01-06 01:38:30)

freeman · 2017-01-06 12:13:56

Yaroslav пише:

Ну вот, я получил ответ куда копать.
Для меня это было не настолько очевидно, спасибо.
У меня еще есть вопросы:
- если мне не достаточно I/O на плате ESP, могу ли я ее приделать к Mega?
- как подружить штатный Wi-Fi Raspberry с ESP?
- ну и будет задача присобачить RS-485 шилд к ESP.
На UNO у меня получается считывать данные с электрического счетчика по rs-485 modbus rtu, но вот как это сделать с ESP?
Но если ответы на эти вопросы требуют жертвоприношений, то пожалуй пока обойдусь.
Пойду в магазин покупать необходимое.
Еще раз спасибо.

На raspberry ставим mqtt-сервер. Для esp есть библиотека pubsub (mqtt-клиент), сам такую схему использую, работает отлично.

Yaroslav1 · 2017-01-06 12:25:14

MQTT - интересная тема, копаю.
Большинство примеров сделано через облако - для меня это проблема.
Первоначально цель сделать автономную систему, потом добавлять функционал через облако.
Насколько я понимаю сервер можно сделать и на Raspberry?! - тогда пойду именно этим путем.

Lic Control
Сам отдаю предпочтение проводным интерфейсам, но не все было предусмотрено на этапе ремонта,
некоторые вещи добавляю по ходу. Отсюда необходимость использовать беспродную связь.
Интересен "Релейный блок расширения выходов по протоколу 1Wire" - Какая стоимость?
Ему надо доп питание 12В? Реле громко щелкают?

Цель моего проекта - не только сделать не самый примитывный умный дом на одной-двух ардуинках,
а еще и научится писать программы, разобраться с SQL. Так что легких путей я не ищу.
Кстати, BlueJ вообще рабочая штука?

freeman · 2017-01-06 13:54:19

Yaroslav1 пише:

MQTT - интересная тема, копаю.
Большинство примеров сделано через облако - для меня это проблема.
Первоначально цель сделать автономную систему, потом добавлять функционал через облако.
Насколько я понимаю сервер можно сделать и на Raspberry?! - тогда пойду именно этим путем.
Lic Control
Сам отдаю предпочтение проводным интерфейсам, но не все было предусмотрено на этапе ремонта,
некоторые вещи добавляю по ходу. Отсюда необходимость использовать беспродную связь.
Интересен "Релейный блок расширения выходов по протоколу 1Wire" - Какая стоимость?
Ему надо доп питание 12В? Реле громко щелкают?

Цель моего проекта - не только сделать не самый примитывный умный дом на одной-двух ардуинках,
а еще и научится писать программы, разобраться с SQL. Так что легких путей я не ищу.
Кстати, BlueJ вообще рабочая штука?

У меня реле модули + esp. Т.к. квартира съемная, вариант только беспроводного устройства рассматривался изначально.
Сейчас все работает на локальном сервере (raspberry) через mqtt, никакого sql. Sql может пригодится разве что для сохранения истории показаний датчиков.
Реле щелкают не громко, ночью их слышно лучше. У каждого человека свой порог "громко"))). Рассматриваю вариант заменить реле на симисторы.

Все управляется через веб-интерфейс, сейчас он выглядит так web-интерфейс

Особо любопытным дам ссылку, сможете поиграться светом у меня в квартире)))))

Nefreemen · 2017-01-06 23:31:50

Yaroslav1, никто Вам не мешает иметь локальный MQTT сервер. У меня на данном этапе он работает в роутере. Но это детали.

Поскольку я давненько интересуюсь темой УД то некоторые системы я отбросил изначально так как они имеют очень существенный (на мой взгляд) недостаток -централизация. Почему я поднял вопрос а что будет если "сердце" такой системы "нагребнется". Даже ПК и тот может виснуть и т.д. чего уж говорить о Raspberry или о другом миникомпьютере. Помните как у Булгакова, Воланд (не помню дословно простите) сказал:"...вы думаете что чем то управляете? Простите но для того что бы управлять нужен план...Ну хотя бы так лет на тысячу...А человек смертный, а самое главное что смертный внезапно...". Ахилесова пята миникомпов это ограниченный ресурс работы SD и eMMC, и это факт. А самое главное что кирдык приходит внезапно. Рассмотрим централизованную систему аналогичную как у Lic Control, что будет с конечными устройствами если от центрального контроллера они не получат сигнал? Ну что может сделать к примеру в его системе реле насоса отопления? Или какое нибудь другое устройство? К чему эти все "расширитетели датчиков" и "умножители портов" они что делают? Разве они могут принять решение "быть или не быть"? Поэтому мое мнение, что каждый узел который отвечает за то или иное действие (группу) быть автономным, иметь свои "мозги", и быть в курсе состояния узлов (датчиков) от которых зависит его работа минуя центральные "мозги". Кроме этого ему можно было бы напрямую "приказать" или "спросить" :D.
Да MQTT хорош во всех отношениях, универсальность, простота, интеграция с облаками и т.д. но не забываем главное- это всего лишь "Telemetry Transport" и не более. Весь вопрос что делать дальше с этим "message". Действительно можно просто через клиент на мобилке, планшете, или нарисовав WEB страницу управлять, даже можно шедулер присобачить :D . Но как по мне то система которая не "помнит" ничего из прошлого, "прямолинейно знает" будущее и не имеет "сценариев поведения" в зависимости от тех или иных ситуаций я бы такую систему не назвал УД :rolleyes: .

Остання редакція Nefreemen (2017-01-06 23:38:03)

freeman · 2017-01-07 01:54:51

На самом деле все решаемо, вопрос стоит ли? Если рулить котлом, то может и стоит иметь минимальный алгоритм поведения в микроконтроллере на случай отказа сервера. Но если это освещение, то наверное не стоит все лишний раз усложнять. Как не крути, а логику в разы проще реализовать на сервере, чем на конечном устройстве. Насчет долговечности sd-карты, мой сервер работает как nas с лета 24/7, на нем же mqtt-сервер, думаю это хороший показатель.

Nefreemen · 2017-01-07 13:30:43

freeman пише:

На самом деле все решаемо, вопрос стоит ли? Если рулить котлом, то может и стоит иметь минимальный алгоритм поведения в микроконтроллере на случай отказа сервера. Но если это освещение, то наверное не стоит все лишний раз усложнять. Как не крути, а логику в разы проще реализовать на сервере, чем на конечном устройстве. Насчет долговечности sd-карты, мой сервер работает как nas с лета 24/7, на нем же mqtt-сервер, думаю это хороший показатель.

Я считаю что стоит. Почему? Действительно освещение не критично (есть обычные выключатели). Но остальные вещи как для меня уже вопрос. Частный дом. Пока не сделал но надо, полив, обслуживание бассейна (фильтрация и подогрев), фильтрация пока сидит на таймере. В перспективе выбросить китайский контроллер который обслуживает сезонный солнечный коллектор летнего душа, часто летом прогавил и закипает , что не есть хорошо (образуется накипь на стенках вакуумных труб, падает эффективность) да и датчик уровня воды специфичный , можно остаться в пене и под холодной водой . Поэтому мне кажется что критичных вещей значительно больше чем не критичных.
По поводу миниПК то за пол года как правило проблемы возникают редко. А вот дальше уже шансы сбоев (как ну очень многие пишут) возрастают в разы. И я с этим полностью согласен. Вообщем как известно ядро Linux не сильно жалует твердотельные накопители (хотя и винда тоже), у меня в смартфоне за год миниСД две штуки сдохли. Для надежной работы наверное нужно ставить систему на хард .

Lic Control · 2017-01-08 00:08:25

Й

Nefreemen пише:

Yaroslav1, никто Вам не мешает иметь локальный MQTT сервер. У меня на данном этапе он работает в роутере. Но это детали.
Поскольку я давненько интересуюсь темой УД то некоторые системы я отбросил изначально так как они имеют очень существенный (на мой взгляд) недостаток -централизация. Почему я поднял вопрос а что будет если "сердце" такой системы "нагребнется". Даже ПК и тот может виснуть и т.д. чего уж говорить о Raspberry или о другом миникомпьютере. Помните как у Булгакова, Воланд (не помню дословно простите) сказал:"...вы думаете что чем то управляете? Простите но для того что бы управлять нужен план...Ну хотя бы так лет на тысячу...А человек смертный, а самое главное что смертный внезапно...". Ахилесова пята миникомпов это ограниченный ресурс работы SD и eMMC, и это факт. А самое главное что кирдык приходит внезапно. Рассмотрим централизованную систему аналогичную как у Lic Control, что будет с конечными устройствами если от центрального контроллера они не получат сигнал? Ну что может сделать к примеру в его системе реле насоса отопления? Или какое нибудь другое устройство? К чему эти все "расширитетели датчиков" и "умножители портов" они что делают? Разве они могут принять решение "быть или не быть"? Поэтому мое мнение, что каждый узел который отвечает за то или иное действие (группу) быть автономным, иметь свои "мозги", и быть в курсе состояния узлов (датчиков) от которых зависит его работа минуя центральные "мозги". Кроме этого ему можно было бы напрямую "приказать" или "спросить" .
Да MQTT хорош во всех отношениях, универсальность, простота, интеграция с облаками и т.д. но не забываем главное- это всего лишь "Telemetry Transport" и не более. Весь вопрос что делать дальше с этим "message". Действительно можно просто через клиент на мобилке, планшете, или нарисовав WEB страницу управлять, даже можно шедулер присобачить . Но как по мне то система которая не "помнит" ничего из прошлого, "прямолинейно знает" будущее и не имеет "сценариев поведения" в зависимости от тех или иных ситуаций я бы такую систему не назвал УД .

Проблема защиты от внезапного отказа контроллера может решаться разными способами. Приведу самый простой и дешевый вариант на примере контроллера топочной: котел работает на 1 ступени (встроенный контроллер); цируляционные насосы включены; клапан теплого пола закрыт; клапаны радиаторов открыты. Все это конфигурируется подбором реле (нормально откр/закр.)
Что бы защитить SD карточку, просто не пишите на нее! Пишите на, например, на USB-флешку. Если она умрет, потеряете только часть архива данных.
Очевидно, что проектирует систему автоматики нужно правильно выбрать количество контроллеров (уровень централизации)и распределить между ними задачи так чтобы выход из строя одного из них не приводил к серьезной проблеме.

Nefreemen · 2017-01-08 12:07:48

Lic Control, интеграция допустим встроенного контроллера топочного котла в систему УД ( у меня котел Altep, с верхним горением и какой то польский контроллер) вызывает сомнение и затруднение, ПИД регулирование вентилятора и прочие "прелести". Собственно вопрос стоит скажем так в "топологии" построения системы о чем я и писал выше.
Что касается писать или не писать на СД или флешку не решает проблему ОС Linux поскольку она использует ФС ext4 и даже размещение SWAP на флешке не решит проблему, потому что она "журналируемая" и имеет прочие особенности. Для надежной работы систем на базе Linux нужен хард (имхо).
Вы в принципе согласны что уровень централизации есть не маловажный фактор надежности системы, хотя в Вашей системе я не не увидел этого. Еще меня если честно очень смущает использование 1-Wire в качестве управляющей шины, например того же упомянутого выше блока реле. Поскольку стандарт 1-Wire накладывает очень жесткие требования на топологию шины, и почему то аналогичное использование (как у Вас) этой шины я не где не встречал.

freeman · 2017-01-08 13:59:12

Насчет linux, все решаемо, можно настроить ext4 под ssd и flash где важно минимальное количество циклов записи, можно использовать ext2 (она вообще без журналирования).

Lic Control · 2017-01-08 23:40:06

Nefreemen пише:

Lic Control, Еще меня если честно очень смущает использование 1-Wire в качестве управляющей шины, например того же упомянутого выше блока реле. Поскольку стандарт 1-Wire накладывает очень жесткие требования на топологию шины, и почему то аналогичное использование (как у Вас) этой шины я не где не встречал.

Есть по этому вопросу хороший документ, почитайте.

Nefreemen · 2017-01-09 13:26:38

Lic Control, к 1-Wire интерес у меня возник еще в 2005 году когда делал сигнализацию (я тогда конкретно затарился устройствами для этой шины до сих пор все еще не использовал ). И у меня есть и другие апноуты (тоже официальные) в которых черным по белому написано что применение шлейфовой или звездообразной топологии не рекомендуется из за сложности согласования импедансов . Мне очень хорошо известна проблематика однопроводных интерфейсов со времен коаксиальный компьютерных сетей которые я строил и обслуживал , об Ethernet тогда только слухи ходили . Но суть не в этом (может Вы не правильно меня поняли). Я нигде не встречал использование 1-Wire в качестве шины управления устройствами (что меня и смущает) а только для получения информации от устройств . Только не не надо мне рассказывать о протоколе, я знаю что он допускает передачу информации от ведущего ведомому, например чтение/запись "блокнота" (eeprom) того же DS18B20. Речь идет о не совсем стандартном применении шины. Я не отрицаю возможности такого использования а написал "смущает" .

Форум arduino.ua

#1 2017-01-04 08:28:02

Безпроводная связь Pasberry Pi + 3 x Arduino

#2 2017-01-04 20:11:34

Re: Безпроводная связь Pasberry Pi + 3 x Arduino

#3 2017-01-04 20:59:16

Re: Безпроводная связь Pasberry Pi + 3 x Arduino

#4 2017-01-04 22:23:39

Re: Безпроводная связь Pasberry Pi + 3 x Arduino

#5 2017-01-04 23:38:45

Re: Безпроводная связь Pasberry Pi + 3 x Arduino

#6 2017-01-05 01:46:53

Re: Безпроводная связь Pasberry Pi + 3 x Arduino

#7 2017-01-05 10:15:42

Re: Безпроводная связь Pasberry Pi + 3 x Arduino

#8 2017-01-05 23:13:53

Re: Безпроводная связь Pasberry Pi + 3 x Arduino

#9 2017-01-06 01:38:04

Re: Безпроводная связь Pasberry Pi + 3 x Arduino

#10 2017-01-06 12:13:56

Re: Безпроводная связь Pasberry Pi + 3 x Arduino

#11 2017-01-06 12:25:14

Re: Безпроводная связь Pasberry Pi + 3 x Arduino

#12 2017-01-06 13:54:19

Re: Безпроводная связь Pasberry Pi + 3 x Arduino

#13 2017-01-06 23:31:50

Re: Безпроводная связь Pasberry Pi + 3 x Arduino

#14 2017-01-07 01:54:51

Re: Безпроводная связь Pasberry Pi + 3 x Arduino

#15 2017-01-07 13:30:43

Re: Безпроводная связь Pasberry Pi + 3 x Arduino

#16 2017-01-08 00:08:25

Re: Безпроводная связь Pasberry Pi + 3 x Arduino

#17 2017-01-08 12:07:48

Re: Безпроводная связь Pasberry Pi + 3 x Arduino

#18 2017-01-08 13:59:12

Re: Безпроводная связь Pasberry Pi + 3 x Arduino

#19 2017-01-08 23:40:06

Re: Безпроводная связь Pasberry Pi + 3 x Arduino

#20 2017-01-09 13:26:38

Re: Безпроводная связь Pasberry Pi + 3 x Arduino

Швидке повідомлення

Підвал форуму