Cześć,
co może być przyczyną, że przestała mi działać historia licznika w aplikacji? Przez 2 miesiące wszystko było OK, 3 dni temu jedyne co zrobiłem to "ręcznie" w urządzeniu poprawiłem odczyt na zgodny z fizycznym licznikiem. Od tego momentu nie odświeża mi historii, nie da się też zmienić zakresu (niezależnie od tego co wybiorę z listy rozwijalnej). W cloudzie historia jest i działa.
Serwer własny - v.25.07, urządzenie i aplikacja Android - aktualne wersje.
Usuwałem już historię w cloudzie (mogłem sobie na to pozwolić), usunąłem i zarejestrowałem na nowo urządzenie - nic nie pomogło.
Licznik impulsów - brak historii w aplikacji: "Odświeżanie nie powiodło się"
-
klew
- Posts: 13907
- Joined: Thu Jun 27, 2019 12:16 pm
- Location: Wrocław
- Has thanked: 134 times
- Been thanked: 137 times
Jeśli usunęłaś historię w cloud, to ona przepadła. Chyba że masz gdzieś backup zrobiony i sobie odtworzysz.
Masz inne kanały z historią, aby sprawdzić czy na nich działa?
Masz inne kanały z historią, aby sprawdzić czy na nich działa?
Najlepsze suple dla Twojego domu 
-
bob_
- Posts: 61
- Joined: Mon Sep 28, 2020 5:49 am
Dzięki klew za chęć pomocy.
Nie chodzi o to, że usunąłem sobie przypadkowo historię, zrobiłem to w ramach próby przywrócenia funkcjonalności apki na androidzie. I czy przed, czy to po usunięciu (kiedy to w cloudzie już widzę "nową" historię budującą się od momentu usunięcia") aplikacja nie chce pokazać nic (błąd odświeżania) , a w karcie OGÓLNE zużycie bieżącego miesiąca jest zerowe.
Czyli jeszcze raz - hstoria pomiaru w cloudzie jest i się buduje, a aplikacja nie chce tego odczytać pomimo ze jeszcze kilka dni temu robiła to bez problemu.
Logi serwera, bazy i clouda nie pokazują nic nietypowego.
EDIT: Okazuje się, że tak samo zachowuje się licznik energii. Problem leży chyba zatem na styku aplikacja - serwer. Tylko gdzie szukać?
EDIT2: Przeinstalowałem aplikację, wyczyściłem jej pamięć (telefon z Androidem) i zauważyłem dodatkowo, że nie pobiera mi ikon. O co tu chodzi? Aplikacje działa normalnie, steruje urządzeniami, a nie ma możliwości pobrania historii pomiarów z dowolnego licznika lub czujnika temperatury i nie pobiera ikon. Cloud telefon widzi (przyznany dostęp i staje się aktywny kiedy używam aplikacji).
ROZWIĄZANIE:
Metoda na windowsa pomogła - ./supla.sh upgrade. Po reinstalacji wszystko działa. Nie rozumiem tego (może się coś sypie na dockerowych instalacjach, bo to już drugi czy trzeci raz u mnie, gdy na dziwaczne problemy bez wyraźnej przyczyny pomaga reinstalacja). Trochę teraz żałuję, że po drodze usunąłem sobie historię, ale do przeżycia.
Nie chodzi o to, że usunąłem sobie przypadkowo historię, zrobiłem to w ramach próby przywrócenia funkcjonalności apki na androidzie. I czy przed, czy to po usunięciu (kiedy to w cloudzie już widzę "nową" historię budującą się od momentu usunięcia") aplikacja nie chce pokazać nic (błąd odświeżania) , a w karcie OGÓLNE zużycie bieżącego miesiąca jest zerowe.
Czyli jeszcze raz - hstoria pomiaru w cloudzie jest i się buduje, a aplikacja nie chce tego odczytać pomimo ze jeszcze kilka dni temu robiła to bez problemu.
Logi serwera, bazy i clouda nie pokazują nic nietypowego.
EDIT: Okazuje się, że tak samo zachowuje się licznik energii. Problem leży chyba zatem na styku aplikacja - serwer. Tylko gdzie szukać?
EDIT2: Przeinstalowałem aplikację, wyczyściłem jej pamięć (telefon z Androidem) i zauważyłem dodatkowo, że nie pobiera mi ikon. O co tu chodzi? Aplikacje działa normalnie, steruje urządzeniami, a nie ma możliwości pobrania historii pomiarów z dowolnego licznika lub czujnika temperatury i nie pobiera ikon. Cloud telefon widzi (przyznany dostęp i staje się aktywny kiedy używam aplikacji).
ROZWIĄZANIE:
Metoda na windowsa pomogła - ./supla.sh upgrade. Po reinstalacji wszystko działa. Nie rozumiem tego (może się coś sypie na dockerowych instalacjach, bo to już drugi czy trzeci raz u mnie, gdy na dziwaczne problemy bez wyraźnej przyczyny pomaga reinstalacja). Trochę teraz żałuję, że po drodze usunąłem sobie historię, ale do przeżycia.
Widzę, że już sobie poradziłeś, ale mimo wszystko napiszę co wiem, może kiedyś się komuś przyda 
a ja się odkopuję w czytaniu tematów na forum.
Zarówno historia jak i ikony pobierane są przez apke po HTTPS na porcie, który wystawiasz dla tego protokołu.
Domyślnie jest to 443 i wtedy nic nigdzie nie trzeba dopisywać.
Ważne, żeby zmienna CLOUD_DOMAIN w pliku .env wskazywała na Twoją instancję najlepiej poprzez domenę osiągalną z LAN i WAN.
Jeśli w CLOUD_DOMAIN jest cokolwiek innego np. domyślne 'cloud.supla.org', a Ty logujesz się do Cloud wpisując adres IP instancji np. 'https://192.168.0.5' to Cloud Ci działa, ale ta konfiguracja jest niewłaściwa. W apce wpiszesz w adres serwera 192.168.0.5 i apka lokalnie w LAN też działa, ale wykresy już nie będą pobierane i ikony też nie. W Cloud wykresy z historią będą działać bo komunikacja Cloud z serwerem odbywa się lokalnie przez socket.
Jeśli CLOUD_DOMAIN zawiera wewnętrzny adres IP, a nie jakąś domenę, to z poza sieci LAN może być problem z pobieraniem historii i ikon. W LAN apka będzie pobierać historię i ikony.
Jeśli w CLOUD_DOMAIN jest np. domena 'cloud.supla.local' i ta domena w Twojej domowej usłudze serwera DNS ma odpowiedni wpis kierujący na adres wewnętrzny IP, to w LAN na apce pobieranie danych będzie działać, ale z zewnątrz może być z tym problem.
Aby wszystko działało w LAN i WAN, to w CLOUD_DOMAIN najlepiej podać domenę, a jeśli używasz innego portu do HTTPS niż standardowy, np. '4444', to trzeba dodatkowo go tam dopisać, bynajmniej kiedyś trzeba było, np. 'mojasupla.pl:4444'. Niemniej jednak rekomenduję używanie standardowego portu 443.
Mając własną domenę i zewnętrzny stały adres IP trzeba ustawić odpowiedni rekord A w strefie DNS domeny kierujący na ten adres IP, lub jeśli masz zmienny zewnętrzny adres IP, to uruchomić DDNS na routerze, a w strefie DNS domeny wprowadzić rekord CNAME na przydzieloną domenę DDNS.
Niezależnie od wszystkiego, po stronie routera, najlepiej zagiąć rzeczywistość i dodać statyczny wpis dla domeny kierujący na wewnętrzny IP z Suplą.
Jeśli router na to nie pozwala, to można postawić sobie obok Supli w dockerze Pi-Hole i tam to zrobić, a wszystkie zapytania do DNS dla klientów LAN kierować do Pi-Hole. Przy okazji przy minimalnej konfiguracji zyskujesz filtr do reklam w całej sieci domowej, możliwość grupowania klientów, wycinania ruchu do konkretnych witryn itp. np. blokowanie YT dzieciakom.
Jeśli jednak nie masz zewnętrznego adresu IP i domeny, to ostatnią deską ratunku jest zestawienie VPN np. przy użyciu Tailscale. Ostatnio przetestowałem i nawet to jakoś działa W CLOUD_DOMAIN wpisujesz wówczas nazwę domeny przydzieloną przez Tailscale, wtedy będzie działać z WAN i zaginasz rzeczywistość dla tej domeny w DNS na routerze lub Pi-Hole aby działało z LAN.
No to tyle z mojego pamiętnika
a ja się odkopuję w czytaniu tematów na forum.Zarówno historia jak i ikony pobierane są przez apke po HTTPS na porcie, który wystawiasz dla tego protokołu.
Domyślnie jest to 443 i wtedy nic nigdzie nie trzeba dopisywać.
Ważne, żeby zmienna CLOUD_DOMAIN w pliku .env wskazywała na Twoją instancję najlepiej poprzez domenę osiągalną z LAN i WAN.
Jeśli w CLOUD_DOMAIN jest cokolwiek innego np. domyślne 'cloud.supla.org', a Ty logujesz się do Cloud wpisując adres IP instancji np. 'https://192.168.0.5' to Cloud Ci działa, ale ta konfiguracja jest niewłaściwa. W apce wpiszesz w adres serwera 192.168.0.5 i apka lokalnie w LAN też działa, ale wykresy już nie będą pobierane i ikony też nie. W Cloud wykresy z historią będą działać bo komunikacja Cloud z serwerem odbywa się lokalnie przez socket.
Jeśli CLOUD_DOMAIN zawiera wewnętrzny adres IP, a nie jakąś domenę, to z poza sieci LAN może być problem z pobieraniem historii i ikon. W LAN apka będzie pobierać historię i ikony.
Jeśli w CLOUD_DOMAIN jest np. domena 'cloud.supla.local' i ta domena w Twojej domowej usłudze serwera DNS ma odpowiedni wpis kierujący na adres wewnętrzny IP, to w LAN na apce pobieranie danych będzie działać, ale z zewnątrz może być z tym problem.
Aby wszystko działało w LAN i WAN, to w CLOUD_DOMAIN najlepiej podać domenę, a jeśli używasz innego portu do HTTPS niż standardowy, np. '4444', to trzeba dodatkowo go tam dopisać, bynajmniej kiedyś trzeba było, np. 'mojasupla.pl:4444'. Niemniej jednak rekomenduję używanie standardowego portu 443.
Mając własną domenę i zewnętrzny stały adres IP trzeba ustawić odpowiedni rekord A w strefie DNS domeny kierujący na ten adres IP, lub jeśli masz zmienny zewnętrzny adres IP, to uruchomić DDNS na routerze, a w strefie DNS domeny wprowadzić rekord CNAME na przydzieloną domenę DDNS.
Niezależnie od wszystkiego, po stronie routera, najlepiej zagiąć rzeczywistość i dodać statyczny wpis dla domeny kierujący na wewnętrzny IP z Suplą.
Jeśli router na to nie pozwala, to można postawić sobie obok Supli w dockerze Pi-Hole i tam to zrobić, a wszystkie zapytania do DNS dla klientów LAN kierować do Pi-Hole. Przy okazji przy minimalnej konfiguracji zyskujesz filtr do reklam w całej sieci domowej, możliwość grupowania klientów, wycinania ruchu do konkretnych witryn itp. np. blokowanie YT dzieciakom.
Jeśli jednak nie masz zewnętrznego adresu IP i domeny, to ostatnią deską ratunku jest zestawienie VPN np. przy użyciu Tailscale. Ostatnio przetestowałem i nawet to jakoś działa
W CLOUD_DOMAIN wpisujesz wówczas nazwę domeny przydzieloną przez Tailscale, wtedy będzie działać z WAN i zaginasz rzeczywistość dla tej domeny w DNS na routerze lub Pi-Hole aby działało z LAN.No to tyle z mojego pamiętnika
SOP 2023 
SOP 2024
Czekam na kolejne Supla Offline Party
: 
cz->b 
+ila
SOP 2024
Czekam na kolejne Supla Offline Party
: 
cz->b 
+ila-
bob_
- Posts: 61
- Joined: Mon Sep 28, 2020 5:49 am
Teraz ja odkopię 
Dzięki za ta wszystkie wyjaśnienia. Chciałem dodać od siebie, że niczego z tych zabiegów nie stosowałem i przez te kilka lat używania Supli tylko czasami się takie problemy zdarzają.
Dla doprecyzowania: mam własną instalację, zewnętrzne IP, do serwera loguję się z zewnątrz przez VPN podając adres IP, w aplkacji Android mam wpisane IP i nazwę użytkownika.
Pozdrawiam
Dzięki za ta wszystkie wyjaśnienia. Chciałem dodać od siebie, że niczego z tych zabiegów nie stosowałem i przez te kilka lat używania Supli tylko czasami się takie problemy zdarzają.
Dla doprecyzowania: mam własną instalację, zewnętrzne IP, do serwera loguję się z zewnątrz przez VPN podając adres IP, w aplkacji Android mam wpisane IP i nazwę użytkownika.
Pozdrawiam