Pomożesz w trenowaniu sztucznej inteligencji ?

[LukiSpajder]

No ale to wychodzi że zostało to właśnie do tego stworzone , aby uzyskać taki stan w supli jak na liczniku . Czy to zaczytywane impulsowo czy przez zdjęcie . Po wymianie licznika musisz i tak skorygować to aby pojawiał ci się stan zgodny z tym co na liczniku .
Jedynie przy zaczytywaniu impulsowym będzie kontynuacja, a tu po zrobieniu zdjęcia wrzuci od razu nową wartość . Może dodać opcję usuń ostatnie zdjęcie i zużycie które się pojawiło .
To może zmienić „ wartość dodaną” na „aktualny stan licznika” i może to rozwiąże problem pytań co tam wpisać . W info dać co to oznacza .

Luźna propozycja

Jednak wartość odczytywana porównywana jest z ostatnim zdjęcie i to potem trafia do historii pomiarów - tak więc korekta w cloud nic nie daje tylko wizualnie mamy wartość zgadzającą się w supli i na liczniku

[klew]

No ale to wychodzi że zostało to właśnie do tego stworzone , aby uzyskać taki stan w supli jak na liczniku . Czy to zaczytywane impulsowo czy przez zdjęcie . Po wymianie licznika musisz i tak skorygować to aby pojawiał ci się stan zgodny z tym co na liczniku .

No tak. ale obecnie dyskutujemy tu propozycję tego, aby nie używać tego w celu uzyskania zgodnych stanów licznika, tylko aby skorygować pomiar zwiększony o 250 m3 z powodu wymiany licznika. Dodanie takie ujemnej warotści spowoduje, że ta "zgodność stanów" zniknie. Także to co napisałeś, potwierdza moją wcześniejszą wątpliwość

Jedynie przy zaczytywaniu impulsowym będzie kontynuacja, a tu po zrobieniu zdjęcia wrzuci od razu nową wartość . Może dodać opcję usuń ostatnie zdjęcie i zużycie które się pojawiło .

To nie jest kwestia zdjęć, tylko stanu licznika (nieważne, czy impulsowo, czy bezpośrednio wartościami). Ogólnie w historii jest zapisywany ciąg stanów licznika. A zużycie jest liczone od przyrostów.
Np. mamy zapisane stany: 0, 1, 2, 2, 3, 5, 200, 202
Z tego Cloud i apki liczą przyrosty: 1, 1, 0, 1, 2, 195, 2
Zużycie i wykresy są robione na podstawie przyrostów.

Usunięcie "200" tutaj nic nie zmieni, bo kolejny pomiar to 202 i znowu pojawi się przyrost 197.
Trzeba by jakoś w bazie oznaczać, że to nie jest kolejny pomiar, tylko nowy punkt startowy.
No i nadal mamy problem z danymi historycznymi, bo Supla zapisuje sobie stan do bazy co 10 min i każdy normalny user zorientuje się o problemie dopiero jakiś czas po jego zaistnieniu. Więc trzeba by pokazać w postaci tabeli dane historyczne, aby user mógł wybrać i oznaczyć ręcznie pierwszy wpis z wartością z nowego licznika. No i dalej cloud i apki muszą się o tym dowiedzieć i przeliczyć na nowo przyrosty itd.

To może zmienić „ wartość dodaną” na „aktualny stan licznika” i może to rozwiąże problem pytań co tam wpisać . W info dać co to oznacza .

To może być jeszcze bardziej problematyczne. Bo dzisiaj jest "aktualny" 250 i tyle wpisujemy, a wracamy tu tydzień później i 250 nie jest już aktualne .

Pole z "aktualnym stanem" nadal nam nie pomoga, bo my potrzebujemy albo oznaczyć miejsce wymiany licznika, albo do wartości zapisywanych w bazie, ustawić jakiś ujemny offset, aby dane pokrywały się z ostatnim stanem starego licznika. TO SIĘ NIE UDA, bo jest zbyt skomplikowane.

Tak czy siak, na chwilę obecną pozostaje kasowanie historii w takiej sytuacji. Tabula rasa raz na 5 lat wszytkim dobrze zrobi

[LukiSpajder]

