Ви не увійшли.
Пишу програму для керування воротами з смартфона. Вона працює через MQTT брокер HiveMq. Виникло питання документувати звернення до брокера.
Документувати спробував в таблицю Google Sheets. Окремо все працює, але коли пробую сумістити, то на брокер і в Google Sheets не доходять деякі повідомлення. Почав аналізувати:
- після кожної передачі запита на Google Sheets відбувається reconnect() до MQTT брокера. В середньому reconnect займає 1,04 сек;
- публікація до MQTT брокера займає в середньому 0,147 сек;
- передача тих самих даних в Google Sheets займає 3,372 сек. Деякі запити потребують ще більше часу.
Виходить що при передачі в Google Sheets і при реконекті програма не отримує повідомлень від MQTT брокера.
Як зробити так, щоб не губити дані. Я ще хотів відправляти повідомлення на Telegram Bot.
// Create an instance of the WiFiClient object
WiFiClientSecure clientG;
// Create an instance of the PubSubClient object
PubSubClient client(clientG);
clientG - використовуються для передачі в Google Sheets. А client для взаємодії з MQTT брокером.
В циклі loop раз в 10 сек відбувається відправка даних даних на брокер:
SendState();
і в Google Sheets.
SendGoogleData();
Як правильно організувати роботу з декільками серверами одночасно?
Неактивний
Зачем Вы занимаетесь колхозом? Не экономьте, делайте нормально. "Документируйте" в базу данных (для чего их и придумали) на собственном сервере (например, хоть на том же копеешном Orange Pi) с резервным питанием. Завтра Гугл изменит политику доступа к таблицам и что Вы будете делать?
1) Я не маю і ніколи не працював з Orange Pi.
2) Мені здається це особливо нічого не змінить. Якщо звернення до Orange Pi буде вимагати працювати по WiFi, то буде теж саме блокування. Цей випадок не вимагає резервного живлення. Коли немає живлення, то не працюють і ворота.
Ось ChatGpt рекомендував мені використовувати бібліотеки, що підтримують асинхронні операції. Зараз пробую AsyncMqttClient.h. Хоча для цього знадобиться додатковий час.
Неактивний
Зачем Вы занимаетесь колхозом? Не экономьте, делайте нормально. "Документируйте" в базу данных (для чего их и придумали) на собственном сервере (например, хоть на том же копеешном Orange Pi) с резервным питанием. Завтра Гугл изменит политику доступа к таблицам и что Вы будете делать?
А еще лучше по старинке - "Документируйте" в тетрадку. Завтра копеешный Orange Pi выйдет из строя и что вы будете делать?
1) Я не маю і ніколи не працював з Orange Pi.
2) Мені здається це особливо нічого не змінить. Якщо звернення до Orange Pi буде вимагати працювати по WiFi, то буде теж саме блокування. Цей випадок не вимагає резервного живлення. Коли немає живлення, то не працюють і ворота.
Ось ChatGpt рекомендував мені використовувати бібліотеки, що підтримують асинхронні операції. Зараз пробую AsyncMqttClient.h. Хоча для цього знадобиться додатковий час.
Мне кажется или Вы путаете понятия WiFi и интернет? И я кстати ничего не говорил про беспровод. Можно кинуть LAN и связать в локалку и сервак и исполнительное устройство.
"Я не маю і ніколи не працював з Orange Pi" - Linux SBC лучший способ познакомится с практической стороной.
"Ось ChatGpt рекомендував мені використовувати бібліотеки" - он многое может порекомендовать. Вот только о правильных (с точки зрения промышленности/стандартов/безопасности/быстродействия) подходов ему неизвестно.
"А еще лучше по старинке - "Документируйте" в тетрадку."
Эм... странный выпад... Вы либо не понимаете что такое БД и зачем они нужны либо это какой-то толстый троллинг.
"Завтра копеешный Orange Pi выйдет из строя и что вы будете делать?" - что за логика? Завтра машины выйдут из строя, давайте сразу все ходить пешком и носить 20 тонные бетонные блоки всем селом руками ..
А для учета отказа оборудования придумали бекапы. Железку можно просто заменить (часто даже не обязательно на такую же), и восстановить бекапы и вуаля - работоспособность проекта восстановлена. Это если по уму делать.
Из личного опыта сколько лет у меня трудятся SBC - ни один не вышел из строя. Видимо вероятности отказа мизерные
что за логика?
Ну вот вы и объясгите что за логика
Завтра Гугл изменит политику
И я кстати ничего не говорил про беспровод. Можно кинуть LAN и связать в локалку и сервак и исполнительное устройство.
В мене проект домашній, для себе. Всі роботи виконую так, щоб було не дорого.
Я дійсно слабо розбираюсь в багатьох питаннях, тому і задав знатокам.
Асинхронна передача на MQTT вже майже працює. Правда змінив чип на ESP32.
Остання редакція AmateurFF (2023-06-14 21:41:52)
Неактивний
Асинхронна робота з MQTT брокером і Телеграм ботом працює.
Використовую бібліотеку https://github.com/khoih-prog/AsyncMQTT_ESP32 для роботи з HiveMq, та https://github.com/cotestatnt/asynctelegram2. За основу взяв приклади які там надаються.
Гірше справи для організації асинхронної передачі на Google Sheets. Пробував використати https://github.com/leanhd/AsyncHttpClient, але до неї немає прикладів, а сам я не розібрався як її використати для роботи з Google Sheets. В мережі теж не знайшов ніяких прикладів асинхронної роботи з Google Sheets. Може хтось користувався бібліотекою AsyncHttpClient і може підсказати як її примінити? Чи може є якись інший спосіб як організувати роботу з Google Sheets, щоб вона не заважала роботі з Телеграм ботом і MQTT брокером?
Остання редакція AmateurFF (2023-06-15 19:59:03)
Неактивний
Нажаль з таблицями Гугл не склалося. Тому вирішив трохи змінити підхід. Долучаю МікроСД карту до мого проекта. Так, як я не зміг освоїти асинхронний доступ до Гугл таблиць, я вирішив зберігати історію роботи воріт в СД картці. Таким чином керування воротами буде виконуватись з мобільних телефонів через додаток, що з'єднується з модулем керування воротами на ESP32-C3-DevKitM-1 через MQTT брокер. Аварійні ситуації будуть відправлятись користувачам на Телеграм Бот. А історія зберігатись в МікроСД. Її навіть можна буде переглядати на мобілці, отримуючи інформацію через MQTT. Поки що так. Тепер треба все зібрати до кучі і перепаяти плату.
Остання редакція AmateurFF (2023-06-17 22:57:58)
Неактивний
Почему бы просто не установить очередность отправки данных? Сначала отправляете команды управления, убеждаетесь в их выполнении и потом уже таким же образом пишете в телегу и гугл. Или у вас ворота непрерывно открываются/закрываются что прям нужно все писать в реал-тайме?
Почему бы просто не установить очередность отправки данных? Сначала отправляете команды управления, убеждаетесь в их выполнении и потом уже таким же образом пишете в телегу и гугл. Или у вас ворота непрерывно открываются/закрываются что прям нужно все писать в реал-тайме?
1) Команди керування по своїй природі асинхронні.
2) Передача даних в Гугл займає більше 3 секунд. Після передачі блока даних відбувається повторне підключення до MQTT брокера, і це реконект займає більше 1 сек. В цей час (передача даних в Гугл, реконект) прийом команд не можливий.
3) В дійсності я не займався оптимізацією відправки, навпаки я намагався передавати всю інформацію (а це 15 стовців таблиці Гугл) . Оптимізація дійсно може значно зменшити втрачання інформації, але не виключити його.
4) Переведення вчити заємодії з MQTT, Telegram, Google повинно було виключити втрату інформації. Це я і наблюдав коли перевів роботу з MQTT і Telegram в асинхронний режим. Нажаль з Google таблицями я не зміг осилити асинхронну передачу. Тому я і вирішив зберігати дані в МікроСД.
Я вже перепаяв плату і зараз займаюсь відладкою і написанням нової версії програми.
Неактивний