ESP, IoT WiFi лампа-будильник. Обсуждение проекта

Нажмите здесь, чтобы посмотреть текст статьи
Сообщение изъято на правах администрации
ВНИМАНИЕ !!!
те кто живой и хочет увидеть ссылку на свое исполнение, прошу централизовать все свои доработки и сообщения. Далее в теме пишем сообщение с ссылкой на ваше сообщение (с проектом), с пометкой @mechanic .

В данной ветке обсуждаются только сия проект. Общие вопросы, доработки и проблемы, не относящиеся к конкретным прошивкам!. Вопросы по прошивкам решаем в темах самих прошивок. Здесь такие разговоры оффтоп.
Всякий любой вопрос не по теме сразу удаляется БЕЗ объяснения причины!
Для этого есть соответствующие ветки форума. Вопрос почему удалили мой пост? также удаляется.
  • Общаясь на форуме будьте взаимно вежливы!
  • Обратите внимание на то, что у нас принято говорить Спасибо путём повышения репутации, нажав на кнопочку
    .
  • Если есть претензии то нажмите кнопку .
  • Запрещено писать красным цветом в ваших постах - этот цвет только для Модераторов .
  • Вопросы, ответ на которые есть в шапке или в FAQ, будут удаляться. За повторный вопрос пользователь может быть наказан.
  • Убедительная просьба придерживаться тематики ветки, избегать флуда и оффтопа!
Очень часто при первом запуске лампы, при подключении к сети лампы не открывается менеджер сетей WIFI.
Помогает комментирование строки #define ESP_USE_BUTTON (отключение кнопки) и заливка скетча выставив Erase flash в All Flash Content
После того, как вы подключили лампу к сети эту строку можно раскомментировать и залить скетч с параметром Erase flash установленным в Only Sketh
FireLamp_EmbUI (ВЕБ-интерфейс, цветомузыка, MP3 плеер, трансляции эффектов с Jinx!, etc.)
Прошивка от @Сотнег (идейное продолжение прошивки от gunner47)
Прошивка FieryLedLamp (на базе версии от Сотнег + ВЕБ-интерфейс)
Прошивка WiFiLamp with Remote Control
Наш участник собрал много полезной информации по блокам питания для лампы. Качественное питание - необходимое условие надёжной работы любого устройства. Изучаем: https://community.alexgyver.ru/threads/nebolshoj-opus-po-bp-dlja-gyverlamp-wifi-lampa-budilnik.3523/

ВНИМАНИЕ! Если у вас не компилируется или не загружается скетч - значит вы сделали что-то неправильно. Специально для вас созданы две темы:
ESP8266, проблема с компиляцией скетча
ESP8266, проблема с загрузкой скетча
Читайте (ЧИТАЙТЕ! Не пишите!) эти темы, там уже есть решение вашей проблемы.
Здесь подобные вопросы считаются оффтопом и молча удаляются, а авторы получают баллы нарушений.
 

Комментарии

recoshet

recoshet

★✩✩✩✩✩✩
15 Июн 2019
1
14
Сообщение изъято на правах администрации
ВНИМАНИЕ !!!
те кто живой и хочет увидеть ссылку на свое исполнение, прошу централизовать все свои доработки и сообщения. Далее в теме пишем сообщение с ссылкой на ваше сообщение (с проектом), с пометкой @mechanic .

В данной ветке обсуждаются только сия проект. Общие вопросы, доработки и проблемы, не относящиеся к конкретным прошивкам!. Вопросы по прошивкам решаем в темах самих прошивок. Здесь такие разговоры оффтоп.
Всякий любой вопрос не по теме сразу удаляется БЕЗ объяснения причины!
Для этого есть соответствующие ветки форума. Вопрос почему удалили мой пост? также удаляется.
  • Общаясь на форуме будьте взаимно вежливы!
  • Обратите внимание на то, что у нас принято говорить Спасибо путём повышения репутации, нажав на кнопочку
    .
  • Если есть претензии то нажмите кнопку .
  • Запрещено писать красным цветом в ваших постах - этот цвет только для Модераторов .
  • Вопросы, ответ на которые есть в шапке или в FAQ, будут удаляться. За повторный вопрос пользователь может быть наказан.
  • Убедительная просьба придерживаться тематики ветки, избегать флуда и оффтопа!