Rozumiem , i się nie upieram przy tym rozwiązaniu .
Może część użytkowników nie dotyczyć ten problem np. Tak jak mnie licznik wody mam zamontowany w studzience przed domem ( takie wymogi wodociągów ) a drugi swój licznik w domu tylko pod suple nie będę go wymienia puki się nie zatrzyma

[Patryk]

Nie wiem, czy to wykonalne.
A jakby "Usuń całą historię" była by jeszcze opcja "Usuń historię z", gdzie podaje się datę, godzinę, minuty.
Wtedy rozwiązało, by to (ogólnie) problem "pików" na wykresach, które zdarzają się na urządzeniach DIY.

[klew]

Nie wiem, czy to wykonalne.
A jakby "Usuń całą historię" była by jeszcze opcja "Usuń historię z", gdzie podaje się datę, godzinę, minuty.
Wtedy rozwiązało, by to (ogólnie) problem "pików" na wykresach, które zdarzają się na urządzeniach DIY.

Tak, ale to nadal nie ma żadnego wpływu na Twój problematyczny licznik, gdzie z 50 robi się 250 m3

Takża opcja usuwania od-do byłaby przydatna i Przemek miałby mniej roboty w ręcznych edycjach bazy.

[YoMan]

Nie mówię że nie. Tylko że nie mam pomysłu jak to tego sensownie podejść

Button w cloud "Wymiana licznika" -> wpisz wartość startową "nowego licznika" ?

To spoko, tylko jak to od strony technicznej zrobić?

To ty jesteś tutaj od rzeczy niemożliwych Ja tylko wujek "dobra rada"
Ale faktycznie pojawił się w sumie dobry pomysł aczkolwiek chyba dość skomplikowany do realizacji skorygowania własnoręcznie danego zapisu i połączyć to z opcją korekty. Czyli po wymianie korygujemy właściwe wskazanie licznika i potem korygujemy peak. W HA można tak naprawiać statsy. Obawiam się jednak, że z tego może wyjść więcej złego niż dobrego.
Może jakiś automat, który przy nienaturalnie dużej zmianie pomiędzy odczytami wymusi akcję potwierdzenia, a do tego czasu zapis w tymczasowej bazie pomocniczej? Po wpisaniu licznika wstecznie skoryguje do momentu tej zmiany? Tez nie będzie proste do zrobienia.

[Yepestis]

Trzeba by wprowadzić pojęcie "urządzeń" i realizowac ich wymiany na "punkcie pomiarowym" że wskazaniem daty i godziny od i do czasu obowiązywania. Wtedy wartość dodana była by per urządzenia a nie per punkt. Historia była by dla urządzenia i wyświetlana dla punktu z uwzględnieniem momentów wymiany urządzenia.

[klew]

Trzeba by wprowadzić pojęcie "urządzeń" i realizowac ich wymiany na "punkcie pomiarowym" że wskazaniem daty i godziny od i do czasu obowiązywania. Wtedy wartość dodana była by per urządzenia a nie per punkt. Historia była by dla urządzenia i wyświetlana dla punktu z uwzględnieniem momentów wymiany urządzenia.

Wartość dodana tutaj nie ma znaczenia i zastosowania.

Reszta się zgadza. "wymiana urządzenia" mogłaby służyć jako znacznik wspomnianiej wcześniej "wymiany licznika". Ale to nadal finalnie sprowadza się do rozwiązania podobnego do tych, co omówiliśmy wcześniej, a dodatkowo nakłada dość duże ryzyko związane z przebudową modeli i migracji ogromnej ilości danych na nowy format (mówimy tu o wszystkich licznikach impulsów i w zasadzie do liczników energii też to ma zastosowanie - po uwzględnieniu tej wartości dodanej).

Wymagane nakłady pracy: spore
Potencjalne ryzyko zepsucia czegoś: spore
Zysk: niewielki



Podejrzewam, że prawie każdy bez trudu wymieni 5 innych funkcjonalności, na których mu bardziej zależy.

[Duch__]

Dodajcie możliwość powiadomień o przekroczeniu zużycia wody godzinowym i dobowym. Muszę żonie ukrucić myju myju

[klew]

Dodajcie możliwość powiadomień o przekroczeniu zużycia wody godzinowym i dobowym. Muszę żonie ukrucić myju myju

To było pytanie retoryczne. Proszę nie wymieniać 5 rzeczy na których Wam bardziej zależy