Сервер. Хочу свой IoT сервер. Вот хочу, бля, и всё тут. Разберём вопрос?

[Гість 3253]

Сервер. Хочу свой IoT сервер. Вот хочу, бля, и всё тут. Разберём вопрос?

Сабж, собственно. в названии темы.
У мну скопилось некое количество разной электронной дряни и достаточное желание как-то всё это увязать.
Ну щас типа IoT ваще развивается и тюдю а я шо, рыжий, штоле?

Там, короче, разные концепции есть - от классической IoT, которая предусматривает вообще всё через интернет (даже лампочка сначала через концентратор плюётся в интернет и потом получает чего-то. Или тот же датчик - напрямую нихуя ничё нишлёт в IoT концепции на исполнительные устройства) (эт так, очень вкратце и упрощённо) - до Z-вэйва, который вообще далековат от концепции IoT и допускает обработку хоть на локальном контроллере, хоть сценарии, забитые гвоздями и работающие в офлайне вообще без интернета.

Поскольку у меня зоопарк из принципиально ни чем не связанной хуеты - ни та, ни та концепции не подходят.

Я хочу что-то среднее, между MQTT (в котором всё через брокер) и модбасом. "Но с перламутровыми пуговицами". Короч, я ещё не знаю что хочу, и, вот, архитектуру этого и хочу обсудить.

Ну... в плане, чтобы было с кем о ней по пиздеть, а не сидеть и задротить молча в одиночку.

Поскольку я даос, и не хочу целиться в какую-то точку в бренном мире, а хочу целиться сразу в великое Дао (ну... так, по крайней мере, будешь точно вперёд двигаться) - начну, пожалуй, с сервера.

Какой сервер выбрать?
Не, на питоне я уже писал - он от больше 500 с копейками соединений дохнет. Хотя пишется довольно быстро и без проблем.

Поскольку целимся в великое Дао - то в великом Дао запрещено использовать кастомные протоколы безопасности, а писать на каждую срань шифрование - не каждая срань его осилит, на срани может стоять и довольно медлительная восьмибитка. То есть, наверняка SSL - от концентратора/контроллера через интернет.

И вот уже пара вопросов:

1) Упереться и прошарить тему, и писать свой сервак? Или есть готовое лёгковесное решение, которое можно адаптировать и сделать на нём?
2) Сколько соединений вообще можно поддерживать одновременно сервером? Я не занимался этим и хочу понимать масштаб.
Просто если это IoT - там придётся определять для юзерской стороны доступность устройств, а значит контроллер/концентратор - должен либо по таймеру (даже если нечего сказать) плеваться в сервер экноледжем себя, либо просто сохранять подключение.

Любая гипотетическая IoT сеть тем лучше - чем больше абонентов (как и любая вообще сеть), а скорости передачи там на каждом мелком девайсе - не космические совсем.
То есть - основное требование к серверу - максимально возможное количество подключений.

Кто шо знает? Колитесь.

P.S. Покашта мне вариант на C# нравится больше (так как я с C# знаком лучше), но он не кроссплатформа. На С++ вроде быстрее работают, но я его меньше применял. но он, теоретически, кроссплатформенный.

 

[Das Zugunfall]

На чем писать?
Я б склонялся к Elixir или Rust.
Первый легко держит хуилионы коннектов, второй - как замена крестов для здорового человека.

P.S. Покашта мне вариант на C# нравится больше (так как я с C# знаком лучше), но он не кроссплатформа.

Он то кросплатформа, но это как из пушки по воробьям.

