Всё работает. Пароли... ключи доступа... генерируются генератором случайных чисел и сохраняются на флешке. Вторая копия Пароли... ключи доступа... сохраняются на любом гаджите (ПК... телефоне...), с которого мы управляем умным домом. Ещё можно загружать на сервер и скачивать любые файлы... Тоже всё должно сохраняться на флешке. Можно подключить видеокамеру (с поддержкой JPG). Тоже можно всё сохранять на флешке. Ещё сервер показывает все ошибки... Тоже всё сохраняется на флешке и в епром. Ещё надо добавить .log файлы. Тоже всё должно сохраняться на флешке. Сервер определяет с какого IP было подключение. Дату, время подключения... может сохранять все команды... и т.д. Еще наверное надо добавить белый / чёрный список IP адресов доступа к серверу... Тоже всё должно сохраняться на флешке. Не знаю что ещё добавить...
Всё это прекрасно, но есть одна проблема... Не очень удобно работать через браузер. Для постоянного контроля за умным домом, браузер должен постоянно опрашивать сервер умного дома. Сейчас опрос делается автоматически, по таймеру (можно опрашивать каждую секунду, каждый час, каждые сутки... и т.д.). Только при слишком частом опросе сервера умного дома получаем большой трафик. Это хорошо когда интернет безлимитный... а если нет ? )) Можно конечно опрашивать сервер реже, например раз в час... но тогда в случае аварии в доме мы об этом узнаем через час)) Да и чтоб постоянно работал браузер... тоже идея не супер.
Короче... надо организовать связь с умным домом по другому. С автоматическим оповещением в случае аварий и т.д. В общем переходим к плану "Б")) И тут нам на помощь приходит Java машина. ))
Проблема в том, я не очень хорошо разбираюсь в Java... поэтому сразу может не всё получится))
Интересно... тут на сайте есть Java-программисты ??? Если что поправьте меня))
Короче.. качаем вот такую интересную программку...
Запускаем программку... Java работает по протоколу TCP и UDP. А так же с COM портами всякими... и т.д. Нам нужен протокол UDP. Подключаем библиотеки всякие для UDP. Открываем сокет... Добавляем окна всякие...
Далее... добавляем библиотеки всякие... java.awt.*; javax.swing.*; Получилось типа простенькое Java приложение... типа "мессенджер"...)) для связи с сервером Умного Дома)) Проверяем как всё работает... Пишем Hello и нажимаем кнопку отправить...
АААААА... !!!! Говорящий Умный Дом !!! Не Алиса пока... но считать уже умеет)) (Яндекс.Станция — умная колонка с голосовым помощником Алисой).
Да, с протокол UDP трафик намного меньше. И работает заметно быстрей)) Экономит время и деньги)) Не зря ещё в далёком 2012 году Гугл решил выпустить браузер с протоколом UPD. https://ru.wikipedia.org/wiki/QUIC
Для постоянного контроля за умным домом, браузер должен постоянно опрашивать сервер умного дома.
Неясно зачем. Трудно представить, что кто-то будет держать на компе всегда открытое окно связи с сервером дома. Почему пользователю просто не запросить состояние сервера, явно послав в него соответствующий запрос? А в случае аварии сервер может послать емайл и/или SMS пользователю. Если у Вас другая идея коммуникации с пользователем, полезно здесь её изложить, иначе понятно только Вам чего добиваетесь.
Насчёт UDP также неясно чего добиваетесь. Если сервер на WIZnet чипе или ESP32, ему всё-равно что обрабатывать - UDP или TCP. Или обслуживающая программа в Мегу не влезает? Если так, давно пора уйти от игрушечных МК. С точки зрения Java приложений - тоже разница небольшая. Я прикрепил простенькие Java программки TCP/UDP сервера/клиента. Сократить объём траффика? Если комп в домашней и лимитной сети, то внутренние соединения на трату лимита не влияют. Если внешний, то разница в траффике между UDP или TCP также небольшая. Да, в UDP нет пакетов подтверждения, установки/разрыва соединения и пр., но это мелочи. Да, TCP хедер использует 20 байт против 8 у UDP, но это тоже мелочи, т.к. в любом случае к пакету добавится ещё хедер IP (20 байт) и хедеры нижних урвней стека, ещё меньше снижающие экономию. Зато при UDP лишитесь многих преимуществ TCP. Для управления сервером из домашней сети это скорее всего не важно, но если соединитесь извне, то многие Firewalls в организациях блокируют UDP пакеты, если только они не жизненно необходимы (например, DNS или NTP). Многие internet-radio станции, вначале вещающие на UDP с развитием сетей давно перешли на TCP. Вообще, UDP имеет смысл для приложений, толерантных к потере отдельных пакетов. Если это недопустимо, то функции надёжной передачи пакетов при UDP должно взять на себя приложение.
Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.
Если у Вас другая идея коммуникации с пользователем, полезно здесь её изложить, иначе понятно только Вам чего добиваетесь.
Идея простая - всегда быть на связи с домом. )) Сейчас у меня сервер на WIZnet чипе. Моему серверу без разницы UDP или TCP... и МК тоже без разницы)) Траффик - это не самое важное. Хотя тоже важно)) Но мне больше нравится UDP, потому что с ним проще работать и UDP протокол не чувствителен к задержкам. Можно передавать быстро... а можно меееееееееееееееедленно... хоть целый день)) Например по радиоканалу... Тайминги, и ACK мы устанавливаем сами - программно. Это не проблема.
Ser60 писал(а):
А в случае аварии сервер может послать емайл и/или SMS пользователю.
На первом месте связь по Интернет. Потом GSM, емайл и/или SMS... и т.д.
Ser60 писал(а):
Трудно представить, что кто-то будет держать на компе всегда открытое окно связи с сервером дома.
Не обязательно держать на компе всегда открытое окно связи с сервером дома. Java может работать и в "фоновом режиме". И в этом "фоновом режиме" Java может сама следить за связью с домом. И сообщать нам при потери связи с домом...
Вот я для примера написал простенькое Java приложение... в качестве эксперимента)). Java запускается в ручную или автоматически при загрузке WINDOWS на компе.
Как это работает (пока просто мысли): 1- Сижу я значит за компом (дома или на работе или в другом месте) и читаю "радиокот", а в это время Java слушает порты компа в "фоновом режиме". Это видно в диспетчере задач. Никаких окон нет))
2- И тут вдруг дома что-то случилось... Тут же прилетает UDP пакет на IP моего компа (дома или на работе или в другом месте). Java переходит в "активный режим" и появляется БОЛЬШОЕ ОКНО на весь экран монитора )) АВАРИЯ !!! Такое сообщение трудно не заметить ))
Затем нажимаем кнопочку "В фоне" и Java переходит в "фоновый режим". И я дальше читаю "радиокот", а в это время Java слушает порты компа в "фоновом режиме".
Если не нажать кнопочку "OK", то сервер умного дома не получит подтверждения и будет дальше отправлять UDP пакеты по всем IP адресам... из списка)) - IP ..... дом - IP ..... работa - IP ..... телефон Если сервер умного дома не получит ответа по IP, то будет звонить мне на телефон... из списка)) +7......... дом +7......... работa +7......... телефон и т.д.
Кратко как-то так)) Браузер так не умеет))
К стате... Java кушаем совсем мало ресурсов системы... в 10 раз меньше браузера. Вообще не нагружает систему...
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
Продолжим..)) Провозился с портами всякими.. оказывается Java не может одновременно оправлять и принимать на один порт... А наш сервер может. Ну и ладно)) Откроем разные порты... на приём и передачу...
Короче... добавил всплывающие окна)) Алгоритм простой: запускаем приложение... появляется консоль... Это Java слушает входящий порт...)) можно что-нибудь написать серверу... ))
При этом Java автоматом отравляет серверу подтверждение что сообщение получено не ещё не прочитано. Вообще окон может быть бесконечно много... Java парсит все входящие сообщения и решает что делать... открыть отдельное окно "сообщение" , "авария" , "срочно !"... или может перенаправить пакет дальше (режим ретранслятора). Короче любые сценарии)) Далее пишем что-нибудь серверу... бла-бла-бла... )) Или просто нажимаем кнопочку "прочитано". Отправляем серверу подтверждение, чтобы сервер знал что сообщение прочитано и не волновался )) Иначе сервер начнёт нам звонить на телефон... +7... )) Далее приходит подтверждение от сервера. Сервер нас услышал))
И т.д. и т.п. Короче... Java может обрабатывать любые сценарии... алгоритмы... Может работать как простой мессенджер... как скайп)) Может работать как ретранслятор пакетов... Как сервер... Можно подключить все устройства в доме: телефон <> ПК <> планшет <> сервер. Все устройства будут общаться между собой. Получится большой Java чат ! и т.д. и т.п. Короче фиг его знает что ещё придумать)) Такая вот умная у нас Java машина)) Хотя наш сервер всё равно умнее))
Надо ещё подумать... а что если IP динамический ? Тут будет свой, отдельный сценарий))
Если коротко, я сейчас нахожусь на стадии тестирования Варианта 1 Сервер на esp8266 (комуникация с хозяином через телеграм)информирование+управление (с остальными устройствами через mqtt) Остальные устройства esp 8266(разних назначений)
Может и в mqtt есть свои недостатки (но простота понимания-применения их всех затмивает) Потому если глобально посмотреть, надо делать комуникацию всех машин сугубо через Mqtt.
Потому я сейчас провожу разного рода експеременты с готовыми fbd пользовательскими блоками под 8266. Пробую утопить esp в кучи разного рода задач (пока не могу) Время покажет,пока нету задачи которую я не смог выполнить (позавчера захотел погноз погоды в телеграм по запросу) Нашол блок, зарегилса на сайте, добавил в проэкт и все заработало с пол пинка.
Я не знаю на щот слейвов, но мастер только на FLprog+8266 Потому что если писать все то что я сейчас имею и могу с нуля надо писец сколь ко времени и нервов. А это как раз то что не вернешь и не востановишь ни когда
_________________ И опыт сын ошибок трудных и гений парадоксов друг
Я сейчас вижу все так, будет брокер в этом зверьке https://item.taobao.com/item.htm?spm=a1 ... 1674155711 https://www.youtube.com/watch?v=ADBct61 ... ex=15&t=0s _____ А дальше можно по разному,я сейчас пробую и так и сяк.(подбираю по надежности и по удобности) _____ Разного рода боты, телеграм-вайбер, сейчас очень популярны и пипец какие удобные. _____ Esp8266-нормально прошивается по воздуху,имеет стабильную веб морду во внутриней памяти. (с кучей всего внутри забито всего половина памяти)и то что она забита никак не влияет на работу. _____ Mqtt-ещо удобен тем что под андроид есть кучя удобных, интуитивно понятных клиентов. _____ Кароче говоря, планов много времени мало.
_________________ И опыт сын ошибок трудных и гений парадоксов друг
Но одновременно на приём и передачу один сокет не работает... Не возможно вызвать sock.send(); пока работает sock.receive();...
Неверно. Вы если чего-то не понимаете или не знаете, сформулируйте Ваши высказывания в виде вопроса. Иначе кто-то может воспринять Ваши заблуждения как истину в первой инстанции. Я выше подал идею насчёт потоков, но Вы не неправильно её имплементировали. Интернет забит дискуссий на тему full-duplex приложений на Java сокетах. См., например, здесь
Неверно. Вы если чего-то не понимаете или не знаете, сформулируйте Ваши высказывания в виде вопроса.
Как вызвать sock.send(); пока работает sock.receive();... ? )) Вызов метода receive () блокирует выполнение программы на неопределенный срок до получения пакета... IOException: Address already in use: Cannot bind (Адрес уже используется: не удается привязать).
Интернет забит дискуссий на тему full-duplex приложений на Java сокетах. См., например,
Это для TCP. А UDP работает иначе...
А пока работает так: есть два независимых сокета (условно): - сокет 1 работает на передачу (в потоке Thread 1). - сокет 2 работает на приём (в потоке Thread 2). Т.к. сокеты и потоки независимы, то один другому не мешает))
Правда могут быть проблемы с NAT... т.к. исходящие и входящие порты не совпадают)) а могут и не быть)) Надо проверять... А вообще надо более подробно изучить работу сокетов в Java. Как работают сокеты в W5500 я знаю точно и подробно, а как работают сокеты в Java... я представляю пока ещё не до конца...
Короче... нигде вразумительного ответа по сокетам не нашёл... Это надо ковырять библиотеки Java... Ну ладно)) Тогда будем использовать отдельные сокеты на приём и передачу... в отдельном потоке)) В Java количество сокетов и потоков - не ограничено)) В W5100 - 4 независимых сокета. full-duplex В W5500 - 8 независимых секетов. full-duplex Короче... с количеством сокетов у нас проблем нет))
Добавим часики... )) Java принимает все входящие пакеты... Автоматом всплывают разные окна... К пакетам автоматом добавляется IP, порт, дата и время когда был отправлен / принят пакет (всё берём из компа).
Я не видел полного кода, но полагаю, что у Вас имеется один поток на приём и другой - на передачу. Это правильно. Однако, неясно почему в одном потоке задействован номер порта 80, а в другом 81. Согласен, что если создавать сокеты в потоках, то их нельзя будет назначить на один и тот-же порт. Значит, следует создать один сокет в стартовой программе вне потоков и передать его потокам, например чераз паракетр конструктора потока. Таким образом, управляющая программа содзаст сокет и потоки на приём и передачу, запустит их и потом terminate. А оба потока будут продолжать использовать созданный ей сокет. Я попробовал таким образом, у меня всё работает.
-контрольная сумма заголовка протоколов UDP, DHCP, DNS, TCP... 0000. -контрольная сумма самих протоколов UDP, DHCP, DNS, TCP... False. При этом всё работает.)) Остаётся только контрольная сумма самого Ethernet пакета (CRC-32), но в этом Windows не участвует. Этим занимается сетевая карта компа. Мда... я так понял все дружно забили на спецификацию Ethernet)) и в первую очередь сам Microsoft)) Ну и ладно. Тогда и мы можем отключить контрольные суммы в нашем сервере)) Нашему серверу меньше работы.
Вот пример кода UDP сервера и клиента. Сервер в main() создаёт сокет и placeholder пакета для передачи клиенту и передаёт это потокам приёмника и передатчика. Таким образом, они используют один и тот-же сокет. Приёмный поток по приёму пакета клиента формирует в общей области памяти пакет для передачи передающему потоку. Передающий поток сканирует длину пакета раз в секунду и как только она станет ненулевой, передаЁт пакет обратно клиенту. Приложение клиента однопотоковое. В цикле оно запрашивает пользователя ввести строку для передачи серверу. После передачи переключается на приём ответа от сервера с выдачей номера порта полученного пакета на передающей стороне, из которого следует, что клиент передаёт пакет и получает ответ с того-же порта сервера. Номер рабочего порта сервера для демонстрации выбран фиксированным (=9876).
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 29
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