Очень часто при первом запуске лампы, при подключении к сети лампы не открывается менеджер сетей WIFI.
Помогает комментирование строки #define ESP_USE_BUTTON (отключение кнопки) и заливка скетча выставив Erase flash в All Flash Content
После того, как вы подключили лампу к сети эту строку можно раскомментировать и залить скетч с параметром Erase flash установленным в Only Sketh
FireLamp_EmbUI (ВЕБ-интерфейс, цветомузыка, MP3 плеер, трансляции эффектов с Jinx!, etc.)
Прошивка от @Сотнег (идейное продолжение прошивки от gunner47)
Прошивка FieryLedLamp (на базе версии от Сотнег + ВЕБ-интерфейс)
Прошивка WiFiLamp with Remote Control
Наш участник собрал много полезной информации по блокам питания для лампы. Качественное питание - необходимое условие надёжной работы любого устройства. Изучаем: https://community.alexgyver.ru/threads/nebolshoj-opus-po-bp-dlja-gyverlamp-wifi-lampa-budilnik.3523/

ВНИМАНИЕ! Если у вас не компилируется или не загружается скетч - значит вы сделали что-то неправильно. Специально для вас созданы две темы:
ESP8266, проблема с компиляцией скетча
ESP8266, проблема с загрузкой скетча
Читайте (ЧИТАЙТЕ! Не пишите!) эти темы, там уже есть решение вашей проблемы.
Здесь подобные вопросы считаются оффтопом и молча удаляются, а авторы получают баллы нарушений.
 
  • Лойс +1
Реакции: dnmer, Санечка снимает, Inei и 11 других
D

didiv

✩✩✩✩✩✩✩
14 Ноя 2019
8
1
Evilinarm написал(а):
Всем привет!
Собрал лампу, поставил прошивку от @gunner47

При прошивке выпадает такая ошибка - что не так? Не понимаю.
Нажмите для раскрытия...
Это варнинги, на функционал не влияют. Смотрите настройки временной зоны в constants.h.
PS: поменял строчку
C++: 
#define LOCAL_OFFSET          (0 * 60)                      // смещение локального времени относительно универсального координированного времени UTC в минутах
стало время по Гринвичу.
 
Изменено:
wayfarermax

wayfarermax

✩✩✩✩✩✩✩
30 Июл 2019
5
1
@Koteyka, здравствуйте! Спасибо за приложение. Заметил одну вещь. Через ваше приглашение не получается выставить "тёплый цвет" в режиме "Белый свет". Если настроить его сначала в приложении от @gunner47, то крутилка "Скорость" показывает с минусом значение.
Screenshot_20191202-230042.jpg
Установленны последние версии прошивки от gunner47 и вашего приложения.
 
E

Evilinarm

✩✩✩✩✩✩✩
2 Дек 2019
2
0
didiv написал(а):
Это варнинги, на функционал не влияют. Смотрите настройки временной зоны в constants.h.
PS: поменял строчку
C++: 
#define LOCAL_OFFSET          (0 * 60)                      // смещение локального времени относительно универсального координированного времени UTC в минутах
стало время по Гринвичу.
Нажмите для раскрытия...
Огромное спасибо! Всё получилось! :cool:
 
P

platon70

✩✩✩✩✩✩✩
6 Окт 2019
6
0
53
didiv написал(а):
У меня две лампы и эта проблема проявляется часто. Иногда само восстанавливается. Грешу на конфликт одновременного получения времени и его вывод.
Время поправить легко (это же миллисекунды). Поставьте 31UL*60UL*1000UL (это 31 минута), например.
Нажмите для раскрытия...
По началу все шло хорошо. Время шло синхронно. Сегодня утром отставание опять возобновилось, теперь на -31 минуту. Изменил NTP сервер с российской локацией. По результатам отпишусь.
 
vvip

vvip