Недавно встала задача прокинуть сигнал от датчиков в гараже в домашнюю сигналку с беспроводными датчиками с проприетарным протоколом.
В гараже какое-то китайское ethernet-реле, управляемое AT командами, чего-то когда покупал, подумал там есть модбас, но нихуя.
Интерфейс с сигналкой можно наладить только через специальную плату у которой с одной стороны их кастомный трансивер, с другой - пара сухих контактов под проводные датчики.
Соответственно, нужна была какая-то промежуточная шняга, которая будет опрашивать реле и через GPIO замыкать сухой контакт на плате.
Уже думал поднимать какой-нить openhab с mosquitto на ARM линуксе, по итогу когда в реле не оказалось ни модбаса ни mqtt, забил, и сделал простейший девайс на ESP.
Шняга втыкается в розетку в любом месте, где есть вифи, и начинает по UDP пинговать реле в гараже на предмет статуса входов, в случае, если статус хоть одного из входов отличается от дефолтного, то через оптрон замыкает геркон на обычном дверном датчике, потроха от которого находятся в одной коробке с есп-шкой и питаются от одного с ней стаба. Если ответов от реле нет продолжительное время, то тоже инициирует сработку. Дешево и сердито.

 

[Chipolog]

 

[Das Zugunfall]

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

 

[Гість 3253]

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

Ты пачиму каментишь без цитирования? Я ж не таймер тему постоянно чекать

У меня статик IP, домен и выделенная виндовая машинка без монитора штобы тестировать.
В принципе, можно впердолить на неё линух, чтобы доступ был хотя-бы по SSH.

Но я не шпарю в красноглазом.

Раст... ни разу не касался. Но, поскольку я хардварщик, и с C# и c C++, в принципе, моих нубских познаний на серьёзное ускорение не хватит - то почему б и не раст?

Чем хорош и нехер его придумали? Пойду почитаю...

UPD
Почитал... может лучше из пушки по воробьям?
Раст, как я понял - очень быстрый и не требует среды выполнения. На счет замены крестов - парадигма там мозголомная, и есть мнение, что написать на нём быстро путёвый бэкэнд - задача нетривиальная.
Эликсир - требует среды выполнения, парадигма тоже совершенно ёбнутая, синтаксис шизофренический. Лучше уже раст... А почему считается, что держит дохуилион коннекшенов?

 

[ujn]

Не, на питоне я уже писал - он от больше 500 с копейками соединений дохнет. Хотя пишется довольно быстро и без проблем.
...

что-то мне подсказывает что здесь уже начинается хуита.... по всем направлениям.

 

[Chipolog]

что-то мне подсказывает что здесь уже начинается хуита.... по всем направлениям.

я ещё не знаю что хочу, и, вот, архитектуру этого и хочу обсудить.

 

[ujn]

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

 

[Гість 3253]

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

Потому, что мы говорим в этой теме об IoT.
Там часто используются хабы. И ты, когда в вебморду заходишь - там ты видишь свои "объекты" (не в плане ООП, а в плане - контроллер на квартире, контроллер в гараже) и неплохо бы фтыкать - они живы вообще, или нет.
Я уже писал выше - тут 2 пути - или ты их по таймеру бомбишь, или они просто открывают коннект к тебе на серв и не отпускают его - тогда понятно, что он жив.

500 сообщений одновременно, к стати, легко.
Это 50 юзверей, у которых стоит по 20 сенсоров, половина из которых сработала.
А 500 юзверей будет тебе обеспечивать 500 одновременных сообщений с завидной регулярностью просто в штатном режиме. К примеру, если у всех есть датчик освещённости, и настало утро. Ну ок - не у всех 500 оно одновременно настало... ну у 500 из 1000 абонентов.

 

[Гість 3253]

что-то мне подсказывает что здесь уже начинается хуита.... по всем направлениям.

Я ж сказал - думай о великом Дао!

Вот сколько пользователей у алексы и у сяоми? Сколько шайб одновременно плюются в сервер?
Надо делать стараться хорошо. Говно, оно само получается. Я б мог остановиться на питоне, у меня, всё равно, нет 500 контроллеров, но нахуй оно нужно? Пишут же люди нормально... я считаю, что если выносить какой-то опыт - так выносить нормальный.

 

