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

Reset сказав(ла):
я так и не понял почему еликсир может держать дохуилион коннектов... за счёт чего
Натисніть, щоб розгорнути...
Я в такие дебри не углублялся, думаю что благодаря легендарным легковесным процессам эрланга, которые молниеносно стартуют и имеют memory footprint что-то около нескольких десятков байт на каждый. Плюс, механизм супервайзоров, который мгновенно рестартует что-то, если оно вдруг упало.
И пару лямов коннектов на одном физическом серваке, это вроде не маркетинговые пресс-релизы всяких пейсбуков, что вот мол нам удалось кардинально повысить показатели нашего чата, после перехода на эрланг, а реально подтвержденный тестами факт.
Тільки зареєстровані користувачі бачать весь контент у цьому розділі

Reset сказав(ла):
Что в расте с БД? Через что работает и какие драйвера использует?
Натисніть, щоб розгорнути...
Думается, со всеми мейнстримовыми СУБД оно работает.
 
Reset сказав(ла):
Но телефон с вайфаём и BT сейчас можно купить не на много дороже, чем борду с ESP32.
Можно с ESP даже Z-Wave/Zig-bee прикрутить, или что угодно, у чего есть UART на выходе. Да и не запрещает ни чего сделать и ESPшный девайс, я ж концептуально хочу, чтобы можно было вообще любую существующую дряни прикрутить
Натисніть, щоб розгорнути...
Так оно все вифи-шное.
А ты ж, я так понял, хочешь солюшн, который будет работать на любом железе, хоть на виндовом десктопе, хоть на openwrt роутере, хоть на тилипоне?
Думаю, раст - самый подходящий варик для этого.
Бо эрланг-машине на каком-нить дешманском роутере может памяти и не хватить, хотя его собирал даже для покетбука:D
 
Skyggedans сказав(ла):
Так оно все вифи-шное.
А ты ж, я так понял, хочешь солюшн, который будет работать на любом железе, хоть на виндовом десктопе, хоть на openwrt роутере, хоть на тилипоне?
Натисніть, щоб розгорнути...
Не совсем так.
Я хочу солюшен, который будет работать на винде и линухе. Для сервера этого достаточно.
Я пробовал солюшен с сервером на мобиле приклеенной к стенке - такое/себе решение. Тупиковое. Сервер должен быть шустр и принимать максимально возможное число коннекшенов, так как, контроллеры IoT в большинстве случаев именно так и действуют - открывают коннект и висят в сессии. По наличию коннекта сервер определяет жив ли контроллер. Стоит ему отвалиться от сети - сервер его роняет. То есть - ни какого опроса контроллеров по таймеру нет - сессия перманентно открыта, надо ему слать что-то, или нет - не важно. Открывая коннекшен - контроллер сообщает серверу, что он живой и есть в мире. Контроллер является в этом случае клиентом.
Вот клиентом телефон - это да.
А сервером - не надо так делать. Плохо это. Хотя, и не исключен такой вариант, и можно даже его выложить на гитхаб, или соурсфорж - он некоммерческий по дефолту. Это любительское решение типа "це пан сам склепав".

Skyggedans сказав(ла):
Думаю, раст - самый подходящий варик для этого.
Бо эрланг-машине на каком-нить дешманском роуте может памяти и не хватить, хотя его собирал даже для покетбука:D
Натисніть, щоб розгорнути...
Ну раст так раст, хоть он и мозголомный... я посмотрел.
На данный момент надо архитектуру обдумать сначала.

Обернуть в абстракцию модбасного типа любой девайс и описать как совокупность входов, и выходов, ID склеивать из ID его нативного протокола+DeviceID - возражения есть?

Пока не решил что делать с их ивентами, надо по курить как во всех известных сетях происходит сообщение сенсора. З-вэйв, зигби и лоре.
Естьещё дофига разных 315/345/433МГц протоколов, на которых кнопки, дверные звонки и сенсоры всякие, они частично вообще неуправляемые и только ивенты генерировать могут, типа "кнопка нажата". Их нельзя опрашивать и у них нет ни каких входов и выходов... можно, конечно, рассматривать мессагу о нажатии, как изменение статуса выхода, но оно не континоус и будет неопределённость - мы знаем, что нажали, но не знаем, отпустили ли.
 