★★★★✩✩✩
18 Дек 2018
459
204
platon70 написал(а):
По началу все шло хорошо. Время шло синхронно. Сегодня утром отставание опять возобновилось, теперь на -31 минуту. Изменил NTP сервер с российской локацией. По результатам отпишусь.
Нажмите для раскрытия...
Что-то есть какие-то смутные ощущения (кода не видел, просто предположение) - что подобное происходит, когда запрос к серверу отправляется, а ответа не приходит. Или приходит 0 как "нет ответа". Тогда в момент когда синхронизация (не) приходит в xx:30 - оно с 30 сбрасывает в 0. Получается отставание на 30 минут. Если это действительно так - тогда синхронизация раз в 60 минут по целым часам даже в случае когда ответ (не) придет - минуты сбросятся в 0. Попробуйте выставить период синхронизации раз в 60 минут. Но это так - в порядке бреда.
Раз ошибка повторяется у многих - значит проблема действительно есть и автору прошивки стоит посмотреть этот момент внимательнее, что происходит...
 
vvip

vvip

★★★★✩✩✩
18 Дек 2018
459
204
Вот такой код в прошивке:
C++: 
      timeSynched = timeClient.update() || timeSynched;                   // если время хотя бы один раз было синхронизировано, продолжаем
      if (!timeSynched)                                                   // если время не было синхронизиировано ни разу, отключаем будильник до тех пор, пока оно не будет синхронизировано
      {
        return;
      }
Если время не было ни разу синхронизировано и синхронизация не удалась - понятно - возвращаемся и ничего не делаем.
А вот если уже было синхронизировано и очередной вызов timeClient.update() вернул false - есть гарантия, что время осталось корректным?
Может быть стоит и в этом случае просто вернуться и не делать все то что ниже выполняется в случае, когда синхронизация удалась. Ибо зачем?
Не тут ли проблема с этим периодическим отставанием?
 
Koteyka 🐱

Koteyka 🐱

★★★★★★✩
Команда форума
27 Окт 2019
935
556
54
Днепр, Украина
firelamp.pp.ua
wayfarermax написал(а):
@Koteyka, здравствуйте! Спасибо за приложение. Заметил одну вещь. Через ваше приглашение не получается выставить "тёплый цвет" в режиме "Белый свет". Если настроить его сначала в приложении от @gunner47, то крутилка "Скорость" показывает с минусом значение.
Посмотреть вложение 6210
Установленны последние версии прошивки от gunner47 и вашего приложения.
Нажмите для раскрытия...
Исправлю. В моей лампе просто тёплый свет отключён. Вот и в приложении, видимо пропустил
 
  • Лойс +1
Реакции: t_igr, solevi и Frolv
Koteyka 🐱

Koteyka 🐱

★★★★★★✩
Команда форума
27 Окт 2019
935
556
54
Днепр, Украина
firelamp.pp.ua
  • Лойс +1
Реакции: Frolv, wayfarermax и solevi
G

gunner47

★★★★★✩✩
18 Июн 2019
253
393
vvip написал(а):
Вот такой код в прошивке:
C++: 
      timeSynched = timeClient.update() || timeSynched;                   // если время хотя бы один раз было синхронизировано, продолжаем
      if (!timeSynched)                                                   // если время не было синхронизиировано ни разу, отключаем будильник до тех пор, пока оно не будет синхронизировано
      {
        return;
      }