[ujn]

Я ж сказал - думай о великом Дао!

Вот сколько пользователей у алексы и у сяоми? Сколько шайб одновременно плюются в сервер?
Надо делать стараться хорошо. Говно, оно само получается. Я б мог остановиться на питоне, у меня, всё равно, нет 500 контроллеров, но нахуй оно нужно? Пишут же люди нормально... я считаю, что если выносить какой-то опыт - так выносить нормальный.

ты сделай архитектуру сначала, MVP на коленке. переписать то 10% от всех усилий. потом оркестрация и прочая хуйня то после.

 

[Гість 3253]

ты сделай архитектуру сначала, MVP на коленке. переписать то 10% от всех усилий. потом оркестрация и прочая хуйня то после.

Вот... об архитектуре.
Поскольку зоопарк разношерстный, но хотелось бы хорошую интегрирующую способность.

Я думаю обернуть устройства в что-то типа модбас. В разных протоколах (зигби, звэйв, e.t.c) устройства описываются и выглядят по разному.
Модбас использует примитивную модель - описывая устройство, как набор катушек и реле. И эта модель, на самом деле - правильная, поскольку они реально и представляют из себя набор входов и выходов, и похуй что там а их протоколе - команд класс, или ещё чего, на самом деле - мы можем либо читать, либо писать, либо происходит ивент.

Есть ещё идентификация по Device ID- это тоже вещь в себе. Но тут, думаю - проще, я могу у себя пришить к Device ID ещё и тип протокола, чтобы избежать теоретически возможных совпадений, когда, гипотетически, у звэйвного и ещё какого-то кастомного/проприетарного девайса этот ID совпадёт.
Вот он не совпадёт, если кроме самого ID добавлять туда ID протокола.

P.S.
Минимально валуабльный продукт тут не совсем просматривается. Пока неясен принцип интеграции новых протоколов - будет хардкодинг и за это руки ампутировать надо. Потому, что послезавтра я захочу (или даже завтра) - свой сервак подключить к лора WAN, или заставить его быть подставным контроллером (ну да. использовать слабую машину вместо, скажем, чего-то типа Vera-хаба, но, при этом, сохранять её собственный функционал)... да много чего можно придумать. MVP в данном случае - тот продукт, который позволяет красиво и стандартно интегрировать в себя новый протокол + интегрировать новый нестандартный девайс.

 

[ujn]

вроде ж MQTT дает приемлемый уровень абстракции и интерфейс. остальное индивидуальными драйверами - плагинами.

 

[Гість 3253]

вроде ж MQTT дает приемлемый уровень абстракции и интерфейс. остальное индивидуальными драйверами - плагинами.

MQTT подразумевает всего одну концепцию - классический IOT.
Если я делаю сервер/концентратор с хорошей способностью к интеграции - уже MQTT можно реализовывать плагином.

Концепция MQTT - всё стучится в брокер, а брокер раздаёт издание подписчикам.
К примеру, Z-wave устройство не стучится ни в какой брокер - оно стучится в свой хаб, к которому его приаттачили.
И, вот, существующие хабы - совсем не обязательно (да и, в в подавляющем большинстве - и не делают так) поддерживают MQTT.

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

В моей концепции - бомбить его говнореле АТ командами можно будет не с ещё одного узкоспециализированного девайса/адаптера, а прямо с сервера. Он, правда, сервер, тогда перестаёт быть классическим сервером и не принимает запросы, а формирует их... однако, такая практика нихера не редкая, и девайсы любительского класса с непродуманным интерфейсом, или примитивным самодельным протоколом - встречаются чаще, чем хотелось бы.

Ну и хуй с ними, пусть встречаются, я хочу интегрировать любой девайс, который поддаётся описанию. Проприетарки, естественно, потребуют контроллера/хаба ( типа з-вэйвного с чётким разделением хаба и девайса, и своим радиоканалом)

