Historia termostatu

[Lector]

Albo wirtualny GPM(KPOP) i przy 9 termostatach robimy tak:

termostat nr 1 ON -> GPM dostaje wartość 11, OFF wartość 10,
termostat nr 2 ON -> GPM dostaje wartość 21, OFF wartość 20,
...
termostat nr 9 ON -> GPM dostaje wartość 91, OFF wartość 90

wtedy historia z jednego GPM pozwoli nam ogarnąć zdarzenia z większej liczby termostatów.

Pomysł OK, też mi to przyszło do głowy, ale ja bym to zrobił prościej. Kolega chce tylko wiedzieć kiedy piec grzeje. Twój sposób daje mu dodatkowe info z jakiego termostatu. No i to jest słuszna koncepcja , natomiast dla informacji o samym piecu wystarczy 0/1. 1 - grzeje, 0 - nie grzeje. I tak dla każdego termostatu. Wtedy na wykresie mamy bardzo ładnie widoczne godziny włączenia i wyłączenia pieca/grzania.

Edit: dobra, doczytałem pierwszy post. Kolega chce analizować system, no to pomysł z wartościami dla każdego termostatu zrzucane na GPM jest lepszy.
Swoją drogą, czy ten komunikat przy włączaniu historii dla GPM też się pojawia? Chodzi mi o ten, który informuje, że to zabiera miejsce na serwerach i jak nie musimy, to mamy sobie darować?

Komunikat o oszczędzaniu miejsca pojawia się, stąd mój pomysł z tymi wartościami - bo tak będzie zapisywana jedna historia a nie np. 9 - szkoda miejsca na serwerze.

A co będzie jak będą chodzić dwa, cztery termostaty - pokaże ostatnio załączony.
To samo z wyłączaniem grzania przez termostaty, albo ustawi się 0 od razu albo po ostatnim wyłączonym.

[vajera]

Pomysł OK, też mi to przyszło do głowy, ale ja bym to zrobił prościej. Kolega chce tylko wiedzieć kiedy piec grzeje. Twój sposób daje mu dodatkowe info z jakiego termostatu. No i to jest słuszna koncepcja , natomiast dla informacji o samym piecu wystarczy 0/1. 1 - grzeje, 0 - nie grzeje. I tak dla każdego termostatu. Wtedy na wykresie mamy bardzo ładnie widoczne godziny włączenia i wyłączenia pieca/grzania.

Edit: dobra, doczytałem pierwszy post. Kolega chce analizować system, no to pomysł z wartościami dla każdego termostatu zrzucane na GPM jest lepszy.
Swoją drogą, czy ten komunikat przy włączaniu historii dla GPM też się pojawia? Chodzi mi o ten, który informuje, że to zabiera miejsce na serwerach i jak nie musimy, to mamy sobie darować?

Komunikat o oszczędzaniu miejsca pojawia się, stąd mój pomysł z tymi wartościami - bo tak będzie zapisywana jedna historia a nie np. 9 - szkoda miejsca na serwerze.

A co będzie jak będą chodzić dwa, cztery termostaty - pokaże ostatnio załączony.
To samo z wyłączaniem grzania przez termostaty, albo ustawi się 0 od razu albo po ostatnim wyłączonym.

Nie - włączony termostat nr 1, 6 i 9 - wartość 163, po chwili wartość spada do 102, to znaczy że termostat nr 6 wyłączył się, po kolejnej chwili przyjmuje wartość 112, tzn. że nr 1 wyłączył się a włączył się nr 2.

Oczywiście, w przypadku liczby termostatów > 10, można stosować wartości 101/100, 201/200...- wtedy jest miejsce na 99 termostatów

[klew]

W takim wariancie nie ma info o % grzania (patrzaj głowice).

Wg mnie warto dodać taką historię do Supli "natywnie". No i zapisywać tylko zmiany - to zajmie dużo mniej miejsca niż taki log z GPM, gdzie zapis jest co 10 min.

[vajera]

W takim wariancie nie ma info o % grzania (patrzaj głowice).

Wg mnie warto dodać taką historię do Supli "natywnie". No i zapisywać tylko zmiany - to zajmie dużo mniej miejsca niż taki log z GPM, gdzie zapis jest co 10 min.

Masz rację - natywna historia jest najlepsza i zajmie najmniej miejsca.
To co zaproponowałem, to proteza na teraz

% głowicy - to już większe wyzwanie - mamy wartości 0 - 100, czyli potrzebujemy minimum 7 bitów, GPM na 8 bajtów, więc albo 8 termostatów i wtedy bajt/termostat, albo wersja poznańska 9 termostatów (7 bitów).

Te 10 minut jest na serwerze "na sztywno", czy można to zmienić w DIY?

[klew]

% głowicy - to już większe wyzwanie - mamy wartości 0 - 100, czyli potrzebujemy minimum 7 bitów, GPM na 8 bajtów, więc albo 8 termostatów i wtedy bajt/termostat, albo wersja poznańska 9 termostatów (7 bitów).

GPM jest na double, więc ostrożnie z kodowaniem czegoś na liczbach

Te 10 minut jest na serwerze "na sztywno", czy można to zmienić w DIY?

Tak działa serwer i tego oczekują Cloud i apki, choć pewniej jakby ktoś na swoim serwerze to przestawił na inną warość, to by ruszyło, ale nie testowaliśmy czy nic nie wybuchnie.
Urządzenia nie mają na to żadnego wpływu.

[vajera]

% głowicy - to już większe wyzwanie - mamy wartości 0 - 100, czyli potrzebujemy minimum 7 bitów, GPM na 8 bajtów, więc albo 8 termostatów i wtedy bajt/termostat, albo wersja poznańska 9 termostatów (7 bitów).

GPM jest na double, więc ostrożnie z kodowaniem czegoś na liczbach

Coś takiego powinno być bezpieczne:

Code: Select all

union {

double gpm_value_double;
uint8_t thermostat_1;
....
uint8_t thermostat_8;
};

albo nawet w wersji poznańskiej

Code: Select all

union {

double gpm_value_double;
uint64_t thermostat_1 : 7;
uint64_t thermostat_2 : 7;
....
uint64_t thermostat_9 : 7;
uint64_t przydas : 1; // ;)
};

[klew]

Ale to zostanie przez serwer odczytane jako double i zapisane w historii w formie: min, max, avg na każde 10 min.

[vajera]

Ale to zostanie przez serwer odczytane jako double i zapisane w historii w formie: min, max, avg na każde 10 min.

OK, czyli serwer nie zapisuje wartości raw - tego nie byłem świadomy.