Если время не было ни разу синхронизировано и синхронизация не удалась - понятно - возвращаемся и ничего не делаем.
А вот если уже было синхронизировано и очередной вызов timeClient.update() вернул false - есть гарантия, что время осталось корректным?
Может быть стоит и в этом случае просто вернуться и не делать все то что ниже выполняется в случае, когда синхронизация удалась. Ибо зачем?
Не тут ли проблема с этим периодическим отставанием?
Нажмите для раскрытия...
Быстрый анализ моего кода меня на ошибку не натолкнул.
А вот если уже было синхронизировано и очередной вызов timeClient.update() вернул false - есть гарантия, что время осталось корректным?
Нажмите для раскрытия...
Если так, тогда timeSynched == true, и должно использоваться время, которое было синхронизировано ранее, - timeClient.getEpochTime(), в котором к моменту синхронизации добавляются тики резонатора esp'шки. Т.е., время просто не уточнится, но за полчаса-час (1-2 неудачные синхронизации) большой накопительной ошибки быть и не может.
Я копал внутренности библиотеки NTPClient, и пока грешу на неё. Действительно, всё указывает на то, что она отмечает момент синхронизации, когда отправляет пакет, а не когда получает успешный ответ. И потом использует его как точку отсчёта. Естественно, в библиотеку я лезть не стану. Тут выходы такие:
  1. Посмотреть практики использования этой библиотеки
  2. Заменить на другую, более надёженую
  3. Проверять timeClient.getEpochTime() до отправки на сервер и после, если время уменьшилось на величину, сопоставимую с периодом синхронизации, значит, произошла ошибка и нужно её скорректировать
  4. Забить на регулярное уточнение времени, оставить попытки синхронизации только до первой успешной
Если уж увеличивать период синхронизации, тогда резонно делать это раз в сутки. Тогда даже при неуспешной синхронизации и том коде, который есть сейчас, время не сдвинется. Но может сдвинуться день недели, и у кого-то будильник "рассветёт" не в тот день :)

Подумаю...
 
Изменено:
  • Лойс +1
Реакции: somon, Koteyka 🐱 и solevi
vvip

vvip

★★★★✩✩✩
18 Дек 2018
459
204
gunner47 написал(а):
Быстрый анализ моего кода меня на ошибку не натолкнул.

Если так, тогда timeSynched == true, и должно использоваться время, которое было синхронизировано ранее, - timeClient.getEpochTime(), в котором к моменту синхронизации добавляются тики резонатора esp'шки. Т.е., время просто не уточнится, но за полчаса-час (1-2 неудачные синхронизации) большой накопительной ошибки быть и не может.
Я копал внутренности библиотеки NTPClient, и пока грешу на неё. Действительно, всё указывает на то, что она отмечает момент синхронизации, когда отправляет пакет, а не когда получает успешный ответ. И потом использует его как точку отсчёта. Естественно, в библиотеку я лезть не стану. Тут выходы такие:
  1. Посмотреть практики использования этой библиотеки
  2. Заменить на другую, более надёженую
  3. Проверять timeClient.getEpochTime() до отправки на сервер и после, если время уменьшилось на величину, сопоставимую с периодом синхронизации, значит, произошла ошибка и нужно её скорректировать
  4. Забить на регулярное уточнение времени, оставить попытки синхронизации только до первой успешной
Если уж увеличивать период синхронизации, тогда резонно делать это раз в сутки. Тогда даже при неуспешной синхронизации и том коде, который есть сейчас, время не сдвинется. Но может сдвинуться день недели, и у кого-то будильник "рассветёт" не в тот день :)

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

Я у себя не использую библиотеки. Сам отправляю UDP - запрос на сервер, сам получаю ответ, сам разбираю полученное время.
Каких-то вот таких проблем с +/-30 минут не наблюдал никогда и не вижу причин, чтобы такое произошло.
Правда у тебя там навороченный переход на зимнее/летнее, автовычисление часового пояса (вроде). У меня этого нет.
Т.к. писал исключительно для себя, а у нас тут нет зимнего/летнего и смещение от UTC всегда одно... Не стал заморачиваться
 
G

gunner47

★★★★★✩✩
18 Июн 2019
253
393
vvip написал(а):
Да нет, вроде по внутренностям момент синхронизации устанавливается когда получен ответ.
Судя по коду - ошибки быть не должно, но судя по отзывам - что-то идет не так.

