Zegar LED na sterowniku MAX7219 oraz ESP8266

[MisiekD]

1 minutę temu, ethanak napisał:

A jaki sens ma tworzenie czegokolwiek, jak gotowego rozwiązania nikt nie przyniósł na tacy?

Ja np. wewnętrznie trzymam czas w UTC, a dopiero przy przeliczaniu na tm uwzględniam offset zależnie od daty. Pewnie istnieją gotowe rozwiązania, ale nie chce mi się szukać...

 

 

Inaczej - projekt jest świetny, tylko ten czas dla naszej strefy nie wzięty pod uwagę.

A ten polski adres NTP nie uwzględni przesunięcia? Bo jeśli tak to to załatwia wszystko.

[Belferek]

2 minuty temu, ethanak napisał:

Pewnie istnieją gotowe rozwiązania, ale nie chce mi się szukać...

Ten krótki artykuł pokazuje, że problem aktualizacji czasu z sieci z uwzględnieniem czasu letniego / zimowego można zamknąć w kilku linijkach - zobacz.

[ethanak]

5 minut temu, MisiekD napisał:

A ten polski adres NTP nie uwzględni przesunięcia

Serwery podają czas w UTC, a ten jest taki sam w Londynie, Polsce i Pernambuco.

[ethanak]

9 minut temu, Belferek napisał:

Ten krótki artykuł pokazuje

A, tak... artykuł mówi:

NTP is part of the Arduino core for the ESP8266 since 2019.

Ja swój zegarek robiłem wcześniej.

[Miglandz]

podpowiem:

#include <time.h>

configTime(0, 0, "x.x.x.x");

setenv("TZ", "CET-1CEST-2,M3.5.0/02:00:00,M10.5.0/03:00:00", 1);

tzset();

[Belferek]

2 minuty temu, ethanak napisał:

Ja swój zegarek robiłem wcześniej.

Tak jak i ja, ale dziś temat wrócił. Opisana we wspomnianym artykule metoda jest rewelacyjna - działa super.

[ethanak]

21 minut temu, Belferek napisał:

metoda jest rewelacyjna

Nie przeczę

W ogóle te fajne biblioteki oszczędzają zabawy z komunikacją UDP z serwerem NTP... ale dzięki temu że wtedy ich nie było potrafię sprawdzić godzinę bez bibliotek

 

[Belferek]

3 godziny temu, ethanak napisał:

W ogóle te fajne biblioteki oszczędzają zabawy z komunikacją UDP z serwerem NTP

O jakich bibliotekach mówisz? Podany artykuł korzysta jedynie z ESP8266Wifi.h i time.h

[ethanak]

Przeczytaj pierwsze zdanie artykułu.

A ta sama biblioteka w 2018 i 2022 może mieć nieco inną zawartość...

A tak w ogóle costam.h to nie jest biblioteka, prawda?

[MisiekD]

8 godzin temu, Belferek napisał:

Tak jak i ja, ale dziś temat wrócił. Opisana we wspomnianym artykule metoda jest rewelacyjna - działa super.

I z tą metodą czas zmienia się idealnie w czasie zmian czasu? Nie ukrywam, że czegoś takiego również poszukuję, lecz, żeby to sprawdzić musiałbym czekać z pół roku  

[ethanak]

Czas się nie zmienia - to tylko funkcja odpowiadająca za przeliczenie z UTC do czasu lokalnego przelicza go zgodnie z timezone.

[Belferek]

34 minuty temu, MisiekD napisał:

I z tą metodą czas zmienia się idealnie w czasie zmian czasu?

Oczywiście, że tak! Sam możesz poeksperymentować z linią:

#define MY_TZ "CET-1CEST,M3.5.0/02,M10.5.0/03"

To tu jest zdefiniowane kiedy ma następować zmiana czasu:

M3, M10 - marzec, październik
5 - ostatni tydzień miesiąca
0 - niedziela
/02 /03 - godzina

Przecież możesz zamienić dla eksperymentu czas zmiany na czas zimowy czyli np.  M10.5.0/03 na M11.3.1/21 co powinno spowodować "przejściem na czas zimowy" dziś (14.11.2022, poniedziałek) o godz. 21:00 :-).

Skopiuj sobie podany w artykule kod i uruchom to sam zobaczysz.

Warto poczytać ten artykuł, który wyjaśnia co te symbole znaczą.

Po eksperymentach wróć do właściwych ustawień.

[ethanak]

20 minut temu, Belferek napisał:

Oczywiście, że tak!

To sprawdź co będzie w now.

[Belferek]

2 godziny temu, ethanak napisał:

To sprawdź co będzie w now.

No chyba mój błąd - źle określiłem numer tygodnia. No ale pisałem o eksperymentach :-). W każdym bądź razie wpis:

#define MY_TZ "CET-1CEST,M3.5.0/02,M11.2.1/23:40:0"

Powoduje, że "zegarek startuje z czasem letnim", a o 23:40 (14.11.2022) "przechodzi na czas zimowy".

Z takim ustawieniem program uruchomiłem o 22:34 (według czasu PC) i w serialu widzę:
 

Brak polaczenia z WiFi:
1970-01-01    01:00:10    wday 4    czas zimowy

Polaczenie z serwerem NTP!
WiFi OK:192.168.0.18
2022-11-14    23:34:26    wday 1    czas letni (DST)

Jest ok, gdyż zgodnie z moim błędnym ustawieniem końca czasu letniego mam dodaną godzinę do czasu pobranego przez NTP.
Przychodzi odpowiednie pora i:

WiFi OK:192.168.0.18
2022-11-14	23:39:59	wday 1	czas letni (DST)
WiFi OK:192.168.0.18
2022-11-14	22:40:00	wday 1	czas zimowy
WiFi OK:192.168.0.18
2022-11-14	22:40:01	wday 1	czas zimowy

Jak widać nastąpiła zmiana czasu. Tak więc mechanizm działa.  To było ustawienie "eksperymentalne". Prawidłowe dla naszej strefy czasowej to oczywiście:

#define MY_TZ "CET-1CEST,M3.5.0/02,M10.5.0/03"

Pytanie tylko dlaczego 14.11.2022 jest w 2, a nie w 3 tygodniem miesiąca?

Edytowano Listopad 14, 2022 przez Belferek

[MisiekD]

10 godzin temu, Belferek napisał:

Prawidłowe dla naszej strefy czasowej to oczywiście:

#define MY_TZ "CET-1CEST,M3.5.0/02,M10.5.0/03"

Rewelka! To powinno być gdzieś podpięte, bo na pewno nie jednemu się przyda