Arduino MEGA i BLYNK, LCD odchodzi do lamusa...

[ethanak]

Może być, nawet lepiej niż w mojej wersji (ciekawe czy zauważysz o czym zapomniałem).

[SOYER]

jeszcze jedno, czyli NULL==false, tak?

7 minut temu, ethanak napisał:

ciekawe czy zauważysz o czym zapomniałem

nie wiem...

czy nie powinno być jeszcze dodane $polaczenie->close()...??

[ethanak]

9 minut temu, SOYER napisał:

jeszcze jedno, czyli NULL==false, tak?

A tak, owszem - co łatwo sprawdzić:

ethanak@moiraine:~/src/soyer$ cat pp.php
<?php
echo (null == False) . "\n";
?>
ethanak@moiraine:~/src/soyer$ php pp.php
1

 

10 minut temu, SOYER napisał:

czy nie powinno być jeszcze dodane $polaczenie->close()...??

Powinno, ale można to pominąć, praktycznie po odczytaniu danych z bazy nic już nie robimy - możemy więc polegać na wbudowanym mechanizmie automatycznego zwalniania zasobów. Moim błędem było zwolnienie rezultatu ($odczyt) jedynie w przypadku, kiedy istniał wynik.

Co ciekawsze - starsze podręczniki PHP wręcz zalecały pozostawianie zwalniania zasobów systemowi - pewnie ze względu na wspaniały i optymalny kod interpretera. Możesz sobie wyobrazić jęki i płacze klientów, którzy koniecznie potrzebowali jakichś potwornych megabajtów pamięci tylko dlatego, że w skryptach nie zwalniano zasobów, a serwery nie z gumy 🙂

 

[SOYER]

z jakiegoś powodu ten poprawiony kod z if nie działa: nie wyświetla wartości...

 

 

a już ok, zapodział się jakiś zbędny nawias }, wywaliłem i ok. Działa.

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[ethanak]

No i dobrze. To co z tą tabelą?

[SOYER]

Teraz idę na imprezę, będę wieczorem. 

Telefon zabieram, ale kompa nie;) 

[SOYER]

@ethanak 

5 godzin temu, ethanak napisał:

No i dobrze. To co z tą tabelą?

No właśnie, co z nią nie tak?

6 godzin temu, ethanak napisał:

Moim błędem było zwolnienie rezultatu ($odczyt) jedynie w przypadku, kiedy istniał wynik.

co w ogóle robi to $odczyt->close(), bo przy $polaczenie->close(), wiadomo zamyka połączenie z bazą... ale zamykanie zmiennej odczyt? Znaczy, że zwalniamy pamięć ktorą ta zmienna wykorzystywała?

Edytowano Styczeń 27, 2019 przez SOYER

[ethanak]

1 godzinę temu, SOYER napisał:

Znaczy, że zwalniamy pamięć ktorą ta zmienna wykorzystywała?

Dokładnie tak.

Co do "co z tabelą"...

Nie wiem dlaczego uważasz, że tabela w bazie danych to takie coś jak tabelka w Excelu, gdzie każda komóreczka ma swoje współrzędne. Nie tędy droga.

Nie wiem skąd pomysł użycia typu int wszędzie gdzie się da. Czy na pewno wyniki są liczbą całkowitą? Co z datami - np. co oznacza zero w kolumnie min_date? I dlaczego wstawiasz jakieś liczby, które MySQL wyliczy sobie sprawniej niz Ty?

Wyobraź sobie tabelę:

create table meteo (
    id bigint auto_increment not null unique,
    czujnik varchar(16) not null,
    aktualna decimal(8.2) not null,
    czas datetime not null default current_timestamp
    )

Oprócz id (identyfikującego konkretny rekord) masz tylko najważniejsze pola, a funkcja która wrzuca dane do bazy zajmuje się tylko kolumnami "czujnik" i "aktualna". Owszem - zapytanie w skrypcie pobierającym dane do strony musi być lekko zmienione, coś w stylu:

select aktualna from meteo where czujnik = '$typ' order by czas desc limit 1;

W ten sposób zachowujesz wszystkie dane i możesz zawsze sprawdzić, jakie były wskazania czujnika w zeszły piątek wieczorem.