Reset сказав(ла):
Я хочу солюшен, который будет работать на винде и линухе. Для сервера этого достаточно.
Я пробовал солюшен с сервером на мобиле приклеенной к стенке - такое/себе решение. Тупиковое. Сервер должен быть шустр и принимать максимально возможное число коннекшенов, так как, контроллеры IoT в большинстве случаев именно так и действуют - открывают коннект и висят в сессии. По наличию коннекта сервер определяет жив ли контроллер. Стоит ему отвалиться от сети - сервер его роняет. То есть - ни какого опроса контроллеров по таймеру нет - сессия перманентно открыта, надо ему слать что-то, или нет - не важно. Открывая коннекшен - контроллер сообщает серверу, что он живой и есть в мире. Контроллер является в этом случае клиентом.
Вот клиентом телефон - это да.
А сервером - не надо так делать. Плохо это. Хотя, и не исключен такой вариант, и можно даже его выложить на гитхаб, или соурсфорж - он некоммерческий по дефолту. Это любительское решение типа "це пан сам склепав".
Натисніть, щоб розгорнути...
Любое вифишное решение, хоть тилипон, хоть есп - ущербно по сути, поскольку имеет вифи-модуль, заточенный на применение в клиенте с автономным питанием. И сам этот модуль в режиме AP может накладывать ограничения на количество и качество коннектов.
Тут нужен девайс с ethernet, воткнутый в хороший скоростной MIMO-роутер.
 
Skyggedans сказав(ла):
Любое вифишное решение, хоть тилипон, хоть есп - ущербно по сути, поскольку имеет вифи-модуль, заточенный на применение в клиенте с автономным питанием. И сам этот модуль в режиме AP может накладывать ограничения на количество и качество коннектов.
Тут нужен девайс с ethernet, воткнутый в хороший скоростной MIMO-роутер.
Натисніть, щоб розгорнути...

Ну так, по этому тилипон и отпадает.
ESP в этом плане тоже имеет проблемы.
Короче - остановимся на win+lin, без всяких андроидов, и не обязательно запускать нагруженный сервак на openwrt роутере.
Андроид - я уже сказал, возможен, как чисто солюшен для гитхаба и сорсфоржа, чисто еблеты свои засветить.
Я бы не хотел на нём концентрироваться.

Давай хоть общую структуру обдумаем.

Обёртка "на любой девайс", имеющая входы (bin, int, float) и выходы (bin, int, float) - вроде, должна всё описать. Есть ещё мнения?
 
Skyggedans сказав(ла):
По идее для начала достаточно.
Натисніть, щоб розгорнути...

Ща покурю ивенты.
Как будем конкретизировать девайс? UI будет требовать конкретики.
Я прокурю как адресуются устройства в разных сетях, но на сейчас я точно знаю, что и в лоре и в з-вэйве есть Home ID (в лоре Net ID), который описывает в звэйве - контроллер (и ,де-факто, одну частную сеть, так как в UI является следующим вложением после рута, а рутом дерева - аккаунт) в лоре - шлюз (и ,де-факто, тоже описывает одну замкнутую частную сеть).
В зигбе тоже какой-то идентификатор, описывающий какой-то кусок пространства, наверное, есть.

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

То есть, вырисовывается система:
Account->
NetID->
- DeviceProtocol+DeviceID
NetID->
- DeviceProtocol+DeviceID
...
- DeviceProtocol+DeviceID
...
NetID

Связка DeviceProtocol+DeviceID будет уникальной, даже если в каких-то двух стандартах окажется совпадающий DeviceID.

К девайсу, кроме его периферии, выраженной через входы, выходы, ивенты - надо прикрутить вспомогательную информацию для UI и драйвер.
В драйвере должны быть юниты и рэйнжи для небинарных входов и выходов(min, max, step (для выходов) и measurement unit) , и, возможно, описание для UI что это вообще - реле, розетка, лампочка, датчик.

Как будем оформлять это инишник на девайс? Можно файлами - тогда имплементация нового девайса будет заключаться в подкладывании файла в папку сервера. Можно в БД.
Я бы выбрал файлы.
Мнения?
 
Reset сказав(ла):
Как будем оформлять это инишник на девайс? Можно файлами - тогда имплементация нового девайса будет заключаться в подкладывании файла в папку сервера. Можно в БД.
Я бы выбрал файлы.
Мнения?
Натисніть, щоб розгорнути...
Ну да, файлами в джсоне, потом его без проблем можно будет в какую-нибудь монгу положить, если возникнет необходимость.
 
