В общем вполне возможно я не прав, непонимая прелестей использования MQTT клиентом, но то, что по нагрузке на сервер как минимум в реализации брокера mosquito он ничуть не легче, а возможно даже тяжелее MySQL будет - это факт.
Ну вот и чудненько - несознанка просветляется, оказывается, MQTT уже не так плох. Однако, мы продолжаем путать мух с котлетами - зачем-то сравнение MQTT с реализацией брокера, и с MySQL. Не надо сравнивать круглое с мягким.
Далее: прекращаем ментально онанировать на то, какой мемкеш няшный, а вместо этого - берём, и пишем простенького брокера MQTT, который будет хранить данные где? Правильно, в мемкеше. На выходе получаем блекджек со шлюхами.
Еще, если я верно понял, подписанному на сообщение клиенту брокер MQTT будет рассылать данные вне зависимости нужны они ему или нет
Нет, ты понял неверно. Брокер рассылает данные подписчикам, ключевое здесь - подписчик. Т.е. если ты не подписался на топик - брокер тебе ничего не пришлёт. Т.е. ты подписываешься только на интересующие тебя данные. Не нужны больше данные - отписался, делов-то. Плюсом ко всему - без плясок с бубном, у топика есть флаг retained, сие значит, что как только ты подконнектился и подписался на топик - брокер вышлет тебе последний полученный интересующий тебя топик. Такой вполне себе механизм "last known data" получается, искаропки. Зацени.
Arhat109-2, ну дайте типовое определение, чем является "прошивка" NodeMCU в микроконтроллере, учитывая, что её функционал явно выходит за рамки классического BIOS?
Вам не нравится компот технологий и Вы предпочитаете вылеззанный код исключительно на С - Ваше право, а вот я не вижу смысла чесать левой ногой правое ухо, изобретая на С или тем более перле сервера для тех или иных задач, когда на том же С написаны решения под каждую из них, и они замечательно согласуются между собой. И я искренне не понимаю с чего Вы взяли, что рукодельный код Ваш будет работать быстрее и стабильнее чем та же связка Nginx как вебсервера, MySQL как базы, php для формирования html страниц, perl в кроне для выполнения регулярных задач, и пресловутый Memcached или кому нравится mosquitto для передачи данных и управления "датчиками"?
Всё изобретено (украдено) давно до вас, не переживайте. Просто Вы пытаетесь использовать свой компот, потому что он Вам больше понятен. Никто же не мешает, пользуйте на здоровье! Просто не надо его навязывать всем остальным как единственно верный, на что Вам уже указали выше.
Работать она будет гарантированно шустрее, а равно как будем жрать меньше ресурсов. По одной простой причине: в ней миниум кода "помазанного поверх" того что работает везде одинаково (билиотеки нижнего уровня). И да, компактней чем хранение в банальном массиве Си - у Вас не получится. Сброс массива в файл - это что делает скуль .. как и чтение туда-сюда непрерывно. Вот, без всего этого МОЖНО обойтись, но не Вам как "недопрограммисту".
Без обид только. Но именно про это и писал wdrakula.
ТС - типичный представитель недокодера, что в последнее время становится агрессивным. Вы это хорошо могли почитать на форуме амперки в топике "пост негодования" про чудо-плату "Искра + JS", где 0.007% от базовой эффективности микроконтроллера выдается за "верх технологий". В нулях - не ошибся, это по даташиту Espruino, лежащей в основе, ежели вчё.
Просто плавая по верхам стеков и технологий, они как выясняется понятия не имеют что под этим стеком находится. Что тот же memcached внутри себя хранит все в банальных массивах той или иной структуры и общается всё через ту же библиотеку TCP/IP, писанную в незапамятные времена .. да и ЗАЧЕМ? Это же надо разбираться, а это "порог вхождения". Куда проще обучение "обезьяним методом".. плохо то, что они становятся все агрессивней. :(
DIYMan, походу я всё верно понял, что подписавшись, та же ESP как клиент будет постоянно "атакована" данными от брокера вне зависимости нужны они или нет, для получения управляющих сигналов исполнителями, той же ESP-хе которая эмулирует пульт кондиционера, это хороший вариант, судя по loop() в https://github.com/knolleary/pubsubclient/blob/master/src/PubSubClient.cpp отрабатывающая мгновенно, не гоняя трафик на лишние запросы, лишь пингуя периодически, еще и с удобным вызовом callback для обработки сообщения, при этом как я понимаю, на одно сообщение от MQTT брокера может быть подписано сколько угодно клиентов и каждый это сообщение получит. В общем в этой задаче, соглашусь, что MQTT намного удобнее, пусть даже и тяжелее, пусть даже с диском работает, управляющих комманд реально 1 / 1000 не наберется, относительно передачи показаний датчиков. Так же, если надо одним "датчиком", срочно дать команду другому, то MQTT тоже вариант идеальный.
А вот для задачи постоянной передачи показаний с датчиков с эпизодической их визуализацией в том же веб-интерфейсе, ИМХО всё таки рациональнее ненавистный некоторым участникам дискуссии memcached. Потому как с одной стороны данные в идеале должны обновляться чуть ли не раз в секунду, с другой стороны востребованы они либо для записи в журнал, по той же температуре не чаще чем раз в 10 минут, либо когда открыта страница генерируемая PHP.
Конечно можно на том же PHP при форировании страницы веб-морды послать устройствам через брокера команду "срочно предоставить данные по показаниям датчиков", но вот тут если честно надо эксперементировать, так как лично я не вполне понимаю с какой скоростью это будет происходить, особенно если датчиков больше двух десятков. Есть конечно вариант отправлять команду предоставить данные при формировании веб страницы не дожидаясь обновления данных, а сами данные забирать через json запрос ко времени запуска которого на браузере данные должны будут подойти, и каждый json заставлять датчики предоставлять данные, чтобы было обновление данных в реальном времени без перезагрузки страницы и только пока такая страница открыта, это опробую.
Но как альтернативный вариант - всё таки сделаю для сравнения и постоянную передачу через перманентно открытый сокет данных показаний датчиков от ESP на memcached, узкое место в этом случае только канал связи, но ИМХО даже 100 датчиков, даже раз в секунду передавая данные, едва ли как-то повлияют.
Еще раз хочу отметит, что как я написал изначально, в этой теме я новичок, и поднял я тему memcached не просто так, а потому что когда я пришел на форум в топе была вот эта тема http://arduino.ru/forum/programmirovanie/esp8266-kak-schitat-dannye-s-saita и относительно её, тема использования memcached ИМХО выглядит более чем логично.
берём, и пишем простенького брокера MQTT, который будет хранить данные где? Правильно, в мемкеше. На выходе получаем блекджек со шлюхами.
А вот это уж точно лишнее, и уж если писать своего брокера, то в его памяти, как советовал учитель-перфекционист, и хранить тогда, нахрена брокеру внешнее хранилище, пусть даже очень шустрое, учитывая, что перезагрузка маловероятна, а при вырубке электричества в дома, даже если малинка без бесперебойника будет то ESP и Arduinки тоже лягут и данные будет хранить просто не для кого.
Уже кусаются. Зайдите на амперку в раздел флудилка и перечитайте топик "пост негодования".. особенно к концу, где меня нагло заблокировали увеличив время отклика сервера на от 18 до 30+ секунд с потерей соединений. Только после того как через фейсбук обратился публично к руководству амперки - блокировку сняли.
Вот такая она вот "амперка" теперь.. спонсор детских соревнований .. :(
Блеать! Это можно как-то остановить? Может на него Св. водой побрызгать? ;) ;) ;)
Или удавку из Св. Пары? (кат. 6е, ессно)
Почему в России столько творческих людей? Иногда хочется им фенозепам раздавать, что б спали и не трогали никого.
-----------------------------------------------
Дорогой, почитай о текущем состоянии дел с проектированием умных домов-сараев-теплиц-курятников и собачьих будок.
Есть уже сложившиеся традиции (где-то - уже даже стандарты), которые помогают обеспечить совместимость узлов разных производителей.
MQTT - одна из них, связь по 485 - еще одна... и т.д. Внутри помещения используется проводная связь, даже не потому, что куча мелких ВиФи устройств засрет канал, не засрет, если не часто, - просто потому, что любому датчику или исполнительному соленоиду-серве-шаговику - нужно питание. А значит проще протянуть сигнал проводом, если питание все равно тянуть.
Если ты планируешь делать уникальное устройство только для своего дома - да хоть как, ЕСП8266, мемкешед и прочее. Практическая ценность - чисто хоббийная - самореализация. Это неплохо, почти всегда хобби это удовольствие от самореализации.
Практической цели в тиражировании устройств, разработанных не "в тренде" - нет никакой. Поэтому я и пишу в 100500-й раз:
Нормальное твое решение, пиши, строй свой умный дом, потом в "Проектах" расскажешь, только митинговать кончай!
А вот это уж точно лишнее, и уж если писать своего брокера, то в его памяти, как советовал учитель-перфекционист, и хранить тогда, нахрена брокеру внешнее хранилище, пусть даже очень шустрое, учитывая,
DIYMan, походу я всё верно понял, что подписавшись, та же ESP как клиент будет постоянно "атакована" данными от брокера вне зависимости нужны они или нет,
Нихера ты не понял, зануда. Ещё раз: ПОДПИСАЛСЯ - данные от брокера пошли. ОТПИСАЛСЯ - данные от брокера не идут. Подписываться/отписываться можно мульён раз, до посинения. Ферштейн?
Атакована, мля, ага. Идиотия твоего занудства просто зашкаливает.
А вот это уж точно лишнее, и уж если писать своего брокера, то в его памяти, как советовал учитель-перфекционист, и хранить тогда, нахрена брокеру внешнее хранилище, пусть даже очень шустрое, учитывая,
Message QOS => 0
Тсс, чукча же писатель, он так нихера ничего по MQTT не прочитал, а ты ему пытаешься межушный ганглий разорвать :)
b707, ну так давно бы вышли с топика, вместе с Arhat109-2, DIYMan и wdrakula, но вашему квартету походу просто в кайф пытаться самоутверждаться на человеке который в ТС прямо заявил что в теме новичок, что ардуина первый дань в руки попала на момент ТС, но по делу пишет один sadman41.
К вопросу пишется ли на диск что-то при QoS 2 - зависит от реализации брокера, в частности если это mosquitto, то в конфиге прямо сказано:
autosave_interval second
The number of seconds that mosquitto will wait between each time it saves the in-memory database to disk. If set to 0, the in-memory database will only be saved when mosquitto exits or when receiving the SIGUSR1 signal. Note that this setting only has an effect if persistence is enabled. Defaults to 1800 seconds (30 minutes).
Одной этой строчки достаточно было бы, если бы были реальные гуру, а не неистовый квартет теоретиков. То есть в конфигурации autosave_interval=0 превращает затею с memcached в абсолютно бессмысленную если применять этого брокера, без всяких фантазий на тему "пишем брокера...". Хотя и это не нужно, так как сброс базы на диск раз в 30 минут не проблема даже в случае с SD картой, но опять же гуру то не нашлось, который бы написал, что брокер не хранит данные на диске, как тот же MySQl, а лишь периодически пакапится на диск... При этом для ускорения-упрощения процесса передачи данных, сохранность которых похрену, QoS = 0 самое то и по логике является по части отправки 100% аналогом memcached, к тому же с функцией рассылки если надо.
При этом "гуру" обсудили что угодно, от качества студентов, до блокировки преподавателя на амперке, может не зря его там забанили?
И специально для DIYMan, если бы Вы были внимательнее, то увидели бы в #55 что прочитал я не только мануал, но и сорцы клиента внимательно, и грешным делом настройки нашел тоже в сорцах, где само название функции persist__backup навело на мысль, что данные не хранятся на диске, как я ошибочно предполагал, а лишь бакапятся. Так что Ваши возмущения на тему того что я не понял, что подписка отменяется - напрасны.
Так, что sadman41, огромное спасибо за конструктив и человеческое общение, а тему эту можно смело закрывать за нецелесообразностью в таком варианте использовать memcached вообще.
И специально для DIYMan, если бы Вы были внимательнее, то увидели бы в #55 что прочитал я не только мануал, но и сорцы клиента внимательно, и грешным делом настройки нашел тоже в сорцах, где само название функции persist__backup навело на мысль, что данные не хранятся на диске,
Ну я ж и говорю - чукча писатель. Вместо того, чтобы просто полезть и посмотреть настройки того же москита - чукча развёл тут бессмысленный трёп. Пеняя на то, что ему кто-то что-то там должен помнить наизусть все настройки москита. Есть у него настройка интервала сбрасывания данных на диск? Чудненько, ты открыл для себя новое, мемкеш не нужен, тема - бессмысленна.
Правильно излагать свои мысли - ты не умеешь, я тебе указал на твой бред по поводу "ESP как клиент будет постоянно "атакована" " - ты вильнул хвостом совсем в другую сторону. Считаешь, после такого с тобой можно общаться конструктивно? Отнюдь.
Слава богу, что эта бредовая тема уже дохнет. Мозговой онанизм, помешанный на дилетанствующем энтузиазме, иногда и не к таким многостраничным высерам приводит. Аминь.
DIYMan, вот это с Вашей стороны попытка выстроить хорошую мину, при очевидно плохой игре. Настройки конечно наизусть никто не помнит, особенно если давно работаешь с чем-то и конфиги стабильные годами, но вот принцип работы, человек с чем либо имеющий постоянно дело - знает, и знающий на моё предположение о том, что этот MQTT брокер работает с диском, рефлекторно ответил бы, что не работает, а лишь бакапится. Так что не надо ляля, если Вы реально и работали с тем же mosquitto, хотя я полагаю другие реализации делают тоже самое, то в режиме поставил как есть, работает и УРА, что является может быть у мега-кодеров признаком профессионализма, но с точки зрения админа - это высшая степень лоханства, круче которой только не знать, что есть такая штука как логи :)
Ипать ты упоротый, слов нет. У меня москит уже пару лет стоит брокером. Но оправдываться перед упарантом - такое себе, живи кем жил. Я уже понял, что ты попрыгунчик ещё тот - упорно спрыгиваешь с фактов, которыми тебя макают в твоё же дерьмо. Уже убейся, вместе с этой сорной темой.
З.Ы. Даже с разделом Persistence настроек москита - и то сумел обосраться, ты талант, парень! Ты там ниже то почитай, что написано, хотя бы autosave_on_changes и шо это значит. Работает москит с диском, как милый работает. Но, конечно, мы сделаем просто - обзовём это бэкапом, и все вокруг - лохи позорные, один ТС - д'Артаньян!
DIYMan, а зачем недопрограммисту упоротому с Вами мегасупергуру, три собаки сожравшему на mosquito спорить? Поспорите с исходниками mosquitto и обоснуйте им своё утверждение, что они работают с диском :)
Оффтоп конечно, но я искренне не понимаю одного момента, форум вроде бы не наркоманско-молодежный, теоретически люди должны быть думающие, читающие и как следствие хоть немного но культурные, кто-то тут преподавателем даже представлялся, а культура общения с жаргонарием где-то между первый и третьим курсом ПТУ, причем у "гуру" прослеживаются признаки именно третьего курса. В жизни к незнакомому человеку тоже обращаемся сразу на "ты" с переходом на "ипать ты упороты"? Очень сомневаюсь, потому что при такой манере общения в реальной жизни, активничали бы такие собеседники в топиках типа "как на Arduino собрать фильтр для базара" и "автоматизация инвалидной коляски". Лично я когда не знаю с кем общаюсь, не хамлю и всегда обращаюсь на "Вы" к собеседнику, потому что черт его знает, кто там за ником, то ли школота голожопая, то ли реально профессор сидит, за обращение на "ты" к которому потом будет стыдно.
Оффтоп конечно, но я искренне не понимаю одного момента, форум вроде бы не наркоманско-молодежный, теоретически люди должны быть думающие, читающие и как следствие хоть немного но культурные, кто-то тут преподавателем даже представлялся, а культура общения с жаргонарием где-то между первый и третьим курсом ПТУ, причем у "гуру" прослеживаются признаки именно третьего курса. В жизни к незнакомому человеку тоже обращаемся сразу на "ты" с переходом на "ипать ты упороты"? Очень сомневаюсь, потому что при такой манере общения в реальной жизни, активничали бы такие собеседники в топиках типа "как на Arduino собрать фильтр для базара" и "автоматизация инвалидной коляски". Лично я когда не знаю с кем общаюсь, не хамлю и всегда обращаюсь на "Вы" к собеседнику, потому что черт его знает, кто там за ником, то ли школота голожопая, то ли реально профессор сидит, за обращение на "ты" к которому потом будет стыдно.
1. "В мире есть много удивительного мой друг, Гораций";
2. "Люди подобны колбасе. Чем их начинят, то они и носят в себе"
DIYMan, а зачем недопрограммисту упоротому с Вами мегасупергуру, три собаки сожравшему на mosquito спорить? Поспорите с исходниками mosquitto и обоснуйте им своё утверждение, что они работают с диском :)
Пиздец. Мы уже директивы условной компиляции с конфигом москита путаем. Просто феерический долбоёб! И даже в приведённом куске кода графоман не увидел, где идёт работа с диском! Телу неведомо, что москит можно настроить так, что КАЖДЫЙ новопришедший топик он будет скидывать на диск, в свою локальную БД. Ну да правильно - нахер чукче читать, он же пейсатель, млять. С маниакальным упорством обсирается, потом игнорирует, что его тычут в кучу, да так, что вся морда уже в говне - и опять: обсираться, обсираться, обсираться.
Форменная клиника, пожалуй, я пас - не дай бог, долбоебизм подобного рода заразен.
Бох с ним, с флеймом по мемкешу. Вот что интересно - на PC переполнения миллиса не боятся. Плюсуют интервал, как... бог черепаху.
да, глянул .. круто чё. Вот это и есть "недокодер", который лепит поделку поверх сделанного, на базе которой следующий деятель лепит свою чухню. И это - становится агрессивным, в том плане, что отсутсвие знаний и пониманий азов уже выдается за достоинство и достижение. :(
DIYMan, походу уровень грамотности у Вас где-то рядом с уровнем культуры. Я нигде не писал, что нельзя заставить mosquitto всё писать на диск, что по коду, что по комментариям к логу, видно, что autosave_on_changes=true именно это и заставить делать, а еще можно log_level поднять до уровня information, чтобы уж диск по полной получил. Я написал, что при autosave_on_changes=false и autosave_interval=0 обращений к диску в процессе работы от mosquitto не будет. Вы моё утверждение оспорили?
Не хотите или не умеете читать код, ну посмотрите комментарии к конфигу, там ровно тоже самое описано.
autosave_intervalseconds
The number of seconds that mosquitto will wait between each time it saves the in-memory database to disk. If set to 0, the in-memory database will only be saved when mosquitto exits or when receiving the SIGUSR1 signal. Note that this setting only has an effect if persistence is enabled. Defaults to 1800 seconds (30 minutes).
Reloaded on reload signal.
autosave_on_changes [ true | false ]
If true, mosquitto will count the number of subscription changes, retained messages received and queued messages and if the total exceeds autosave_interval then the in-memory database will be saved to disk. If false, mosquitto will save the in-memory database to disk by treating autosave_interval as a time in seconds.
Но квартету теоретических гуру куда интереснее сыпать оскорблениями и по-детски радоваться тому, что mosquitto писали чайники, у которых обязательно переполнение по миллисекундам будет... при использовании секунд.
Arhat109-2, я может не силен в жаргоне и реально что-то не понял, ну так может великий гуру снизойдет до чего-то более конкретного, кроме многозначитальных, но совершенно неинформативных "нда..."
В моем понимании переполнение миллиса это выход значения за пределы 32 бит, то есть при интервале без малого 50 дней, что как бы маловероятно, если речь идет о конфиге, так как едва ли какой маньяк будет ставить периодичность бакапа в 2 месяца, но в данном коде миллисекунды вообще нигде не фигурируют, так как mosquitto_time либо запрашивает, либо приводит время к секундам.
За пределы long last_backup + db->config->autosave_interval даст глюк либо после нового, 2106 года, либо если какой нибудь маньяк поставит autosave_interval 100 лет.
Базовые правила работы со знаковой и беззнаковой арифметикой. Они вроде как изучаются теперь ещё в школе, на уроках информатики, хотя тут могу и ошибиться, вроду бы где-то видел в школьном учебнике от ФГОС, но не помню точно.
Думаю, что все тут прекрасно понимают, что в данном случае ошибка не смертельная. Ну, начнет через триста лет престарелый москит херачить на квантоноситель свой фотонный кэш, сжигая сотни планет - никто из нынечитающих этого даже и не заметит.
Хуже то, что в код, который каждом двадцатом полуумном доме включает и выключает обогреватели, попадают детские ошибки. Кто знает - сколько там еще такого, необнаруженного?
А про миллис... миллис и его переполнение - локальный мем и тема, на которой поломана не одна клавиатура. Так что не нервничайте - это было для местных написано.
sadman41, это уже понятнее. Темы про переполнение миллис на этом форуме я полистал и да, по уму, чтобы не было проблем в 22 веке желательно бы изменить
Но устраивать из этого истрику может только законченный перфекционист, так как при дефолтном 1800 интервеле, который полагаю у 99.9% остался без изменений, где-то в феврале 2106 года mosquitto целых пол часа будет насиловать диск, пытаясь в каждом цикле забакапить данные, но что-то мне подсказывает, что носитель образца 2106 года переживет эту нагрузку.
Совсем красиво уж если делать, выше дописать бы
if (db->persistence_changes > 0) {
Так как сейчас, получается mosquitto по таймеру бакапит данные на диск даже если ничего с прошлого раза не изменилось в этих данных, имея механизм контроля за изменениями в данных, что имхо куда более актуальный в этом веке вопрос к данному куску кода, нежели переполнение long
Что же до кода в полоумных домах, ИМХО на фоне того что в 99% систем использующих POSIX-время, ему выделено как раз long - проблемы с домами - это семечки, так как мы реально имеем повторение проблемы 2000 года только в феврале 2106, но думаю катастроф по этому поводу будет не больше, чем было при наступлении 2000го :)
А если учесть, что во многих системах time является знаковым int(32), то имеем проблему 2038-01-19 03:14:07 так как сегодняшний свежим mysql по запросу SELECT UNIX_TIMESTAMP('2038-01-19 03:14:08') выдает null :(
А если учесть, что во многих системах time является знаковым int(32), то имеем проблему 2038-01-19 03:14:07 так как сегодняшний свежим mysql по запросу SELECT UNIX_TIMESTAMP('2038-01-19 03:14:08') выдает null :(
Ну вот видите - на пенсию пойдете, получите null. В ПФ вам ответят, что "так программа посчитала, а она не ошибается!"
Потом и узнаем от вас - смертельна ли ошибка с переполнением миллис или нет.
Перечитал. Срачем в целом удовлетворен, поучаствовать нимог по обективным причинам. Запомнилось
DetSimen пишет:
то, что стадо не знакомых с друг другом программистов, над которым нет общего начальства с батогами, допиливает 15 лет, по определению не может быть "стабильным".
Таки да! Хоть линуксятников чет от этого коробит.
По сути.
//Идея такая. 1. Если надо передать данные с датчиков...
Как бы в принципе вобще не проблема. Трафик от них мизер. Один только момент на заметку - датчик в принципе не знает кому его показания нужны, отсюда и идея "срать" в промежуточное хранилище, откуда заинтересованые стороны уже и выковыряют. Вы не новичек в IT, кто тут сервер а кто клиент по логике информационных потоков почувствуете;)
//2. По части управления, ардуина вполне может держать постоянно открытым порт memcached и читать оттуда значения управляющих комманд..
А вот тут уже засада. Ну если режим бойлера задать то можна и раз минуту читать. А если сделать свет чуть ярче или шторы приподнять? Если читать не часто, то нет интерактивности. Нажали на кнопку - а результата нет, он появится позже когдато. Для исправления прийдется делать непрерывное чтение и как следствие - разбухший трафик, забитый канал.
Получается п.1 вобще не проблема, на какую технологию не положись, а п.2 - определяющий, что решает его в наиболее сложном кейсе т.е. интерактивное управление, то годится и для п.1 Не две ж технологии юзать.
По поводу сервера ресурсоемкого. Я понимаю источник предубеждений. Растут они из одновременной поддержки сервером многих клиентов. Но для датчика не актуально. Клиент на него приходит получает данные и уходит - доли секунды. Если даже в этот момент прийдет второй клиент - подождет завершения обслуживания первого. А сколько там их всего, этих клиентов будет? Ну десяток. Все обслужатся друг за другом. По управлению тоже все логично - одним устройством в один момент управляет один клиент. На есп-хе просто песня.
Про MQTT. Технология на лоха. Быстрый старт соблазняет массы. А дальше - тупик, тупляк и зависимость от неизвестных личностей.
Да да да... И почему дураки сервера ставят на Линухе и Фри? Дикари, наверно.
И по персональному использованию Андроид (это Линукс... совсем Линукс, не только по ядру, которое полностью линуховое но и по типу файловых систем - ext4, по структуре стартовых скриптов, формату исполняемого файла - elf, это я заранее останавливаю твой поток красноречия ;) без обид!), так вот Андроид, по количеству установок, сам понимаешь, тут даже пруфлинк не нужен, покрывает Винду как слон моську! Гы! ;) Так что дорогой "не линуксятник" - иди ... поплачь, штоле.
Именно опенсорс разработка выиграла у проприетарщиков. Еще пример: кто компилирует, даже коммерческие проекты, на разных платформах, не GCC? Хотя есть еще с дюжину проприетарных компиляторов для разных платформ.
Куда ни ткни - в опенсорс попадешь ;)! Либо на базе Линуха либо ФриБСД.ОС на Микротиках - на Линухе, на Джуниперах - на основе Фри... ну и т.д.
вот только религиозного срачика в данной теме и не хватало....
Чудак человек! Это ж самый жир! Лучший способ прокрастинировать - пустой срач.
Вот мне нужно: движок на форд собирать, чинить посудомойку, перстраивать сарай, не говоря о том, что пора гнать брагу, пока не перестоялась и нужно идти командовать талибами, чинящами общий водопровод, пока они чего не сломали...
НО! - тут есть возможность все послать и сраться Линух-vs-Винда! Это же реальный кайф!
Нууш, я в прокрастинации - первый ченпион. Надо делать и то и то и это, а время есть только на вотку. За что моими барельефами разной степени выпуклости украшены все сковороды в доме.
Да да да... И почему дураки сервера ставят на Линухе и Фри? Дикари, наверно.
И по персональному использованию Андроид (это Линукс... совсем Линукс, не только по ядру, которое полностью линуховое но и по типу файловых систем - ext4, по структуре стартовых скриптов, формату исполняемого файла - elf, это я заранее останавливаю твой поток красноречия ;) без обид!), так вот Андроид, по количеству установок, сам понимаешь, тут даже пруфлинк не нужен, покрывает Винду как слон моську! Гы! ;) Так что дорогой "не линуксятник" - иди ... поплачь, штоле.
Именно опенсорс разработка выиграла у проприетарщиков. Еще пример: кто компилирует, даже коммерческие проекты, на разных платформах, не GCC? Хотя есть еще с дюжину проприетарных компиляторов для разных платформ.
Куда ни ткни - в опенсорс попадешь ;)! Либо на базе Линуха либо ФриБСД.ОС на Микротиках - на Линухе, на Джуниперах - на основе Фри... ну и т.д.
Та ты не пыжся! я и сам под линукс пишу и gcc собираю. И даже комерческое. Факт в другом. Коробит линуксятника! Как черта от святой воды. Потому что сами знают что так))) Хотя там даже и пол намека на линукс нету вобще ;) А подобие стабильности появляется когда дистрибутив комерческий делают, ну командой одной, с плеткой и пряниками допиляют исходники опенсорса до пригодного к продаже вида. Так то.
Logik, чем конкретно Вам не нравится тот же MQTT на той же mosquitto для получения команд ESPхами, реально очень хотелось бы узнать подробнее.
При этом на самом деле если даже вернуться к идеи вычитывания ESPхами того же memcached или другого хранилища, то я не вижу большой проблемы делать это раз в секунду. Радиоканалу пофиг, висит ли та же ESP на сокете с MQTT брокером, ожидая команды, или общается по нему - по части трафика, ну будет раз в секунду от каждой EPS пусть даже 100 байт передаваться, как это повлияет на скорость локалки в доме? Даже 100 ESP по 100 байт в секунду породит трафик около 10 килобайт в секунду, при мощности сети как минимум в 100 мегабит, ужрав тем самым ноль целых, хрен десятитысячных процента трафика. Гуру тут могут начать истерику на тему того, что кроме самих данных еще жрет протокол, но даже выше сотых процентов лимита даже 100 датчиков не сожрут.
На тему задержек комманд на период опроса ESPхами - соглашусь, есть такая проблема, почему и стал изучать внимательно MQTT, в противном случае был вариант реально писать что-то самописное, что выдавало бы команды, но... Я сужу по своему дому, который именно дом, а не хрущевка однокомнатная и пытаюсь представить где мне критична скорость.
Свет - едва ли. Ходить по дому как дурак с планшетом или телефоном, чтобы игнорируя выключатели, которые под рукой, включать свет в комнатах я точно не буду. Если же речь к примеру о режиме освещения, типа там цвет светодиодной подстветки изменить на подходящий под настроение - то задержка в секунду не косяк, всё равно же прикола ради будет в этом блоке функция плавного перехода от цвета к цвету, от одного уровня яркости к другому.
Кондиционеру нафиг скорость не нужна, подождать секунду не проблема, учитывая, что пока эта тварь затворки откроет, пока вентиляторы раскрутит, пройдет больше, а эффективное охлаждение или тем более оборгев, при температуре даже 0 за бортом, от него раньше чем через минуту ждать вообще не имеет смысла.
Ворота гаража, учитывая время их открытия - подождут секунду, бойлер как Вы верно заметили тоже подожет, горелка на пилетах тем более, в общем абсолютно всё кроме включения света упирается во время исполнения команды исполнителем более 10-15 секунд и не требует обработки команд в реальном времени.
Со светом мне автоматизация реально нужна лишь в режиме "включить освещение двора" и "вырубить свет во всем доме" когда ложусь спать. Когда же среди ночи прижало пойти в сортир, то маловероятно, что кто-то будет искать в телефоне или планшете как свет включить в клозете, куда проще нажать клавишу, расположение которой знаешь на ощупь, есть еще вариант по датчику движения и освещенности включать свет, но у меня этот вариант не катит, так как собаки, и не чихуа, которую можно отфильтровать настройками датчиков движения, а охранные зверики, которых датчик от человека отличить не сможет.
То есть с одной стороны я понимаю, что тема MQTT при которой исполнитель получает команду мгновенно вроде бы лучше, чем опрос команд даже раз в секунду, но Вы реально смутили фразой, что MQTT в итоге упрется во что-то, не раскрыв полностью во что... С другой стороны в режиме умного дома нет как таковых realtime задач, кроме света, который всё равно включать удобнее руками по клавише на входе в комнату.
При этом на тему MQTT насколько я его смог теоретически изучить, нет там проблемы, что отправитель не знает кому нужны его данные, отправил я к примеру температуру в кабинете как cabinetetemperature=27 и кому надо из элементов системы сам на неё подпишется и получит их, отправителю знать получателя ненадо, и в этом смысле идея MQTT мне нравится. Не нравится мне в MQTT реально, что нет варианта ReadCurrentValue без подписки и отписки, и поэтому возможно в итоге сделаю гибрид в котором данные отправляются всё же в memcached, а управляющие команды для EPS идут через MQTT.
Нету там 100Мб. Там вайфай, в нем все на практике в десяток и более раз медленей. К тому же по нему все остальное в доме шарится. А короткими пакетами вайфай забется на раз.
Раз в секунду - во первых для интрерактивного комфорта мало, нужно разы в секунду, во вторых не факт что с MQTT даже раз в сек обеспечится. На пределе оно.
//стал изучать внимательно MQTT, в противном случае был вариант реально писать что-то самописное
Ну писать таки всеравно прийдется, вопрос только чего, куда и сколько. Вам же нужна будет некоторая внутреняя логика поведения частей, типа похолодало - закрываем окно, не помогло - включаем обогрев и т.д. Если уж так, чтоб совсем не писать - идем в ищу исполнителя или на фирму где все под ключ.
//в режиме умного дома нет как таковых realtime задач, кроме света
Скорость критична везде где нужна интерактивность. Регулировка громкости звука, обороты вентилятора и т.д. Будут ли и сколько таких задач у Вас - Вам видней конечно.
//MQTT при которой исполнитель получает команду мгновенно
ниче там не мгновенно. Хотя кому и через секунду - мгновенно будет. Ищите по форуму, тема про управление по MQTT уже не раз перемывалась, чтоб подымать сначала. Скажу только что держать постоянный коннект по вайфаю - очень плохая мысль. Не тот канал, валится будет часто, а обнаруживатся что отвалилось - не быстро.
//Не нравится мне в MQTT реально, что нет варианта ReadCurrentValue без подписки и отписки,
Угу. Я Вам подскажу как. Все подписаны на всех. Т.е. собираете все показания в одну xml-ину, например, и рассылаете всем. Она там в пару килобайт выйдет, вобщем пофиг, при коротких пакетах. А если еще и широковещательно сделать - воще красота.
//нет там проблемы, что отправитель не знает кому нужны его данные
Это не проблема. Это свойство датчика. И при проектировании системы его надо учитывать и использовать себе на пользу. Иначе может стать проблемой. Вобще это свойство однозначно говорит, кто тут должен быть сервером. И выворачивать логику построения системы супротив логики информационных потоков в ней - себе дороже.
//в итоге сделаю гибрид в котором данные отправляются всё же в memcached, а управляющие команды для EPS идут через MQTT.
if ((SendedValue!=CurrentValue) || (LastSended<millis()-PingTime)) {SendValue...}
В такой логике и данные придут по мере изменения, и нагрузка на канал минимизируется, ведь 99% датчиков меняют показания довольно редко, при этом PingTime нужен лишь для решение задачи вычисления отвалившихся датчиков, а для этого вполне достаточно пинга раз в 10 минут.
//не факт что с MQTT даже раз в сек обеспечится.
Теоретически должно быть в разы быстрее, но это предстоит проверять на практике, когда чайнамейл доставит малинку.
//Ну писать таки всеравно прийдется, вопрос только чего, куда и сколько. Вам же нужна будет некоторая внутреняя логика
Одно дело писать логику, другое дело мастерить сервер для обмена данными.
//Скажу только что держать постоянный коннект по вайфаю - очень плохая мысль. Не тот канал, валится будет часто, а обнаруживатся что отвалилось - не быстро.
Про обнаружение отвалившихся я написал чуть выше, модули которые лишь передают данные можно запрограммировать не держать коннект, а конектиться, передавать данные и отваливаться. А вот управляющим придется так или иначе быть на связи постоянно, а значит где-то по мере возможности кабель, а где-то придется писать скетч в котором 90% кода будет посвящено поддержке соединения.
/// ...нет варианта ReadCurrentValue... Угу. Я Вам подскажу как. Все подписаны на всех.
Есть простейшая задача - визуализировать в веб интерфейсе температуру в комнате, самое простое - это тому же php приконектиться к чему то, что по запросу get temperature1 вернуло бы хранящееся значение. В MQTT, если я верно понял, для этого надо записывать RETAIN=1, а на PHP каждый раз создавать новый SubscriberID, подписываться, получать значение и после отписываться, чтобы не плодились "мертвых" подписчики у MQTT брокера, что как мне кажется слишком большое количество "теледвижений" для одной операции. Более того, учитывая, что без модуля времени ни ESP ни аудуина не знают сколько времени, а MQTT не отдает как я понял время публикации сообщения подписчику, получается никак не отследить свежеть данных, а соответственно не проверить живой ли вообще датчик.
В общем вполне возможно я не прав, непонимая прелестей использования MQTT клиентом, но то, что по нагрузке на сервер как минимум в реализации брокера mosquito он ничуть не легче, а возможно даже тяжелее MySQL будет - это факт.
Ну вот и чудненько - несознанка просветляется, оказывается, MQTT уже не так плох. Однако, мы продолжаем путать мух с котлетами - зачем-то сравнение MQTT с реализацией брокера, и с MySQL. Не надо сравнивать круглое с мягким.
Вот тебе, кстати, первая попавшаяся ссылка на брокер, который могёт в MySQL сохранять: https://www.raviyp.com/embedded/233-learn-how-to-save-mqtt-messages-into-a-mysql-database
Далее: прекращаем ментально онанировать на то, какой мемкеш няшный, а вместо этого - берём, и пишем простенького брокера MQTT, который будет хранить данные где? Правильно, в мемкеше. На выходе получаем блекджек со шлюхами.
Еще, если я верно понял, подписанному на сообщение клиенту брокер MQTT будет рассылать данные вне зависимости нужны они ему или нет
Нет, ты понял неверно. Брокер рассылает данные подписчикам, ключевое здесь - подписчик. Т.е. если ты не подписался на топик - брокер тебе ничего не пришлёт. Т.е. ты подписываешься только на интересующие тебя данные. Не нужны больше данные - отписался, делов-то. Плюсом ко всему - без плясок с бубном, у топика есть флаг retained, сие значит, что как только ты подконнектился и подписался на топик - брокер вышлет тебе последний полученный интересующий тебя топик. Такой вполне себе механизм "last known data" получается, искаропки. Зацени.
Arhat109-2, ну дайте типовое определение, чем является "прошивка" NodeMCU в микроконтроллере, учитывая, что её функционал явно выходит за рамки классического BIOS?
Вам не нравится компот технологий и Вы предпочитаете вылеззанный код исключительно на С - Ваше право, а вот я не вижу смысла чесать левой ногой правое ухо, изобретая на С или тем более перле сервера для тех или иных задач, когда на том же С написаны решения под каждую из них, и они замечательно согласуются между собой. И я искренне не понимаю с чего Вы взяли, что рукодельный код Ваш будет работать быстрее и стабильнее чем та же связка Nginx как вебсервера, MySQL как базы, php для формирования html страниц, perl в кроне для выполнения регулярных задач, и пресловутый Memcached или кому нравится mosquitto для передачи данных и управления "датчиками"?
Всё это вопросы веры. Преимущества ни одного из решений неочевидны при генерализованном рассмотрении абстрактной задачи.
Всё изобретено (украдено) давно до вас, не переживайте. Просто Вы пытаетесь использовать свой компот, потому что он Вам больше понятен. Никто же не мешает, пользуйте на здоровье! Просто не надо его навязывать всем остальным как единственно верный, на что Вам уже указали выше.
Работать она будет гарантированно шустрее, а равно как будем жрать меньше ресурсов. По одной простой причине: в ней миниум кода "помазанного поверх" того что работает везде одинаково (билиотеки нижнего уровня). И да, компактней чем хранение в банальном массиве Си - у Вас не получится. Сброс массива в файл - это что делает скуль .. как и чтение туда-сюда непрерывно. Вот, без всего этого МОЖНО обойтись, но не Вам как "недопрограммисту".
Без обид только. Но именно про это и писал wdrakula.
Коллеги... мне кажется спор бесперспективен.
ТС - типичный зануда :)
Проще махнуть рукой и согласиться с ним, чем донести до него иную точку зрения.
ТС - типичный представитель недокодера, что в последнее время становится агрессивным. Вы это хорошо могли почитать на форуме амперки в топике "пост негодования" про чудо-плату "Искра + JS", где 0.007% от базовой эффективности микроконтроллера выдается за "верх технологий". В нулях - не ошибся, это по даташиту Espruino, лежащей в основе, ежели вчё.
Просто плавая по верхам стеков и технологий, они как выясняется понятия не имеют что под этим стеком находится. Что тот же memcached внутри себя хранит все в банальных массивах той или иной структуры и общается всё через ту же библиотеку TCP/IP, писанную в незапамятные времена .. да и ЗАЧЕМ? Это же надо разбираться, а это "порог вхождения". Куда проще обучение "обезьяним методом".. плохо то, что они становятся все агрессивней. :(
ТС - типичный представитель недокодера,..
плохо то, что они становятся все агрессивней. :(
Слава Б..у, что (пока!) не кусается! ;) ;) ;)
DIYMan, походу я всё верно понял, что подписавшись, та же ESP как клиент будет постоянно "атакована" данными от брокера вне зависимости нужны они или нет, для получения управляющих сигналов исполнителями, той же ESP-хе которая эмулирует пульт кондиционера, это хороший вариант, судя по loop() в https://github.com/knolleary/pubsubclient/blob/master/src/PubSubClient.cpp отрабатывающая мгновенно, не гоняя трафик на лишние запросы, лишь пингуя периодически, еще и с удобным вызовом callback для обработки сообщения, при этом как я понимаю, на одно сообщение от MQTT брокера может быть подписано сколько угодно клиентов и каждый это сообщение получит. В общем в этой задаче, соглашусь, что MQTT намного удобнее, пусть даже и тяжелее, пусть даже с диском работает, управляющих комманд реально 1 / 1000 не наберется, относительно передачи показаний датчиков. Так же, если надо одним "датчиком", срочно дать команду другому, то MQTT тоже вариант идеальный.
А вот для задачи постоянной передачи показаний с датчиков с эпизодической их визуализацией в том же веб-интерфейсе, ИМХО всё таки рациональнее ненавистный некоторым участникам дискуссии memcached. Потому как с одной стороны данные в идеале должны обновляться чуть ли не раз в секунду, с другой стороны востребованы они либо для записи в журнал, по той же температуре не чаще чем раз в 10 минут, либо когда открыта страница генерируемая PHP.
Конечно можно на том же PHP при форировании страницы веб-морды послать устройствам через брокера команду "срочно предоставить данные по показаниям датчиков", но вот тут если честно надо эксперементировать, так как лично я не вполне понимаю с какой скоростью это будет происходить, особенно если датчиков больше двух десятков. Есть конечно вариант отправлять команду предоставить данные при формировании веб страницы не дожидаясь обновления данных, а сами данные забирать через json запрос ко времени запуска которого на браузере данные должны будут подойти, и каждый json заставлять датчики предоставлять данные, чтобы было обновление данных в реальном времени без перезагрузки страницы и только пока такая страница открыта, это опробую.
Но как альтернативный вариант - всё таки сделаю для сравнения и постоянную передачу через перманентно открытый сокет данных показаний датчиков от ESP на memcached, узкое место в этом случае только канал связи, но ИМХО даже 100 датчиков, даже раз в секунду передавая данные, едва ли как-то повлияют.
Еще раз хочу отметит, что как я написал изначально, в этой теме я новичок, и поднял я тему memcached не просто так, а потому что когда я пришел на форум в топе была вот эта тема http://arduino.ru/forum/programmirovanie/esp8266-kak-schitat-dannye-s-saita и относительно её, тема использования memcached ИМХО выглядит более чем логично.
А вот это уж точно лишнее, и уж если писать своего брокера, то в его памяти, как советовал учитель-перфекционист, и хранить тогда, нахрена брокеру внешнее хранилище, пусть даже очень шустрое, учитывая, что перезагрузка маловероятна, а при вырубке электричества в дома, даже если малинка без бесперебойника будет то ESP и Arduinки тоже лягут и данные будет хранить просто не для кого.
Уже кусаются. Зайдите на амперку в раздел флудилка и перечитайте топик "пост негодования".. особенно к концу, где меня нагло заблокировали увеличив время отклика сервера на от 18 до 30+ секунд с потерей соединений. Только после того как через фейсбук обратился публично к руководству амперки - блокировку сняли.
Вот такая она вот "амперка" теперь.. спонсор детских соревнований .. :(
Блеать! Это можно как-то остановить? Может на него Св. водой побрызгать? ;) ;) ;)
Или удавку из Св. Пары? (кат. 6е, ессно)
Почему в России столько творческих людей? Иногда хочется им фенозепам раздавать, что б спали и не трогали никого.
-----------------------------------------------
Дорогой, почитай о текущем состоянии дел с проектированием умных домов-сараев-теплиц-курятников и собачьих будок.
Есть уже сложившиеся традиции (где-то - уже даже стандарты), которые помогают обеспечить совместимость узлов разных производителей.
MQTT - одна из них, связь по 485 - еще одна... и т.д. Внутри помещения используется проводная связь, даже не потому, что куча мелких ВиФи устройств засрет канал, не засрет, если не часто, - просто потому, что любому датчику или исполнительному соленоиду-серве-шаговику - нужно питание. А значит проще протянуть сигнал проводом, если питание все равно тянуть.
Если ты планируешь делать уникальное устройство только для своего дома - да хоть как, ЕСП8266, мемкешед и прочее. Практическая ценность - чисто хоббийная - самореализация. Это неплохо, почти всегда хобби это удовольствие от самореализации.
Практической цели в тиражировании устройств, разработанных не "в тренде" - нет никакой. Поэтому я и пишу в 100500-й раз:
Нормальное твое решение, пиши, строй свой умный дом, потом в "Проектах" расскажешь, только митинговать кончай!
А вот это уж точно лишнее, и уж если писать своего брокера, то в его памяти, как советовал учитель-перфекционист, и хранить тогда, нахрена брокеру внешнее хранилище, пусть даже очень шустрое, учитывая,
Message QOS => 0
DIYMan, походу я всё верно понял, что подписавшись, та же ESP как клиент будет постоянно "атакована" данными от брокера вне зависимости нужны они или нет,
Нихера ты не понял, зануда. Ещё раз: ПОДПИСАЛСЯ - данные от брокера пошли. ОТПИСАЛСЯ - данные от брокера не идут. Подписываться/отписываться можно мульён раз, до посинения. Ферштейн?
Атакована, мля, ага. Идиотия твоего занудства просто зашкаливает.
А вот это уж точно лишнее, и уж если писать своего брокера, то в его памяти, как советовал учитель-перфекционист, и хранить тогда, нахрена брокеру внешнее хранилище, пусть даже очень шустрое, учитывая,
Message QOS => 0
Тсс, чукча же писатель, он так нихера ничего по MQTT не прочитал, а ты ему пытаешься межушный ганглий разорвать :)
ну блин - неужели еще не поняли? Человеку просто скучно и не с кем поболтать.
Вы ему 2 строчки - он в ответ 25. Причем сполошной белиберды.
Остановить его невозможно, можно только уйти из темы.
b707, ну так давно бы вышли с топика, вместе с Arhat109-2, DIYMan и wdrakula, но вашему квартету походу просто в кайф пытаться самоутверждаться на человеке который в ТС прямо заявил что в теме новичок, что ардуина первый дань в руки попала на момент ТС, но по делу пишет один sadman41.
К вопросу пишется ли на диск что-то при QoS 2 - зависит от реализации брокера, в частности если это mosquitto, то в конфиге прямо сказано:
autosave_interval second
The number of seconds that mosquitto will wait between each time it saves the in-memory database to disk. If set to 0, the in-memory database will only be saved when mosquitto exits or when receiving the SIGUSR1 signal. Note that this setting only has an effect if persistence is enabled. Defaults to 1800 seconds (30 minutes).
Одной этой строчки достаточно было бы, если бы были реальные гуру, а не неистовый квартет теоретиков. То есть в конфигурации autosave_interval=0 превращает затею с memcached в абсолютно бессмысленную если применять этого брокера, без всяких фантазий на тему "пишем брокера...". Хотя и это не нужно, так как сброс базы на диск раз в 30 минут не проблема даже в случае с SD картой, но опять же гуру то не нашлось, который бы написал, что брокер не хранит данные на диске, как тот же MySQl, а лишь периодически пакапится на диск... При этом для ускорения-упрощения процесса передачи данных, сохранность которых похрену, QoS = 0 самое то и по логике является по части отправки 100% аналогом memcached, к тому же с функцией рассылки если надо.
При этом "гуру" обсудили что угодно, от качества студентов, до блокировки преподавателя на амперке, может не зря его там забанили?
И специально для DIYMan, если бы Вы были внимательнее, то увидели бы в #55 что прочитал я не только мануал, но и сорцы клиента внимательно, и грешным делом настройки нашел тоже в сорцах, где само название функции persist__backup навело на мысль, что данные не хранятся на диске, как я ошибочно предполагал, а лишь бакапятся. Так что Ваши возмущения на тему того что я не понял, что подписка отменяется - напрасны.
Так, что sadman41, огромное спасибо за конструктив и человеческое общение, а тему эту можно смело закрывать за нецелесообразностью в таком варианте использовать memcached вообще.
И специально для DIYMan, если бы Вы были внимательнее, то увидели бы в #55 что прочитал я не только мануал, но и сорцы клиента внимательно, и грешным делом настройки нашел тоже в сорцах, где само название функции persist__backup навело на мысль, что данные не хранятся на диске,
Ну я ж и говорю - чукча писатель. Вместо того, чтобы просто полезть и посмотреть настройки того же москита - чукча развёл тут бессмысленный трёп. Пеняя на то, что ему кто-то что-то там должен помнить наизусть все настройки москита. Есть у него настройка интервала сбрасывания данных на диск? Чудненько, ты открыл для себя новое, мемкеш не нужен, тема - бессмысленна.
Правильно излагать свои мысли - ты не умеешь, я тебе указал на твой бред по поводу "ESP как клиент будет постоянно "атакована" " - ты вильнул хвостом совсем в другую сторону. Считаешь, после такого с тобой можно общаться конструктивно? Отнюдь.
Слава богу, что эта бредовая тема уже дохнет. Мозговой онанизм, помешанный на дилетанствующем энтузиазме, иногда и не к таким многостраничным высерам приводит. Аминь.
DIYMan, вот это с Вашей стороны попытка выстроить хорошую мину, при очевидно плохой игре. Настройки конечно наизусть никто не помнит, особенно если давно работаешь с чем-то и конфиги стабильные годами, но вот принцип работы, человек с чем либо имеющий постоянно дело - знает, и знающий на моё предположение о том, что этот MQTT брокер работает с диском, рефлекторно ответил бы, что не работает, а лишь бакапится. Так что не надо ляля, если Вы реально и работали с тем же mosquitto, хотя я полагаю другие реализации делают тоже самое, то в режиме поставил как есть, работает и УРА, что является может быть у мега-кодеров признаком профессионализма, но с точки зрения админа - это высшая степень лоханства, круче которой только не знать, что есть такая штука как логи :)
Ипать ты упоротый, слов нет. У меня москит уже пару лет стоит брокером. Но оправдываться перед упарантом - такое себе, живи кем жил. Я уже понял, что ты попрыгунчик ещё тот - упорно спрыгиваешь с фактов, которыми тебя макают в твоё же дерьмо. Уже убейся, вместе с этой сорной темой.
З.Ы. Даже с разделом Persistence настроек москита - и то сумел обосраться, ты талант, парень! Ты там ниже то почитай, что написано, хотя бы autosave_on_changes и шо это значит. Работает москит с диском, как милый работает. Но, конечно, мы сделаем просто - обзовём это бэкапом, и все вокруг - лохи позорные, один ТС - д'Артаньян!
Вангую - щас будет очередной нудный высер.
DIYMan, а зачем недопрограммисту упоротому с Вами мегасупергуру, три собаки сожравшему на mosquito спорить? Поспорите с исходниками mosquitto и обоснуйте им своё утверждение, что они работают с диском :)
#ifdef WITH_PERSISTENCE if(db->config->persistence && db->config->autosave_interval){ if(db->config->autosave_on_changes){ if(db->persistence_changes >= db->config->autosave_interval){ persist__backup(db, false); db->persistence_changes = 0; } }else{ if(last_backup + db->config->autosave_interval < mosquitto_time()){ persist__backup(db, false); last_backup = mosquitto_time(); } } } #endif #ifdef WITH_PERSISTENCE if(flag_db_backup){ persist__backup(db, false); flag_db_backup = false; } #endifОффтоп конечно, но я искренне не понимаю одного момента, форум вроде бы не наркоманско-молодежный, теоретически люди должны быть думающие, читающие и как следствие хоть немного но культурные, кто-то тут преподавателем даже представлялся, а культура общения с жаргонарием где-то между первый и третьим курсом ПТУ, причем у "гуру" прослеживаются признаки именно третьего курса. В жизни к незнакомому человеку тоже обращаемся сразу на "ты" с переходом на "ипать ты упороты"? Очень сомневаюсь, потому что при такой манере общения в реальной жизни, активничали бы такие собеседники в топиках типа "как на Arduino собрать фильтр для базара" и "автоматизация инвалидной коляски". Лично я когда не знаю с кем общаюсь, не хамлю и всегда обращаюсь на "Вы" к собеседнику, потому что черт его знает, кто там за ником, то ли школота голожопая, то ли реально профессор сидит, за обращение на "ты" к которому потом будет стыдно.
Вам в драматурги надо. Я сейчас заплачу.
Наданапица.
Не вздумай, дед. С этим не шутют.
(*лучше отпиши на амперку мои спасибки за то, что почистили тему. ну ты знаешь куда. И да, пусть перечитают в ней ПЕРВЫЙ пост вдумчиво. :) *)
Оффтоп конечно, но я искренне не понимаю одного момента, форум вроде бы не наркоманско-молодежный, теоретически люди должны быть думающие, читающие и как следствие хоть немного но культурные, кто-то тут преподавателем даже представлялся, а культура общения с жаргонарием где-то между первый и третьим курсом ПТУ, причем у "гуру" прослеживаются признаки именно третьего курса. В жизни к незнакомому человеку тоже обращаемся сразу на "ты" с переходом на "ипать ты упороты"? Очень сомневаюсь, потому что при такой манере общения в реальной жизни, активничали бы такие собеседники в топиках типа "как на Arduino собрать фильтр для базара" и "автоматизация инвалидной коляски". Лично я когда не знаю с кем общаюсь, не хамлю и всегда обращаюсь на "Вы" к собеседнику, потому что черт его знает, кто там за ником, то ли школота голожопая, то ли реально профессор сидит, за обращение на "ты" к которому потом будет стыдно.
1. "В мире есть много удивительного мой друг, Гораций";
2. "Люди подобны колбасе. Чем их начинят, то они и носят в себе"
авторов найдешь сам. :)
DIYMan, а зачем недопрограммисту упоротому с Вами мегасупергуру, три собаки сожравшему на mosquito спорить? Поспорите с исходниками mosquitto и обоснуйте им своё утверждение, что они работают с диском :)
#ifdef WITH_PERSISTENCE if(db->config->persistence && db->config->autosave_interval){ if(db->config->autosave_on_changes){ if(db->persistence_changes >= db->config->autosave_interval){ persist__backup(db, false); db->persistence_changes = 0; } }else{ if(last_backup + db->config->autosave_interval < mosquitto_time()){ persist__backup(db, false); last_backup = mosquitto_time(); } } } #endif #ifdef WITH_PERSISTENCE if(flag_db_backup){ persist__backup(db, false); flag_db_backup = false; } #endifПиздец. Мы уже директивы условной компиляции с конфигом москита путаем. Просто феерический долбоёб! И даже в приведённом куске кода графоман не увидел, где идёт работа с диском! Телу неведомо, что москит можно настроить так, что КАЖДЫЙ новопришедший топик он будет скидывать на диск, в свою локальную БД. Ну да правильно - нахер чукче читать, он же пейсатель, млять. С маниакальным упорством обсирается, потом игнорирует, что его тычут в кучу, да так, что вся морда уже в говне - и опять: обсираться, обсираться, обсираться.
Форменная клиника, пожалуй, я пас - не дай бог, долбоебизм подобного рода заразен.
Бох с ним, с флеймом по мемкешу. Вот что интересно - на PC переполнения миллиса не боятся. Плюсуют интервал, как... бог черепаху.
Бох с ним, с флеймом по мемкешу. Вот что интересно - на PC переполнения миллиса не боятся. Плюсуют интервал, как... бог черепаху.
ну так это небось писано командой добровольцев типа нашего ТС :) - а смотрящий не уследил
Бох с ним, с флеймом по мемкешу. Вот что интересно - на PC переполнения миллиса не боятся. Плюсуют интервал, как... бог черепаху.
Годно :)
А это не миллисекунды. https://github.com/eclipse/mosquitto/blob/master/lib/time_mosq.c функция mosquitto_time возвращает время в секундах.
Бох с ним, с флеймом по мемкешу. Вот что интересно - на PC переполнения миллиса не боятся. Плюсуют интервал, как... бог черепаху.
да, глянул .. круто чё. Вот это и есть "недокодер", который лепит поделку поверх сделанного, на базе которой следующий деятель лепит свою чухню. И это - становится агрессивным, в том плане, что отсутсвие знаний и пониманий азов уже выдается за достоинство и достижение. :(
Н-да .. Вы даже не поняли о чем было сказано..
DIYMan, походу уровень грамотности у Вас где-то рядом с уровнем культуры. Я нигде не писал, что нельзя заставить mosquitto всё писать на диск, что по коду, что по комментариям к логу, видно, что autosave_on_changes=true именно это и заставить делать, а еще можно log_level поднять до уровня information, чтобы уж диск по полной получил. Я написал, что при autosave_on_changes=false и autosave_interval=0 обращений к диску в процессе работы от mosquitto не будет. Вы моё утверждение оспорили?
Не хотите или не умеете читать код, ну посмотрите комментарии к конфигу, там ровно тоже самое описано.
autosave_intervalsecondsThe number of seconds that mosquitto will wait between each time it saves the in-memory database to disk. If set to 0, the in-memory database will only be saved when mosquitto exits or when receiving the SIGUSR1 signal. Note that this setting only has an effect if persistence is enabled. Defaults to 1800 seconds (30 minutes).
Reloaded on reload signal.
autosave_on_changes[ true | false ]If
true, mosquitto will count the number of subscription changes, retained messages received and queued messages and if the total exceedsautosave_intervalthen the in-memory database will be saved to disk. Iffalse, mosquitto will save the in-memory database to disk by treatingautosave_intervalas a time in seconds.Но квартету теоретических гуру куда интереснее сыпать оскорблениями и по-детски радоваться тому, что mosquitto писали чайники, у которых обязательно переполнение по миллисекундам будет... при использовании секунд.
Arhat109-2, я может не силен в жаргоне и реально что-то не понял, ну так может великий гуру снизойдет до чего-то более конкретного, кроме многозначитальных, но совершенно неинформативных "нда..."
В моем понимании переполнение миллиса это выход значения за пределы 32 бит, то есть при интервале без малого 50 дней, что как бы маловероятно, если речь идет о конфиге, так как едва ли какой маньяк будет ставить периодичность бакапа в 2 месяца, но в данном коде миллисекунды вообще нигде не фигурируют, так как mosquitto_time либо запрашивает, либо приводит время к секундам.
За пределы long last_backup + db->config->autosave_interval даст глюк либо после нового, 2106 года, либо если какой нибудь маньяк поставит autosave_interval 100 лет.
Что я не так понял?
Базовые правила работы со знаковой и беззнаковой арифметикой. Они вроде как изучаются теперь ещё в школе, на уроках информатики, хотя тут могу и ошибиться, вроду бы где-то видел в школьном учебнике от ФГОС, но не помню точно.
А это не миллисекунды. https://github.com/eclipse/mosquitto/blob/master/lib/time_mosq.c функция mosquitto_time возвращает время в секундах.
Думаю, что все тут прекрасно понимают, что в данном случае ошибка не смертельная. Ну, начнет через триста лет престарелый москит херачить на квантоноситель свой фотонный кэш, сжигая сотни планет - никто из нынечитающих этого даже и не заметит.
Хуже то, что в код, который каждом двадцатом полуумном доме включает и выключает обогреватели, попадают детские ошибки. Кто знает - сколько там еще такого, необнаруженного?
А про миллис... миллис и его переполнение - локальный мем и тема, на которой поломана не одна клавиатура. Так что не нервничайте - это было для местных написано.
sadman41, это уже понятнее. Темы про переполнение миллис на этом форуме я полистал и да, по уму, чтобы не было проблем в 22 веке желательно бы изменить
if(last_backup + db->config->autosave_interval < mosquitto_time()){на
if(last_backup < mosquitto_time() - db->config->autosave_interval){Но устраивать из этого истрику может только законченный перфекционист, так как при дефолтном 1800 интервеле, который полагаю у 99.9% остался без изменений, где-то в феврале 2106 года mosquitto целых пол часа будет насиловать диск, пытаясь в каждом цикле забакапить данные, но что-то мне подсказывает, что носитель образца 2106 года переживет эту нагрузку.
Совсем красиво уж если делать, выше дописать бы
if (db->persistence_changes > 0) {Так как сейчас, получается mosquitto по таймеру бакапит данные на диск даже если ничего с прошлого раза не изменилось в этих данных, имея механизм контроля за изменениями в данных, что имхо куда более актуальный в этом веке вопрос к данному куску кода, нежели переполнение long
Что же до кода в полоумных домах, ИМХО на фоне того что в 99% систем использующих POSIX-время, ему выделено как раз long - проблемы с домами - это семечки, так как мы реально имеем повторение проблемы 2000 года только в феврале 2106, но думаю катастроф по этому поводу будет не больше, чем было при наступлении 2000го :)
А если учесть, что во многих системах time является знаковым int(32), то имеем проблему 2038-01-19 03:14:07 так как сегодняшний свежим mysql по запросу SELECT UNIX_TIMESTAMP('2038-01-19 03:14:08') выдает null :(
А если учесть, что во многих системах time является знаковым int(32), то имеем проблему 2038-01-19 03:14:07 так как сегодняшний свежим mysql по запросу SELECT UNIX_TIMESTAMP('2038-01-19 03:14:08') выдает null :(
Ну вот видите - на пенсию пойдете, получите null. В ПФ вам ответят, что "так программа посчитала, а она не ошибается!"
Потом и узнаем от вас - смертельна ли ошибка с переполнением миллис или нет.
Перечитал. Срачем в целом удовлетворен, поучаствовать нимог по обективным причинам. Запомнилось
то, что стадо не знакомых с друг другом программистов, над которым нет общего начальства с батогами, допиливает 15 лет, по определению не может быть "стабильным".
Таки да! Хоть линуксятников чет от этого коробит.
По сути.
//Идея такая. 1. Если надо передать данные с датчиков...
Как бы в принципе вобще не проблема. Трафик от них мизер. Один только момент на заметку - датчик в принципе не знает кому его показания нужны, отсюда и идея "срать" в промежуточное хранилище, откуда заинтересованые стороны уже и выковыряют. Вы не новичек в IT, кто тут сервер а кто клиент по логике информационных потоков почувствуете;)
//2. По части управления, ардуина вполне может держать постоянно открытым порт memcached и читать оттуда значения управляющих комманд..
А вот тут уже засада. Ну если режим бойлера задать то можна и раз минуту читать. А если сделать свет чуть ярче или шторы приподнять? Если читать не часто, то нет интерактивности. Нажали на кнопку - а результата нет, он появится позже когдато. Для исправления прийдется делать непрерывное чтение и как следствие - разбухший трафик, забитый канал.
Получается п.1 вобще не проблема, на какую технологию не положись, а п.2 - определяющий, что решает его в наиболее сложном кейсе т.е. интерактивное управление, то годится и для п.1 Не две ж технологии юзать.
По поводу сервера ресурсоемкого. Я понимаю источник предубеждений. Растут они из одновременной поддержки сервером многих клиентов. Но для датчика не актуально. Клиент на него приходит получает данные и уходит - доли секунды. Если даже в этот момент прийдет второй клиент - подождет завершения обслуживания первого. А сколько там их всего, этих клиентов будет? Ну десяток. Все обслужатся друг за другом. По управлению тоже все логично - одним устройством в один момент управляет один клиент. На есп-хе просто песня.
Про MQTT. Технология на лоха. Быстрый старт соблазняет массы. А дальше - тупик, тупляк и зависимость от неизвестных личностей.
Таки да! Хоть линуксятников чет от этого коробит.
=====СОРРИ ОФФТОП======СОРРИ ОФФТОП=======
Да да да... И почему дураки сервера ставят на Линухе и Фри? Дикари, наверно.
И по персональному использованию Андроид (это Линукс... совсем Линукс, не только по ядру, которое полностью линуховое но и по типу файловых систем - ext4, по структуре стартовых скриптов, формату исполняемого файла - elf, это я заранее останавливаю твой поток красноречия ;) без обид!), так вот Андроид, по количеству установок, сам понимаешь, тут даже пруфлинк не нужен, покрывает Винду как слон моську! Гы! ;) Так что дорогой "не линуксятник" - иди ... поплачь, штоле.
Именно опенсорс разработка выиграла у проприетарщиков. Еще пример: кто компилирует, даже коммерческие проекты, на разных платформах, не GCC? Хотя есть еще с дюжину проприетарных компиляторов для разных платформ.
Куда ни ткни - в опенсорс попадешь ;)! Либо на базе Линуха либо ФриБСД.ОС на Микротиках - на Линухе, на Джуниперах - на основе Фри... ну и т.д.
вот только религиозного срачика в данной теме и не хватало....
а мне все OS нравятся, использую разные в зависимости от задач.
вот только религиозного срачика в данной теме и не хватало....
Чудак человек! Это ж самый жир! Лучший способ прокрастинировать - пустой срач.
Вот мне нужно: движок на форд собирать, чинить посудомойку, перстраивать сарай, не говоря о том, что пора гнать брагу, пока не перестоялась и нужно идти командовать талибами, чинящами общий водопровод, пока они чего не сломали...
НО! - тут есть возможность все послать и сраться Линух-vs-Винда! Это же реальный кайф!
Нууш, я в прокрастинации - первый ченпион. Надо делать и то и то и это, а время есть только на вотку. За что моими барельефами разной степени выпуклости украшены все сковороды в доме.
Таки да! Хоть линуксятников чет от этого коробит.
=====СОРРИ ОФФТОП======СОРРИ ОФФТОП=======
Да да да... И почему дураки сервера ставят на Линухе и Фри? Дикари, наверно.
И по персональному использованию Андроид (это Линукс... совсем Линукс, не только по ядру, которое полностью линуховое но и по типу файловых систем - ext4, по структуре стартовых скриптов, формату исполняемого файла - elf, это я заранее останавливаю твой поток красноречия ;) без обид!), так вот Андроид, по количеству установок, сам понимаешь, тут даже пруфлинк не нужен, покрывает Винду как слон моську! Гы! ;) Так что дорогой "не линуксятник" - иди ... поплачь, штоле.
Именно опенсорс разработка выиграла у проприетарщиков. Еще пример: кто компилирует, даже коммерческие проекты, на разных платформах, не GCC? Хотя есть еще с дюжину проприетарных компиляторов для разных платформ.
Куда ни ткни - в опенсорс попадешь ;)! Либо на базе Линуха либо ФриБСД.ОС на Микротиках - на Линухе, на Джуниперах - на основе Фри... ну и т.д.
Та ты не пыжся! я и сам под линукс пишу и gcc собираю. И даже комерческое. Факт в другом. Коробит линуксятника! Как черта от святой воды. Потому что сами знают что так))) Хотя там даже и пол намека на линукс нету вобще ;) А подобие стабильности появляется когда дистрибутив комерческий делают, ну командой одной, с плеткой и пряниками допиляют исходники опенсорса до пригодного к продаже вида. Так то.
Logik, чем конкретно Вам не нравится тот же MQTT на той же mosquitto для получения команд ESPхами, реально очень хотелось бы узнать подробнее.
При этом на самом деле если даже вернуться к идеи вычитывания ESPхами того же memcached или другого хранилища, то я не вижу большой проблемы делать это раз в секунду. Радиоканалу пофиг, висит ли та же ESP на сокете с MQTT брокером, ожидая команды, или общается по нему - по части трафика, ну будет раз в секунду от каждой EPS пусть даже 100 байт передаваться, как это повлияет на скорость локалки в доме? Даже 100 ESP по 100 байт в секунду породит трафик около 10 килобайт в секунду, при мощности сети как минимум в 100 мегабит, ужрав тем самым ноль целых, хрен десятитысячных процента трафика. Гуру тут могут начать истерику на тему того, что кроме самих данных еще жрет протокол, но даже выше сотых процентов лимита даже 100 датчиков не сожрут.
На тему задержек комманд на период опроса ESPхами - соглашусь, есть такая проблема, почему и стал изучать внимательно MQTT, в противном случае был вариант реально писать что-то самописное, что выдавало бы команды, но... Я сужу по своему дому, который именно дом, а не хрущевка однокомнатная и пытаюсь представить где мне критична скорость.
Свет - едва ли. Ходить по дому как дурак с планшетом или телефоном, чтобы игнорируя выключатели, которые под рукой, включать свет в комнатах я точно не буду. Если же речь к примеру о режиме освещения, типа там цвет светодиодной подстветки изменить на подходящий под настроение - то задержка в секунду не косяк, всё равно же прикола ради будет в этом блоке функция плавного перехода от цвета к цвету, от одного уровня яркости к другому.
Кондиционеру нафиг скорость не нужна, подождать секунду не проблема, учитывая, что пока эта тварь затворки откроет, пока вентиляторы раскрутит, пройдет больше, а эффективное охлаждение или тем более оборгев, при температуре даже 0 за бортом, от него раньше чем через минуту ждать вообще не имеет смысла.
Ворота гаража, учитывая время их открытия - подождут секунду, бойлер как Вы верно заметили тоже подожет, горелка на пилетах тем более, в общем абсолютно всё кроме включения света упирается во время исполнения команды исполнителем более 10-15 секунд и не требует обработки команд в реальном времени.
Со светом мне автоматизация реально нужна лишь в режиме "включить освещение двора" и "вырубить свет во всем доме" когда ложусь спать. Когда же среди ночи прижало пойти в сортир, то маловероятно, что кто-то будет искать в телефоне или планшете как свет включить в клозете, куда проще нажать клавишу, расположение которой знаешь на ощупь, есть еще вариант по датчику движения и освещенности включать свет, но у меня этот вариант не катит, так как собаки, и не чихуа, которую можно отфильтровать настройками датчиков движения, а охранные зверики, которых датчик от человека отличить не сможет.
То есть с одной стороны я понимаю, что тема MQTT при которой исполнитель получает команду мгновенно вроде бы лучше, чем опрос команд даже раз в секунду, но Вы реально смутили фразой, что MQTT в итоге упрется во что-то, не раскрыв полностью во что... С другой стороны в режиме умного дома нет как таковых realtime задач, кроме света, который всё равно включать удобнее руками по клавише на входе в комнату.
При этом на тему MQTT насколько я его смог теоретически изучить, нет там проблемы, что отправитель не знает кому нужны его данные, отправил я к примеру температуру в кабинете как cabinetetemperature=27 и кому надо из элементов системы сам на неё подпишется и получит их, отправителю знать получателя ненадо, и в этом смысле идея MQTT мне нравится. Не нравится мне в MQTT реально, что нет варианта ReadCurrentValue без подписки и отписки, и поэтому возможно в итоге сделаю гибрид в котором данные отправляются всё же в memcached, а управляющие команды для EPS идут через MQTT.
Нету там 100Мб. Там вайфай, в нем все на практике в десяток и более раз медленей. К тому же по нему все остальное в доме шарится. А короткими пакетами вайфай забется на раз.
Раз в секунду - во первых для интрерактивного комфорта мало, нужно разы в секунду, во вторых не факт что с MQTT даже раз в сек обеспечится. На пределе оно.
//стал изучать внимательно MQTT, в противном случае был вариант реально писать что-то самописное
Ну писать таки всеравно прийдется, вопрос только чего, куда и сколько. Вам же нужна будет некоторая внутреняя логика поведения частей, типа похолодало - закрываем окно, не помогло - включаем обогрев и т.д. Если уж так, чтоб совсем не писать - идем в ищу исполнителя или на фирму где все под ключ.
//в режиме умного дома нет как таковых realtime задач, кроме света
Скорость критична везде где нужна интерактивность. Регулировка громкости звука, обороты вентилятора и т.д. Будут ли и сколько таких задач у Вас - Вам видней конечно.
//MQTT при которой исполнитель получает команду мгновенно
ниче там не мгновенно. Хотя кому и через секунду - мгновенно будет. Ищите по форуму, тема про управление по MQTT уже не раз перемывалась, чтоб подымать сначала. Скажу только что держать постоянный коннект по вайфаю - очень плохая мысль. Не тот канал, валится будет часто, а обнаруживатся что отвалилось - не быстро.
//Не нравится мне в MQTT реально, что нет варианта ReadCurrentValue без подписки и отписки,
Угу. Я Вам подскажу как. Все подписаны на всех. Т.е. собираете все показания в одну xml-ину, например, и рассылаете всем. Она там в пару килобайт выйдет, вобщем пофиг, при коротких пакетах. А если еще и широковещательно сделать - воще красота.
//нет там проблемы, что отправитель не знает кому нужны его данные
Это не проблема. Это свойство датчика. И при проектировании системы его надо учитывать и использовать себе на пользу. Иначе может стать проблемой. Вобще это свойство однозначно говорит, кто тут должен быть сервером. И выворачивать логику построения системы супротив логики информационных потоков в ней - себе дороже.
//в итоге сделаю гибрид в котором данные отправляются всё же в memcached, а управляющие команды для EPS идут через MQTT.
Мрак.
//короткими пакетами вайфай забется на раз
Это решается упомянутой в этой теме логикой
if ((SendedValue!=CurrentValue) || (LastSended<millis()-PingTime)) {SendValue...}
В такой логике и данные придут по мере изменения, и нагрузка на канал минимизируется, ведь 99% датчиков меняют показания довольно редко, при этом PingTime нужен лишь для решение задачи вычисления отвалившихся датчиков, а для этого вполне достаточно пинга раз в 10 минут.
//не факт что с MQTT даже раз в сек обеспечится.
Теоретически должно быть в разы быстрее, но это предстоит проверять на практике, когда чайнамейл доставит малинку.
//Ну писать таки всеравно прийдется, вопрос только чего, куда и сколько. Вам же нужна будет некоторая внутреняя логика
Одно дело писать логику, другое дело мастерить сервер для обмена данными.
//Скажу только что держать постоянный коннект по вайфаю - очень плохая мысль. Не тот канал, валится будет часто, а обнаруживатся что отвалилось - не быстро.
Про обнаружение отвалившихся я написал чуть выше, модули которые лишь передают данные можно запрограммировать не держать коннект, а конектиться, передавать данные и отваливаться. А вот управляющим придется так или иначе быть на связи постоянно, а значит где-то по мере возможности кабель, а где-то придется писать скетч в котором 90% кода будет посвящено поддержке соединения.
/// ...нет варианта ReadCurrentValue... Угу. Я Вам подскажу как. Все подписаны на всех.
Есть простейшая задача - визуализировать в веб интерфейсе температуру в комнате, самое простое - это тому же php приконектиться к чему то, что по запросу get temperature1 вернуло бы хранящееся значение. В MQTT, если я верно понял, для этого надо записывать RETAIN=1, а на PHP каждый раз создавать новый SubscriberID, подписываться, получать значение и после отписываться, чтобы не плодились "мертвых" подписчики у MQTT брокера, что как мне кажется слишком большое количество "теледвижений" для одной операции. Более того, учитывая, что без модуля времени ни ESP ни аудуина не знают сколько времени, а MQTT не отдает как я понял время публикации сообщения подписчику, получается никак не отследить свежеть данных, а соответственно не проверить живой ли вообще датчик.