Czy rozumiesz o co chodzi?

[SOYER]

10 minut temu, ethanak napisał:

Nie wiem skąd pomysł użycia typu int wszędzie gdzie się da. Czy na pewno wyniki są liczbą całkowitą? Co z datami - np. co oznacza zero w kolumnie min_date? I dlaczego wstawiasz jakieś liczby, które MySQL wyliczy sobie sprawniej niz Ty. 

 

Tym się nie sugeruj. Jak już pisałem, jest to moja pierwsza tabelka zrobionatylko po to by była i było na czym ćwiczyć... Wiem, że dla każdej "szufladki" można ustawić sto różnych parametrów, typy danych, utf..... Nie zajmowałem się tym, tylko wpisałem te pięć by mieć na czym ćwiczyć łączenie z bazą. 

 

16 minut temu, ethanak napisał:

desc limit 1;

what's that mean...? 

no właśnie nie wiem jak to zrobić by zapisywać te wszystkie historyczne dane potrzebne do wykresów. 

Ogromna “tabelka"? 

[Treker (Damian Szymański)]

35 minut temu, SOYER napisał:

what's that mean...? 

Oznacza to, że pobierasz tabelę posortowaną malejąco i chcesz zobaczyć tylko jeden, pierwszy wynik (nawet jeśli w tabeli jest miliard wpisów). Lepiej zajrzyj do jakiegoś kursu MySQL bo to podstawy. Zaraz dostaniesz tu słuszny wycisk od @ethanak.

35 minut temu, SOYER napisał:

no właśnie nie wiem jak to zrobić by zapisywać te wszystkie historyczne dane potrzebne do wykresów. 

Ogromna “tabelka"? 

Zależy, o którym wymiarze tabeli piszesz 😉 Nie ma być "szeroka" tylko ma być długa. Czyli po prostu każdy pomiar będzie nowym wpisem do tej tabeli w stylu "ID, DATA, WARTOŚĆ" (przykład niezwiązany z Waszymi kodami, bo nie śledzę tak dokładnie tematu). Praktycznie o to głównie chodzi w MySQL. Większość zastosowań są to jakieś tabele, w których jest ogrom wpisów. Posty na forum to też jedna tabela, w której jest ponad 120 tysięcy wpisów.

[SOYER]

już doczytałem;)... podstawy kwerend... 

Najlepiej jakby było: wynik ostatni, a za poprzednie dni uśredniona wartość z całej doby, dodatkowo max i min wartość z każdego dnia, plus uśrednienia dla każdego miesiąca osobno... 

Tylko nie wiem co z tego w tabeli a co z wyliczeń, chodzi mi o to czy jest sens trzymać poszczególne pomiary co iluś minutowe, za ileś tam wstecz. Czy też po północy wyciągamy średnie za ostatnią dobę i zapisujemy. 

Jak się robi takie bazy? 

[Treker (Damian Szymański)]

3 minuty temu, SOYER napisał:

Tylko nie wiem co z tego w tabeli a co z wyliczeń, chodzi mi o to czy jest sens trzymać poszczególne pomiary co iluś minutowe, za ileś tam wstecz. Czy też po północy wyciągamy średnie za ostatnią dobę i zapisujemy. 

Pierwsza wersja łatwiejsza i pewnie większość systemów tak działa, bo nikomu nie chce się robić mechanizmu, który będzie o północy zapisywał średnią i kasował resztę 😉

[ethanak]

7 godzin temu, SOYER napisał:

Najlepiej jakby było: wynik ostatni, a za poprzednie dni uśredniona wartość z całej doby, dodatkowo max i min wartość z każdego dnia, plus uśrednienia dla każdego miesiąca osobno... 

Do tego właśnie służą bazy danych i wbudowane w nie funkcje statystyczne - wyciąganie wartości minimalnych/maksymalnych,  średnie, odchylenia, mediany i co tam cobie jeszcze wymyślisz.

7 godzin temu, SOYER napisał:

czy jest sens trzymać poszczególne pomiary co iluś minutowe, za ileś tam wstecz.