У зигби самая заморочная адресация.
В корне сети одновременно ID самой сети (PAN ID) и координатор, как физическое устройство.
Адрес координатора всегда 0x00. Разные координаторы не ссорятся, поскольку отличаются PAN ID. Даже находясь на одном радиоканале.
А дальше - там такой зоопарк, шо можно, если полностью поддерживать стэк зигби - подахуеть.
Там и кластера, и группы, и узлы
Каждый пакет должен содержать PAN ID (поле MAC), NwkAddr (поле NWK), адрес конечной точки приемника и передатчика, ID профиля и кластера (поле APS).
И... есть ещё профиля.
Каждая конечная точка содержит идентификатор профиля и идентификатор устройства. Как мы уже говорили, одно физическое устройство может представлять собой несколько устройств ZigBee. Идентификаторы устройств ZigBee принимают значения от 0x0000 до 0xffff (см. табл. 4). Идентификаторы устройств имеют двойное назначение. Они позволяют отображать на дисплее пользователя иконки, соответствующие типу устройства, и в то же время помогают сделать инструменты ZigBee более совершенными.
Натисніть, щоб розгорнути...

Ёбаный зоопарк... мне понадобится время, водка и кофе, чтобы понять как эту хуйню имплементировать :D

P.S. Я понимаю, что они "хотели как лучше", но... всё таки... ну нахуя так?
 
тут был уже?
Тільки зареєстровані користувачі бачать весь контент у цьому розділі
 
bclogin сказав(ла):
тут был уже?
Тільки зареєстровані користувачі бачать весь контент у цьому розділі
Натисніть, щоб розгорнути...

Нет.
ТРЕБОВАНИЯ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ
Скачайте и распакуйте образ HassOS для вашего устройства
Скачайте balenaEtcher для записи изображения на SD-карту
Натисніть, щоб розгорнути...
В устройствах
As an image for your device:

Raspberry Pi 3 Model B and B+ 32bit (recommended)
Raspberry Pi 3 Model B and B+ 64bit
Raspberry Pi 4 Model B 32bit (recommended)
Raspberry Pi 4 Model B 64bit
Tinkerboard
Odroid-C2
Odroid-N2 (Beta)
Odroid-XU4
Intel-Nuc
As a virtual appliance:

VMDK (VMWare Workstation)
VHDX
VDI
OVA (not available at this time!)
Not recommended Hardware:

Raspberry Pi
Raspberry Pi Zero-W
Raspberry Pi 2
Натисніть, щоб розгорнути...

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

Ну не то это...
P.S. На обычный Orange PI 3 (которого нет в списке, но есть у меня дома) - ставится тот самый пайтон, поскольку на него ставится тривиальная убунта. Хоть сервер, хоть десктоп. И запускай-нихачу. Для домашнего пользования тебе его хватит с головой.

P.P.S.
Оно видит только вайфайные устройства?
Походу - да. И я не нашел список поддерживаемой периферии.
Ну и всё, что коннектится к сети.

P.P.P.S Он даже так определяет присутствие людей дома. Сама по себе идея неплохая, но годится только для слежки за домочадцами... датчик присутствия, который "это" поддерживало бы - я не нашел.
 
Сцууукоооо... эт я про зигби читаю.
Кроме того, устройствам, работающим на ZigBee, в обязательном порядке должен быть присвоен один из стандартных профилей назначения:
- мониторинг предприятия
- автоматизация коммерческих помещений
- телекоммуникация
- амбулаторное или стационарное лечение
- дополнительные измерения

Профили необходимы для обеспечения совместимости устройств от разных производителей без предварительной настройки. Если профили устройств не совпадают, то работать друг с другом они не смогут.
(и тут вишенка на торте (ред.))
Однако, как показывает практика, даже совпадение профилей не гарантирует абсолютной совместимости, поскольку чипы с поддержкой ZigBee выпускаются несколькими разными компаниями, которые могут назначать спецификации профилей по своему, или оптимизировать работу протокола
Натисніть, щоб розгорнути...

Шитоблядь? :рл:
Не, ну я понимаю, что писатель - не всегда читатель, но... эндпоинт в зигби не может передавать данные другому эндпоинту. Только шлюзу в корень. О какой совместимости он волает? Кто-то сталкивался?
 
