Часы на esp8266 и max7219 + android управление

Тема в разделе "Глядите, что я сделал", создана пользователем IvanUA, 28 авг 2017.

?

Вы повторили это проект?

  1. Нет (просто ознакомился)

    35 голосов
    13,3%
  2. Да, один раз (попробовал)

    111 голосов
    42,0%
  3. Да, не однократно

    122 голосов
    46,2%
Можно выбрать сразу несколько вариантов.
  1. IvanUA

    IvanUA Гуру

    Сделал вкладку меню "Настройки" мультиязычной. Попутно нашел и поправил пару косяков.
    В самой прошивке часов, тоже есть небольшие правки для соместимости с приложением.
    Так что для тестов надо обновить и прошивку и приложение.
    [​IMG]
     
    Vladis_a нравится это.
  2. spazmalgon

    spazmalgon Нерд

    Доброй ночи.
    1. В новой прошивке данные погодного сервера не выводятся на модули, хотя в web интерфейсе значения погодного сервера отображаются.
    2. После внесения настроек, часы самопроизвольно перегружаются ( по прошествии ~ 28 мин.)
     
  3. IvanUA

    IvanUA Гуру

    Попробуйте стереть флеш, и записать прошивки и флеш по новой. Возможно остались "хвосты" от предыдущей прошивки.

    ПС. В приложение добавил перевод списка меню, настройки WiFi, время, памятные даты, погода.
     
    Последнее редактирование: 7 июл 2023
  4. mikhail09p

    mikhail09p Гик

    Здравствуйте.
    Вот уже несколько лет работают у меня несколько экземпляров Ваших, Иван, часов. В основном прошивка 4.1. Одни с 5.1. Без RTC. В последние дни (или недели...) неправильно кажут время. По крайней мере 2 экземпляра точно. Не на час врут, а хаотично... Ни у кого не было? Сегодня добавлю модуль RTC. Сервер был windows, заменил на ntp3.time.in.ua Не помагает.
     
  5. big_alex

    big_alex Гик

    Тоже заметил сбои, прошлой осенью установил RTC но прошивка была 4.1, недавно обновил на 5.0.31 и периодически часы отстают на время заданное в ntpTimer=millis()+3600000; // при удачном обновлении повтор через 60 минут

    Смотрел на роутере журнал запросов DNS, погода запрашивается четко раз в час, а вот время и народмон всего 2-4 раза в сутки
     
  6. IvanUA

    IvanUA Гуру

    Здраствуйте.
    В принице я особо ничего не менял в прошивках в плане расчета времени.
    Хаотично - это можна как то по подробнее.
    В последних прошивках я сделал двойной запрос времени. Это было связано с тем что при включении (когда нет РТЦ) часы делают первый расчет и коррекция идет по зимнему времени. Получается что после перезагрузки иногда часы ошибались у меня к примеру на 1 час. Так вот, сейчас после включения, часы получают время, все просчитывают и в течении минуты снова получают время. Если в первый раз возникла ошибка при коррекции зима/лето, то вторым запросом это устраняется.
    Что бы не городить такой геморой можно было бы отказаться от функции перевода на зима/лето или жестко ее закрепить, но .... пока будет так.

    ППС. Как и прежде, если есть возможность обновиться более новой прошивкой (если вам она подходит с урезаными функциями) то я бы советовал это все же сделать. В процессе модернизации прошивок, находятся "косячки" которые я стараюсь устранить.
     
  7. big_alex

    big_alex Гик

    дело в том что сбой происходит в процессе работы, без перезагрузки и на величину периода успешной синхронизации.
    Я делал период 15 минут ntpTimer=millis()+900000; и часы сбивались на 15 минут, вроде как переход зима/лето не причем
    И по идее я должен видеть на роутере запросы к NTP каждые 15 минут, но этого нет, может быть раза 3-4 за сутки
     
  8. IvanUA

    IvanUA Гуру

    Очень странно
    Код (C++):
        //-----------Отримання часу від NTP серверу---------------------------
        if (ntpTimer < millis() && !alarm_work) {
          printTime();
          Serial.println(" --- Время запроса");
          timeUpdateNTP();
          if (statusUpdateNtpTime == 0) ntpTimer = millis() + 300000; //при невдалому оновлені повторення через 5 хвилин
          else ntpTimer = millis() + 900000; // при вдалому обновлені повторення через 60 хвилин
        }
      }
    Попробуйте для начала в компорт выводить просто время когда должен происходить запрос.
    Если будет в компорт вылетать "--- Время запроса" каждые 15 минут, то будем разбираться с функцией timeUpdateNTP();
    Если нет, то нужно будет искать почему не срабатывает условие ntpTimer < millis() && !alarm_work
     
  9. mikhail09p

    mikhail09p Гик

    В двоих часах установил RTC. Так что не помогу, наверное... Работают.
    Кстати, когда заказывал RTC, купил pcf8563. С той точки зрения, что хоть у них точность похуже, чем DS3231, но дешевле чуть и всё равно, время постоянно обновляется с интернет.
    А у них адресация то другая. Неувязка получилась... :)
     
  10. IvanUA

    IvanUA Гуру

    Да, я использую адреса 67, 68 а у этого модуля я так понимаю 51-й
    Если команды те же то без проблем его можно добавить в прошивку.
    Какую прошивку вы используете.
    Если не последнюю, то сами сможете вписать, или помочь?
     
    mikhail09p нравится это.
  11. big_alex

    big_alex Гик

    временно поставил период обновления 3 минуты
    К UART подключаться не очень удобно поэтому я просто добавил bip(); bip(); сразу в функцию getNTPtime() и каждые 3 минут часы пикают по 3 раза
    но DNS запросов нет
    Код (C++):
    //==========ОТРИМАННЯ ДАТИ ТА ЧАСУ ВІД СЕРВЕРА ТОЧНОГО ЧАСУ =============================================================
    void getNTPtime(){
      WiFi.hostByName(times.ntpServerName.c_str(),timeServerIP);
      bip();bip();
      int cb;
    В функции getNTPtime() если я правильно понял отправляется 3 запроса с паузой 800 мс, т.е всего длительность около 2,5 сек
    при этом сама функция вызывается из timeUpdateNTP() тоже три раза, соответственно пауза между сигналами должна быть около 2,5 сек, верно?
    Просто этой паузы нет, такое ощущение что delay(800); не работает
     
  12. mikhail09p

    mikhail09p Гик

    Спасибо, но команды другие. И адреса регистров не совпадают. Не заморачивайтесь, мелочи.
     
  13. IvanUA

    IvanUA Гуру

    Код (C++):
    udp.beginPacket(timeServerIP, 123);                    
        udp.write(packetBuffer, NTP_PACKET_SIZE);
        udp.endPacket();
        delay(800);                                            
        cb = udp.parsePacket();
    После каждого запроса есть пауза в 800 мс.
    По механизму совершенно верно. При запросе времени подается до трех запросов, если ответ получен уже после первого то цикл заканчивается, дальше выполняется "разкладывание" времени во временные переменные. И так три раза если есть удачные ответы. Потом эти временные переменные сравниваются и если все три раза было полученно одно и тоже время (секунды не всчет), то только тогда это время уже обновляется в часах и в часовом модуле (если он установлен).
     
  14. IvanUA

    IvanUA Гуру

    Ничего сложного нет.
    1.
    в файле rtc.h
    в строке #defineDS_RTC_TIME 0x00
    надо поменять значение на 0х02
    2.
    в основном коде
    Код (C++):
    Wire.beginTransmission(0x67);
      errorRTC=Wire.endTransmission();
      if(errorRTC==0){
        rtcAddr=0x67;
    0x67 поменять на 0х51

    Должно работать)))

    Если возможно проверьте. Если заработает, то я добавлю этот модуль в последующую прошивку.
     
  15. ivan_alexoff

    ivan_alexoff Гик

    @IvanUA Вопрос о "погодной точке" - до обновления прошивки на v58 точка в конце дисплея постоянно мигала. Сейчас она появляется по непонятно каким событиям. Большая часть времени ее нет. Две точки, одна в начале, другая в конце я так понимаю мигают при сбое запросов к серверу. Не то что она нужна эта точка, просто больше из инетерсу хочется узнать за нее :)
     
  16. big_alex

    big_alex Гик

    Похоже timeUpdateNTP(); отрабатывает нормально, где косяк непонятно
    Поставил период синхронизации 5 минут и если время слетит то через 5 минут должно исправиться, но костыль так себе
     
  17. DiMaro

    DiMaro Нерд

    По поводу синхронизации времени...
    не при чем зона, не при чем лето c зимой и NTP серверы не причем
    проявление глюка чаще всего заметно именно при перезагрузке или при холодном старте только потому, что время еще ни разу успешно не синхронизировано и отличается от реального значительно
    в процессе работы это менее заметно но может проявляется по разному (как карта ляжет), например, может откатываться (отставать) ровно на время периода синхронизации с NTP сервером указанное в настройках, стоит добавить строчку в код в любом участке кода и проявление проблемы может измениться

    решал эту проблему и сейчас с этим точно все нормально, главное чтобы интернет не подводил и пакет в 48 байт NTP сервер вернул вовремя... достаточно однократного запроса

    RTC, кстати, не спасет, глюк и в нем все старательно перепишет... если только синхронизацию вообще отключить

    проблема связана с нарушением атомарного доступа к глобальным переменным времени hour, minute, second... и переменным даты (во всяком случае в 4 версиях точно, за последние ничего утверждать не берусь)
    даже логи старые остались на компе
    Иван думаю догадается, что за воскличательные знаки в логе и почему в итоге такое странное время :)
    Код (C++):
    20:04:19.396 -> 12:00:00>NTP Packet Received (48 byte)
    20:04:19.396 ->      From IP: 194.190.168.1
    20:04:19.396 ->      port: 123
    20:04:19.396 ->      Data:
    20:04:19.396 ->      -----------------------
    20:04:19.396 ->      24 01 06 E8 00 00 00 00
    20:04:19.396 ->      00 00 00 47 47 50 53 00
    20:04:19.396 ->      E7 96 3D 8C 62 43 D9 47
    20:04:19.396 ->      00 00 00 00 00 00 00 00
    20:04:19.396 ->      E7 96 3D 93 41 08 80 C6
    20:04:19.396 ->      E7 96 3D 93 41 09 A1 13
    20:04:19.396 ->      -----------------------
    20:04:19.396 -> Время ожидания ответа t4 = 65 ms
    20:04:19.396 -> Временная метка t2 = 254 ms
    20:04:19.443 -> Временная метка t3 = 254 ms
    20:04:19.443 -> Время обработки сервером = 0 ms
    20:04:19.443 -> текущий ping = 65 ms
    20:04:19.443 -> -----------------------
    20:04:19.443 -> highWord = E796
    20:04:19.443 -> lowWord = 3D93
    20:04:19.443 -> secsSince1900 = E7963D93
    20:04:19.443 -> epoch = 63EBBF13
    20:04:19.443 -> -----------------------
    20:04:19.443 -> unix = E7963D93
    20:04:19.443 -> Время с 1 января 1900 года = 3885383059 сек.
    20:04:19.443 -> -----------------------
    20:04:19.443 -> unix = 63EBBF13
    20:04:19.443 -> Время Unix от 1 января 1970 года = 1676394259 сек.
    20:04:19.443 -> -----------------------
    20:04:19.497 -> unix + ping = 63EBBF13
    20:04:19.497 -> unix + Zone = 63EBE943
    20:04:19.497 -> -----------------------
    20:04:19.497 -> time = 4BCA
    20:04:19.497 -> hour = 20
    20:04:19.497 -> minute = 4
    20:04:19.497 -> second = 19
    20:04:19.497 -> !
    20:04:19.497 ->      Time: 12:00:00
    20:04:19.497 ->      Date: 14.02.2023 Weekday = 3
    20:04:19.497 ->      Time Updated Successfully
    20:04:19.597 -> !
     
    Последнее редактирование: 13 июл 2023
  18. IvanUA

    IvanUA Гуру

    Точка в начале дисплея - ошибка получения прогноза на сейчас.
    Точка в конце диспелея - ошибка получения прогноза на сегодня/завтра.
    Анимацию ошибки можно выключить в настройках.
    В последней прошивке на каком то сервере я менял запросо на сегодня/завтра (он не работал с новыми АПИ). Возможно вы как раз попали что у вас не было прогноза, а теперь он иногда есть))))
    Здесь я так понимаю ситуация особенная, надо пробовать разные варианты, хотя бы методом исключения. Я привык искать проблему создавая маркеры вывода в ком порт... так понимаю где затык.
    Я делал три запроса подряд именно с той целью что бы при плохом интернете имемть больше шансов не "сломать" текущее время)))
    дело в том что сейчас я бы сделал запрос проще... Я бы не распаковывал Юникс время (количество секунд от 1.1.1970) на минуты часы и так далее, а просто получал бы три его значения, сравнивал бы их, и если они отличаются не более чем на величину периода запроса +/-, то тогда бы расчитывал бы полное время и дату... Но это время, у меня с ним сейчас немного напряг, може быть позже....

    ПС. Закончила наконец пилить приложение. Есть перевод для всех вкладок. Для корректной работы приложения и часов, прошивку в часах тоже стоит обновить из той же папки что и приложение
    https://drive.google.com/drive/folders/14w48Io_iZ6RJkBmL0gccqlWDtGQvLgX2?usp=drive_link
    Если замечаний к работе приложения не будет, выложу его в Плеймаркет.
     
  19. DiMaro

    DiMaro Нерд

    Иван, эту "особенную" ситуацию в своем сообщении жирным выделил :)
    время "ломает" глюк, а не отсутствие совсем необязательных дополнительных запросов.
    три запроса возможно этот глюк замаскируют, но не всегда, опять же, как карта ляжет.
    а вот устранив причину отпадет необходимость в этом костыле, в виде многократных запросов, сравнений и бестолковых задержек по 800мс.
    только это почти ничего не изменит и не приведет к ожидаемому положительному результату, малость ускорит процесс на несколько микросекунд, но на фоне задержек по 800мс, равных количеству запросов - это ничтожно мало (в сумме то более 2.4 секунды)
    лог выше в моем сообщении, это результат работы моей тестовой программы для анализа ответа сервера и общей ситуации в целом, потому такой подробный, в самом проекте без излишеств... и вообще без задержек. определен необходимый тайм аут ожидания UDP пакета. ждать можно сколько угодно... когда получаем тогда и анализируем.
    и еще этот лог, до устранения глюка, демонстрирует что при вполне корректном ответе сервера... на выходе можем иметь, после окончания обработки ответа, совсем некорректное локальное время
     
  20. IvanUA

    IvanUA Гуру

    Как минимум это изменит код, немного сократится процессорное время на лишнюю распаковку данных. И вполне возможно что во время вывода бегущей строки уберет возможное подтормаживание.
    Конечно можно из пакета получить разрешенный сервером период запросов, рассчитать RTT и сформировать свою паузу между подачей запросов. Но я прошу прощения, мы же не строим эталонные часы синхронные с атомными. Вот именно по этому выбрано время в 800мс, с головой достаточное что бы сервер нас не "послал".
    Как бы там ни было я убрал эту задержку и из логов видно что мой сервер меня посылает акурат на третьем запросе. По этому сделал паузу в 64мс после запроса, и если был "послан" то тогда 800мс.
    Ну это уже проблемы вашего кода, если он не может корректно разложить 4 байта временной метки. Я отправляю 3 запроса и если полученного времени больше чем на пару секунд, то я не обновляю локальное время и в часовом модуле тоже его не обновляю. А вот если все три метки времени очень близки (с учетом особенностей доставки UDP пакетов) то я принимаю поледнее полученное время как истенное, и только тогда обновляю время локальное и в часовом модуле.
    4 байта = 32 бита. Если глюк попал в младший бит, то это секунды, а если глюк попал в более старший бит, то это могут быть минуты, часы, года.... Как думает какова вероятность того что глюк три раза попадет в тот же бит? Вот и я думаю что вероятность поймать ошибку стремится к нулю... Как по мне - очень действенный костыль получился)))