A co ile minut wrzucasz dane do bazy? Nie wiem jak jest w Twoim przypadku, a od tego zależy jak to zrobić...

7 godzin temu, SOYER napisał:

Jak się robi takie bazy? 

Najpierw się wie co się wrzuca i ile mniej więcej tego będzie - potem w zależności od tego projektuje się resztę. Ale głównym elementem będzie zawsze tabela podobna do tej, którą zaproponowałem.

 

[SOYER]

Co minutę, 13 wartości... 

[ethanak]

Coś mi się nie wydaje że to prawda - o ile mnie pamięć nie myli, to czas pomiaru PM jest dłuższy niż minuta... ale niech Ci będzie.

Załóżmy, że będziemy w aplikacji trzymać dane z ostatniego roku (jakieś ograniczenie czasowe musimy sobie założyć).

Gdyby tabela wyglądała tak prosto (jeden rekord - jedna wartość) potrzeba by było 365 * 13 * 1440 = 6832800 rekordów. Na normalnym dysku baza z 6 milionami rekordów nie byłaby jeszcze największa (choć już i tak trzeba by było zastosować parę dodatkowych mechanizmów po to, aby działało to z jako-tako akceptowalną prędkością). Na nośniku który mamy do dyspozycji dane z selecta dostalibyśmy pewnie następnego dnia...

Spróbujmy inaczej.

Zamiast rozbijać dane na rekordy dla poszczególnych wartości, zróbmy rozbicie wyłącznie na czas. Niech poszczególne czujniki będą kolumnami tabeli, czyli coś w stylu:
 

create table meteo2(
	czas datetime primary key default current_timestamp,
	temp_zewn int not null,
	temp_kuchnia int not null,
...
	);

Tracimy przez to pewną elastyczność (bo dołożenie nowego czujnika wymaga teraz zmiany w tabeli), ale za to o rząd wielkości zmniejszyliśmy ilość rekordów - mamy teraz 365 * 1440 = 525600.

Dla normalnego talerzowego dysku to już fraszka - pół miliona rekordów jeszcze ładnie poindeksowanych (klauzula primary key w deklaracji kolumny "czas" powoduje założenie indeksu i dobrego kopa dla szybkości) to taka normalna, spora ale nie bardzo duża baza. Teoretycznie można by tak to zostawić, ale zastanówmy się: czy jest konieczne zapisywanie do bazy co minutę? Ja loguję temperaturę w trzech pomieszczeniach w mieszkaniu co minutę - ale tylko na 24 godziny, w dodatku w pliku w ramdysku, a potrzebne mi to było do obliczenia parametrów pieca CO (szybkość nagrzewania mieszkania) aby określić moment wyprzedzenia włączenia pieca dla uzyskania określonej temperatury o określonej godzinie. Gdybym chciał logować to do jakiejś bazy danych - spokojnie zapisywałbym dane co 10 minut, a co najwyżej aplikacja odbierająca dane z czujników obrabiałaby porcję 10 wyników (np. wyliczała medianę albo jaką inną ciekawszą średnią) i dopiero te przetworzone dane trafiałyby do tabeli w bazie.

Tak więc do zapisu danych z roku potrzebowalibyśmy jedynie 365 * 144 = 52560 rekordów, co nawet dla tak wolnego nośnika jakim jest karta SD nie powinno stanowić problemu.

Pytałeś o możliwość stworzenia jakiegoś programu, który "po północy" przeliczałby dane z ostatniego dnia. Owszem, istnieje możliwość stworzenia takiego programu - ale nie na takim etapie nauki na jakim jesteś dzisiaj. Powiedzmy, że za jakiś miesiąc - dwa mógłbyś się spróbować z tym zmierzyć (a tymczasem dane leciałyby sobie w kosmos?). Możesz więc zrobić inaczej: wybrać na dziś wpisywanie wartości co minutę (niech sobie lądują w bazie, będzie co liczyć) i liczyć na to że w ciągu miesiąca będziesz w stanie napisać aplikację kompaktującą dane. Tyle, że ja bym raczej nie ryzykował i wybrał dziesięciominutowy okres zapisu danych.

Co wybierzesz?