Я у себя не использую библиотеки. Сам отправляю UDP - запрос на сервер, сам получаю ответ, сам разбираю полученное время.
Каких-то вот таких проблем с +/-30 минут не наблюдал никогда и не вижу причин, чтобы такое произошло.
Правда у тебя там навороченный переход на зимнее/летнее, автовычисление часового пояса (вроде). У меня этого нет.
Т.к. писал исключительно для себя, а у нас тут нет зимнего/летнего и смещение от UTC всегда одно... Не стал заморачиваться
Нажмите для раскрытия...
Часовые пояса не могут дать ошибку в 30 минут. Они же кратны часу. 30 минут - это как раз время синхронизации с ntp сервером. Тем более, тут писали о том, что при изменении интервала синхронизации изменяется и ошибка.
Если момент синхронизации соответствует ответу от сервера, значит, остаётся только одно место для ошибки - неправильно распознанный ответный ntp-пакет. Время не корректируется, а текущий момент синхронизации проставляется в качестве точки отсчёта.
Если предположение о нераспознанном пакете подтвердится, то будет большой вопрос - а чем это будет отличаться от самописной реализации? И как защититься от ошибки в этом случае?
 
G

gunner47

★★★★★✩✩
18 Июн 2019
253
393
Koteyka написал(а):
Могут. Есть пояса, кратные 30 мин.
Посмотреть вложение 6224
И таких много
Нажмите для раскрытия...
Таких немного. Я выше уже кидал ссылку на видео о часовых поясах и проблеме подсчёта разницы во времени между текущей датой и произвольным моментом в истории.
Это абсолютно не относится к нашему случаю.
Или у вас есть информация о том, что кто-то из владельцев лампы использует не кратные часу часовые пояса?
 
Koteyka 🐱

Koteyka 🐱

★★★★★★✩
Команда форума
27 Окт 2019
935
556
54
Днепр, Украина
firelamp.pp.ua
gunner47 написал(а):
Или у вас есть информация о том, что кто-то из владельцев лампы использует не кратные часу часовые пояса?
Нажмите для раскрытия...
В данный момент сомневаюсь, но вдруг кто-то в Исландию с лампой поедет :cool:
 
G

gunner47

★★★★★✩✩
18 Июн 2019
253
393
Koteyka написал(а):
В данный момент сомневаюсь, но вдруг кто-то в Исландию с лампой поедет :cool:
Нажмите для раскрытия...
Тогда будет совсем печально... Во1, ошибка может стать кратна часу :) Во2, багрепорты на исландском... эйяфья и вот это всё - ну его )
 
  • Лойс +1
Реакции: Koteyka 🐱
vvip

vvip

★★★★✩✩✩
18 Дек 2018
459
204
gunner47 написал(а):
Если предположение о нераспознанном пакете подтвердится, то будет большой вопрос - а чем это будет отличаться от самописной реализации? И как защититься от ошибки в этом случае?
Нажмите для раскрытия...
Ну так может если update() вернуло false - не делать всех дальнейших расчетов и корректировки времени, пока не вернет true?Ну или хотя бы этот LastUpdate как-то корректировать...
 
Изменено:
A

AnatolyDem

✩✩✩✩✩✩✩
30 Сен 2019
10
1
Россия
AndyIP написал(а):
Собрал проект на основе прошивки от vvip-68, с часами и звуком.

Здравствуй. У меня с печатью ваших моделей на 3d принтер проблема ...заказал у человека напечатать...основание напечаталось без части где стоит индикатор...недавно купил себе принтер, немного научился печатать...решил перепечатать, в Куре модель основания выглядит нормально, подготовил модель для печати...потом решил посмотреть, а модель опять оказалась без выступа :( пробовал в разных прогах, получается так же
1.jpg
Нажмите для раскрытия...
 
P

platon70

✩✩✩✩✩✩✩
6 Окт 2019
6
0
53
У кого из вас проявилась эта ошибка? Может это связано с часовым поясом? Я живу на Урале +5 UTC. Прошил скетч со строкой:
#define NTP_INTERVAL (60UL * 60UL * 1000UL) // интервал синхронизации времени (60 минут)

Завтра отпишусь по результату.
P.S.: Смена сервера синхронизации не помогло...
 
A

AndyIP

★★✩✩✩✩✩
3 Июл 2019
91
50
Да. Там есть баг. Видимо sketchup как то криво импортирует :(
Можно подправить STL-ку на специальном сайте :)
https://service.netfabb.com/
Вот исправленная этим сайтом STL-ка
 

Вложения

Изменено:
  • Лойс +1
Реакции: AnatolyDem
Войдите или зарегистрируйтесь для ответа.
Сверху Снизу