P.S. К примеру, у тебя вэйвный контроллер, который может 251 девайс (это максимум для одного Home ID в з-вэйве). Но у тебя нет на одной квартире столько.
Ты покупаешь контроллер за $200 и используешь на 10%. Это не интересно. К примеру, у тебя есть ещё и гараж, и ты хочешь контролировать ящик стола на работе, а, также - ещё какую-нибудь херню. Но они не в зоне действия твоего Home концентратора. но в зоне действия интернета.
И тебе надо тогда, или купить по контроллеру на каждый удалённый объект, и прибить их себе к аккаунту на какой-нибудь Вере, или...
А почему бы не сделать дешманный свисток, который значительно дешевле и просто транслирует з-вэйв пакеты на мой сервер, имитируя, как будто они на том же контроллере?

Старых мобилок с вайфаем доебенчиков. Клиент я писал на андроид даже в сраном App Inventor - он там уже есть, его пазлом может собрать там даже школьник.
В телефоне есть BT, я могу сделать Z-wave-BT адаптер и транслировать тупо мессаги прямо на сервер, даже не педаля для телефона софт, делающий его я-Wave хабом. Хотя и это можно сделать.

Короче, я хочу подружить разные концепции. Можно дружить их с помощью MQTT, но я хочу и сам MQTT подружить с остальными. То есть - он может там участвовать на общих правах, а не как корневая технология.

 

[ujn]

...
P.S. К примеру, у тебя вэйвный контроллер, который может 251 девайс (это максимум для одного Home ID в з-вэйве). Но у тебя нет на одной квартире столько.
Ты покупаешь контроллер за $200 и используешь на 10%. Это не интересно. К примеру, у тебя есть ещё и гараж, и ты хочешь контролировать ящик стола на работе, а, также - ещё какую-нибудь херню. Но они не в зоне действия твоего Home концентратора. но в зоне действия интернета.
И тебе надо тогда, или купить по контроллеру на каждый удалённый объект, и прибить их себе к аккаунту на какой-нибудь Вере, или...
А почему бы не сделать дешманный свисток, который значительно дешевле и просто транслирует з-вэйв пакеты на мой сервер, имитируя, как будто они на том же контроллере?

Старых мобилок с вайфаем доебенчиков. Клиент я писал на андроид даже в сраном App Inventor - он там уже есть, его пазлом может собрать там даже школьник.
В телефоне есть BT, я могу сделать Z-wave-BT адаптер и транслировать тупо мессаги прямо на сервер, даже не педаля для телефона софт, делающий его я-Wave хабом. Хотя и это можно сделать.

Короче, я хочу подружить разные концепции. Можно дружить их с помощью MQTT, но я хочу и сам MQTT подружить с остальными. То есть - он может там участвовать на общих правах, а не как корневая технология.

ты хочешь реализовать программно на телефоне с зубом м вафлей хаб з-вейв(опустим несовпадение по частотам и протоколам) ? если такое возможно то тебе и первый хаб за 200 долларов не впал.

хотя кмк тут более уместно устройство ретранслятор на хаб, а не эмулятор первого хаба. ну то такое ) вперед)) главное по забористее стек технологий выбрать))

 

[Гість 3253]

ты хочешь реализовать программно на телефоне с зубом м вафлей хаб з-вейв(опустим несовпадение по частотам и протоколам) ? если такое возможно то тебе и первый хаб за 200 долларов не впал.

А где несовпадение? over BT я могу что угодно слать. Да, понадобится адаптер типа статик-контроллер. Но его можно сделать.

хотя как тут более уместно устройство ретранслятор на хаб, а не эмулятор первого хаба. ну то такое ) вперед)) главное по забористее стек технологий выбрать))

