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

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

 

Доброй ночи.

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

 

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

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

 

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

 

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

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

 

Здраствуйте.
В принице я особо ничего не менял в прошивках в плане расчета времени.
Хаотично - это можна как то по подробнее.

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

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

 

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

 

Очень странно

Код (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

 

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

 

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

 

временно поставил период обновления 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); не работает

 

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

 

Код (C++):

udp.beginPacket(timeServerIP, 123);                    
    udp.write(packetBuffer, NTP_PACKET_SIZE);
    udp.endPacket();
    delay(800);                                            
    cb = udp.parsePacket();

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

 

Ничего сложного нет.
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

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

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

 

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

 

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

 

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

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

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

проблема связана с нарушением атомарного доступа к глобальным переменным времени hour, minute, second... и переменным даты (во всяком случае в 4 версиях точно, за последние ничего утверждать не берусь)
даже логи старые остались на компе
Иван думаю догадается, что за воскличательные знаки в логе и почему в итоге такое странное время

Спойлер: log

Код (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 -> !

 

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

Здесь я так понимаю ситуация особенная, надо пробовать разные варианты, хотя бы методом исключения. Я привык искать проблему создавая маркеры вывода в ком порт... так понимаю где затык.

Я делал три запроса подряд именно с той целью что бы при плохом интернете имемть больше шансов не "сломать" текущее время)))

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

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

 

Иван, эту "особенную" ситуацию в своем сообщении жирным выделил

время "ломает" глюк, а не отсутствие совсем необязательных дополнительных запросов.
три запроса возможно этот глюк замаскируют, но не всегда, опять же, как карта ляжет.
а вот устранив причину отпадет необходимость в этом костыле, в виде многократных запросов, сравнений и бестолковых задержек по 800мс.

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

 

Как минимум это изменит код, немного сократится процессорное время на лишнюю распаковку данных. И вполне возможно что во время вывода бегущей строки уберет возможное подтормаживание.

Конечно можно из пакета получить разрешенный сервером период запросов, рассчитать RTT и сформировать свою паузу между подачей запросов. Но я прошу прощения, мы же не строим эталонные часы синхронные с атомными. Вот именно по этому выбрано время в 800мс, с головой достаточное что бы сервер нас не "послал".
Как бы там ни было я убрал эту задержку и из логов видно что мой сервер меня посылает акурат на третьем запросе. По этому сделал паузу в 64мс после запроса, и если был "послан" то тогда 800мс.

Ну это уже проблемы вашего кода, если он не может корректно разложить 4 байта временной метки. Я отправляю 3 запроса и если полученного времени больше чем на пару секунд, то я не обновляю локальное время и в часовом модуле тоже его не обновляю. А вот если все три метки времени очень близки (с учетом особенностей доставки UDP пакетов) то я принимаю поледнее полученное время как истенное, и только тогда обновляю время локальное и в часовом модуле.

4 байта = 32 бита. Если глюк попал в младший бит, то это секунды, а если глюк попал в более старший бит, то это могут быть минуты, часы, года.... Как думает какова вероятность того что глюк три раза попадет в тот же бит? Вот и я думаю что вероятность поймать ошибку стремится к нулю... Как по мне - очень действенный костыль получился)))