Оебать, руст жеш по конченому сделан...
Как его вообще компилировать? Из под VS Code - какой-то пиздец... Если положить файл в папку куда установлен сам руст (в .cargo/bin) - запускается, но требует Cargo.toml в той же папке.
Из другой папки - не запускается, потому, что... внимание... не может открыть файл... который уже открыт!!!
Так и пишет
Running] cd "f:\proj\Rust\test1\" && rustc test1.rs && "f:\proj\Rust\test1\"test1
error: couldn't read test1.rs: Не удается найти указанный файл. (os error 2)

error: aborting due to previous error


[Done] exited with code=1 in 0.084 seconds
Натисніть, щоб розгорнути...

Как вообще правильно проект там создавать? А как подключать другие файлы потом?


Скаааай!! Это ты раст предложил! :D Шо дальше с этим пиздецом делать-то?
1596455527e249100983.jpg

Прога запускается, к стати, это какой-то примерчик первый попавшийся, который порт на локалхосте слушает
Код: 
use std::net::{SocketAddrV4, Ipv4Addr, TcpListener};
use std::io::{Read, Error};

fn main() -> Result<(), Error> {
    let loopback = Ipv4Addr::new(127, 0, 0, 1);
    let socket = SocketAddrV4::new(loopback, 0);
    let listener = TcpListener::bind(socket)?;
    let port = listener.local_addr()?;
    println!("Listening on {}, access this port to end the program", port);
    let (mut tcp_stream, addr) = listener.accept()?; //block  until requested
    println!("Connection received! {:?} is sending data.", addr);
    let mut input = String::new();
    let _ = tcp_stream.read_to_string(&mut input)?;
    println!("{:?} says {}", addr, input);
    Ok(())
}

Если полезть на предложенный порт - пишет Connection received! V4(127.0.0.1:49935) is sending data.
Это неправильно, так как в сообщении:
Listening on 127.0.0.1:49889, access this port to end the program
А она не завершается при этом. Только если ещё раз зайти - завершается.

В варнингах следующее:
Код: 
Unknown RLS configuration:
 `action_on_save` ,
`action_on_starting_command_if_there_is_running_command` ,
`build_args` ,
`cargo_cwd` ,
`cargo_env` ,
`cargo_home_path` ,
`cargo_path` ,
`check_args` ,
`clippy_args` ,
`custom_build_configurations` ,
`custom_check_configurations` ,
`custom_clippy_configurations` ,
`custom_doc_configurations` ,
`custom_run_configurations` ,
`custom_test_configurations` ,
`doc_args` ,
`execute_cargo_command_in_terminal` ,
`mode` ,
`racer_path` ,
`rls` ,`run_args` ,
`rust_lang_src_path` ,
`rustsym_path` ,
`rustup` ,
`show_output` ,
`test_args`
 
RLS это language server, всякая хрень для IDE, типа автокомплита, к сборке отношения не имеет.
Проект надо через cargo создавать, тогда он сам нормальный конфиг сгенерит.
Я в VSCode тока с ним игрался, в студии еще не пробовал.
 
Skyggedans сказав(ла):
RLS это language server, всякая хрень для IDE, типа автокомплита, к сборке отношения не имеет.
Проект надо через cargo создавать, тогда он сам нормальный конфиг сгенерит.
Я в VSCode тока с ним игрался, в студии еще не пробовал.
Натисніть, щоб розгорнути...

Это и есть VS code
Что значит через карго? Там описания кривые шопиздец, если вообще есть.
1371683044_pilot.jpg
 
Но давай, всё же, про архитектуру, пока я курю адресацию и пытаюсь придумать абстракцию для разных типов сетей.

Самая большая скорость у ZigBee - 250кбит, реально, с учётом коллизий и отработки ячеистой структуры - не больше 70 кбит.
У остальных - по меньше - 40 кбит/20 кбит

То есть, обычный куйс для IoT сети - большое количество хабов с постоянно открытым соединением, но, при этом - низкая плотность данных. 100 пользователей не сожрут даже мегабит канала, и это если они все одновременно сойдут с ума, начнут нажимать все подряд кнопки со скоростью автомата, а также будет 10 раз в скеунду происходить смена времени суток, пожар, землетрясение, и двери станут самостоятельно хлопать.

Какую архитектуру посоветуешь для такого типа сети? Много постоянно открытых коннектов с низким/умеренным потоком данных.
 
Ви повинні увійти або зареєструватися, щоб відповісти.
Назад
Зверху Знизу