Так я и говорил, что телефон можно и не превращать в хаб. Именно как ретранслятор и использовать. Просто, потому, что у него есть и интернет в коробке и вторая сторона, поддающаяся адаптированию.
Но можно и ESP32 прикрутить, просто с телефоном возни меньше, не надо делать сам девайс и возиться с красноглазыми средствами разработки под ЕСП, которые нихера не юзерфрендли.

P.S. В случае с з-вэйвом статик-контроллер (эмулятор первого хаба) в какой-то мере, всё равно, придётся создать, так как звэйв по другому не работает. Там устройство инклудится к сети при его непосредстввенном участии, ты нажимаешь кнопку и оно переходит в инклуд, при этом мощность сигнала падает и оно ждёт, что контроллер (какой-нибудь) его начнёт инклудить.
К стати, в этот момент устройство можно угнать. Сигнал специально сильно понижают, чтобы его не слышал ни кто, кроме того контроллера, который не дальше метра.
Нельзя просто прописать в сеть з-вэйв девайс и ждеть, что он начнёт выполнять твои команды, если к нему обратиться.

 

[Das Zugunfall]

В моей концепции - бомбить его говнореле АТ командами можно будет не с ещё одного узкоспециализированного девайса/адаптера, а прямо с сервера. Он, правда, сервер, тогда перестаёт быть классическим сервером и не принимает запросы, а формирует их... однако, такая практика нихера не редкая, и девайсы любительского класса с непродуманным интерфейсом, или примитивным самодельным протоколом - встречаются чаще, чем хотелось бы.

Справедливости ради, это говнореле может быть TCP мастером, TCP слейвом, UDP мастером и UDP слейвом. С мастерами все понятно, а вот со слейвами не совсем. Доков нету нихуя, но со своим китайским софтом на иероглифах оно как-то работает как слейв, так что бомбить его в этом режиме не надо, оно само дергает мастер в случае какого-то события.
Хз, можно было бы и с wireshark-ом посидеть поглядеть, думаю там все предельно просто.

 

[Das Zugunfall]

возиться с красноглазыми средствами разработки под ЕСП, которые нихера не юзерфрендли.

А шо, ардуино для ESP32 не придумали еще?
Я просто с ним не работал еще, на 8266 застрял.
Хотя в board manager-е вроде попадался он мне.

 

[Гість 3253]

Справедливости ради, это говнореле может быть TCP мастером, TCP слейвом, UDP мастером и UDP слейвом. С мастерами все понятно, а вот со слейвами не совсем. Доков нету нихуя, но со своим китайским софтом на иероглифах оно как-то работает как слейв, так что бомбить его в этом режиме не надо, оно само дергает мастер в случае какого-то события.
Хз, можно было бы и с wireshark-ом посидеть поглядеть, думаю там все предельно просто.

Таки чито вi думаiте про концепцию?
Ну, допустим, Rust (я так и не понял почему еликсир может держать дохуилион коннектов... за счёт чего). Он быстрый и не требует среды выполнения (как его под красноглазым запускать - пока не понял, но, по идее - должен работать, он же бинарь?)

Что в расте с БД? Через что работает и какие драйвера использует? Надож будет организовать привязку издатель-подписчики, аккаунты для этого всего (чтобы как-то классифицировать вообще узлы, кому что принадлежит) и какие-то сценарии (или для сценариев подключать плагин?).

 

[Гість 3253]

А шо, ардуино для ESP32 не придумали еще?
Я просто с ним не работал еще, на 8266 застрял.
Хотя в board manager-е вроде попадался он мне.

Придумали, но я тоже с ним пока не работал. Говорят, вроде, пашет. Но телефон с вайфаём и BT сейчас можно купить не на много дороже, чем борду с ESP32.
Можно с ESP даже Z-Wave/Zig-bee прикрутить, или что угодно, у чего есть UART на выходе. Да и не запрещает ни чего сделать и ESPшный девайс, я ж концептуально хочу, чтобы можно было вообще любую существующую дряни прикрутить