@szopen masz rację Node-RED to osobna bajka i szkoda by to zgineło w gąszczu postów o samej integracji.
Przeniosę to zaraz do odpowiedniego działu w Node-RED i podlinkuję tutaj żeby zachować porządek a jednocześnie ułatwić innym znalezienie gotowca.
1 polubienie
Dołączam się do prośby @Marcin4 , sensor sprawdzający czy są jakiekolwiek przesyłki pozwoli w dużo większym zakresie wykorzystać tą integrację
1 polubienie
@stirante czy dobrze wdzę że dodałeś ten sensor paczek właśnie się zbierałem do pull requestuz ale no cóż wyślę tylko poprawki na bardziej dopasowane do standardów.
Tak, właśnie robię release. Dodatkowo dorzucam raw_response atrybut, gdzie jest surowy JSON z serwera dotyczący paczki jeśli ktoś chce więcej informacji o paczce.
Miałem Ci za chwilę wysyłać Pull Request trochę zmian dodałem.
Oj, mam nadzieję, że nie ma dużo konfliktów
Siedze w domu z grypą to dłubie sobię trochę w HA
to już przygotuje pod nową poprawkę twoją nie zmieniło się zbyt wiele raczej dam tylko przygotowanie pod standardy bo widzę trochę zamieszania raczej nic wielkiego. Wysłałem PR co nieco poprawiłem chyba działa. Sorry za commity. W tej chwili jest 2800 linijek kodu.
1 polubienie
Życzę szybkiego powrotu do zdrowia, ja za to nie miałem wystarczającej ilości czasu i dopiero zaktualizowałem do 1.1.0 (HACS nie pokazywał, że aktualizacja jest dostępna).
I w związku z tym pytanie - czy Integracja ma tak wyglądać?
Bo to sugeruje, że encja sensor.polish_shipment_tracking_active_shipments jest powiązana tylko z poczetex’em.
Sensor dodawany jest globalnie ale przykleja się do pierwszego lepszego entry i wygląda jakby był częścią pocztex. U mnie jest częścią inpostu. Nie do końca wiem jak to rozwiązać szczerze mówiąc. Aktualnie po prostu działa.
1 polubienie
Są dwie opcje, aby to naprawić:
Opcja 1: Odpięcie sensora od konkretnego wpisu (Zalecam)
Zamiast dodawać sensor w async_setup_entry każdego kuriera, powinieneś go dodać w async_setup w pliku __init__.py. Jednak ponieważ async_add_entities jest dostępne tylko w platformie sensorów najprościej jest zmodyfikować sensor.py, aby sensor nie dziedziczył po konkretnym wpisie.
Opcja 2: Utworzenie “Wirtualnego Urządzenia” dla całej integracji
Możesz stworzyć jedno wspólne urządzenie o nazwie np. “Statystyki Przesyłek” do którego będą trafiać globalne sensory. Wtedy niezależnie od kuriera, sensor będzie zawsze w tym samym miejscu.
Jak będę miał coś czasu więcej to może zrobie PR chyba żeby sam to rozwiążesz.
@szopen Na zrzucie Pocztex był prawdopodobnie:
- Albo pierwszym zainstalowanym kurierem.
- Albo ostatnim, który przeszedł proces
async_setup_entrypo restarcie (jeśli encja nie była wcześniej w rejestrze).
@Allon
Nie mam pojęcia jak było, bo wszystkie wpisy w Integracji stworzyłem sobie na jakimś wczesnym etapie (i nie pamiętam w jakiej kolejności ale chyba pocztex był akurat ostatni), więc podczas aktualizacji już wszystkie były utworzone.
@stirante
Do dziś nie wiem czy to działa 
ale autoryzacja tutaj z pewnością wylogowała mi telefon z aplikacji DHL (i kurier mnie zaskoczył, bo się pojawił dzień przed czasem).
Więc kolejna kwestia to, czy jest możliwość równoczesnego używania dedykowanych aplikacji oraz tej Integracji.
DHL to jedyna integracja której nie jestem pewien. Do tej pory nic mi nie przyszło DHLem więc nie wiem jak wygląda dokładnie response z paczką. Inna sprawa że mnie nie wylogowało z apki.
1 polubienie
Gdyby taki byt zaistniał i w nim pojawiały się sensory z danymi - status_key , tracking_number , o identyfikacji kuriera nie wspomnę, byłaby rewelacja.
W praktyce sama informacja paczek jest >0 , jest ok , ale taka zmiana ułatwiłaby tworzenie automatyzacji czy powiadomień.
Taka “struktura kalendarza”, w którym pojawiają się wydarzenia.
1 polubienie
Chodzi coś takiego?
Stałe urządzenie o nazwie np. “Centrum Przesyłek”. W tym urządzeniu będą pojawiać się:
- Sensor globalny (liczba paczek).
- Sensory indywidualne dla każdej paczki (dynamicznie dodawane).
1 polubienie
Nie wiem czy to możliwe, ale załóżmy scenariusz Integracja - sensor globalny (ilość paczek) sensory- encje Inpost, pocztex,itd
Każda encja zwraca null gdy nic nie ma , wpada przesyłka do inpost , encja wypełnia się atrybutami. Czujnik globalny przyda się do ukrywania karty informującej o przesyłkach, a stabilne encje, a nie tworzone dynamicznie to wymarzona sytuacja do powiadomień.
Nie bez kozery napisałem struktura kalendarza , mamy encję np inpost, której jedynym atrybutem jest przyjazna nazwa “Inpost” , a state jest off lub null, gdy pojawia się przesyłka z inpost, encja zmienia state na utworzona i wypełnia się tablica atrybutów. Niestety programistą to ja nie jestem, więc sprowadź mnie na ziemię jeśli to niemożliwe.
W samej integracji można by dodać kosmetycznie ikonę chodzi o ten widok
Ikona zwykłej paczki , ale to kosmetyka.
Tu się odniósł tak
Stateless Sensors: Encje kurierów powinny zawsze istnieć. Jeśli nie ma paczek, stan = 0 lub idle, a nie null/unavailable. Z doświadczenia.
Attributes Overload: Przekazywanie szczegółów paczek w atrybutach sensora kuriera, zamiast tworzenia osobnej encji dla każdego numeru trackingu (to zapobiega zaśmiecaniu bazy danych HA).
Czyli najlepiej jakby było osobne urządzenie z wszystkimi kurierami i sensory dla tych kurirów mają wskazywać albo 0 albo liczbę paczek (prosto dla automatyzacji jeśli więcej lub równo to itd.)
Do tego jeśli są paczki to w atrybutach wyświetlają się szczegóły.
Jeśli chodzi o ikonę integracji to nie jest to prosta sprawa. Sam to przechodziłem i mi się udało kto widział ten widzial. Trzeba mieć ikonę i logo dokładnie 8 muszą mieć przeźeoczyste tlo. Wtedy trzeba wyslać PR do oficjalnego repo homeassistant/brands i się czeka tak z 2 tygodnie, ale w końcu to sam Frenck akceptuje. Nie wiem, ale chyba folder brands na github nie dziala ja go mam ale tylko do dokumentacji. Jest mało takich porad jak tworzyć takie integrację oraz jak przejść tą całą drogę sam widzę jakie to ciężkie.
Nie tłumaczyłem tu specjalnie wszystkich technikaliów i jak to zrobić, ale to nie będzie aż tak trudne.
3 polubienia
Ikona to drugorzędna sprawa, Twoja koncepcja już mi się podoba 
Ikony nie muszą mieć przeźroczystego tła, loga być też nie musi z tego co pamiętam, można tego samego obrazka użyć jako logo…
- Icon size must be:
- 256x256 pixels for normal version.
- 512x512 pixels for the hDPI version.
Może taka?
Ładne ale obawiam się, że te znaki/loga przewoźników są prawnie chronione. Może zostawić paczkę, flagę i dołożyć coś w rodzaju auta kurierskiego w drodze.
2 polubienia
Nie wlaśnie sam wiem bo to robiłem i jak moja integracja nazywała się PGE Dyanmic Energy wręcz wymagali żeby integracja miała logo PGE akurat w tym przypadku raczej nie będa wyamagli tu log przewoźników.
Tu są chyba wszystkie wymagania:
- Wymagania techniczne plików (Wspólne)
Format: Tylko PNG.
Przezroczystość:
Zalecane tło transparentne.
Kompresja:
Obrazy muszą być zoptymalizowane (bezstratnie).
Przycięcie (Trim): puste przestrzenie wokół logo/ikony. Obraz powinien stykać się krawędziami z grafiką (zero zbędnych marginesów).
- Specyfikacja Ikony (icon.png)
Ikona to kwadratowy “awatar” marki.
Proporcje:
1:1 (idealny kwadrat).
Rozmiar standardowy:
256 x 256 px.
Rozmiar hDPI (icon@2x.png):
512 x 512 px.
- Specyfikacja Logo (logo.png)
Logo to zazwyczaj logotyp (napis + symbol) w układzie poziomym.
Proporcje:
Zgodne z oryginalnym logo marki (najlepiej poziome).
Jeśli logo jest kwadratowe, można tylko pliki icon.png – system automatycznie użyje ich jako logo.
- Tryb Ciemny (Opcjonalnie ale warto większość używa trybu ciemnego)
Podsumowanie:
icon.png (256x256)
icon@2x.png (512x512)
logo.png (poziome, wysokość 256px)
logo@2x.png(poziome, wysokość 512px)
No i jeszcze najlepiej dla każdego dark_:
dark_icon.png
dark_logo.png
dark_icon@2x.png
dark_logo@2x.png