Natywna integracja z Home Assistant (komponent) 2.2

A niestety będę mógł to sprawdzić dopiero po 17 , ale myślę że to może być to.

A niestety będę mógł to sprawdzić dopiero po 17 , ale myślę że to może być to.

Spokojnie ja i tak głębiej będę mógł do tego zajrzeć dopiero na weekend. Ale teraz tak myślę, że ten poprzedni sposób może nie wystarczyć. Okazuje się, że w Pythonie warunek value == True będzie spełniony również gdy value = 1.0 czyli float, a pewnie dla zupełni innych typów danych może być podobnie, więc nie będzie widać o co chodzi.

Najlepiej gdy załączysz log tak jak wczoraj i będzie widać co dokładnie przyszło z kontrolera. Wtedy coś można będzie więcej powiedzieć.

I chyba coś z typem danych 'last_sync' jest nie tak bo wykresy są jak od tekstowego, a fajnie by było gdyby był liniowy.

I chyba coś z typem danych 'last_sync' jest nie tak bo wykresy są jak od tekstowego, a fajnie by było gdyby był liniowy.

Raczje nie będzie z tym problemu. Spróbuj dodać po linii 257
coś takiego:

state_class=SensorStateClass.MEASUREMENT,

state_class=SensorStateClass.MEASUREMENT,działa
natomiast bateria cały czas 0%
w załączniku log

Ale przy okazji zauważyłem, że tworzą mi się jakieś dziwne encje:
- climate.wylacznik_sypialnia
- climate.brama_furtka

to jakaś mutacja ROP z RGT

Kod: [Zaznacz]

state_class=SensorStateClass.MEASUREMENT,działa
natomiast bateria cały czas 0%
w załączniku log

hmm, nie rozumiem, tam jest false, czyli wartość logiczna. Powinno się poprawnie zamieniać na procenty w takim razie. A czy sama encja jest ok? Jest aktywna czy HA pokazuje, że jest unavailable?
Pokaż jak wygląda w narzędziach deweloperskich w ekranie Stany.

Ale przy okazji zauważyłem, że tworzą mi się jakieś dziwne encje:
- climate.wylacznik_sypialnia
- climate.brama_furtka

to jakaś mutacja ROP z RGT

A to już w ogóle jest jakaś herezja Pokaż te encje także w ekranie Stany. Mamy sprawę z Archiwum X

Tak wygląda bateria

A co do tych dwóch dziwnych encji to je usunąłem bo miały status "przywrócone" i zobaczymy co będzie. Bo może to po moich wczorajszych "rzeźbach" z baterią

Ta bateria, to jakieś czary - niezależnie od implementacji metody bool_to_int zwraca zawsze 0 Póki co zostawiam rozwiązanie z czytaniem atrybutu.

{% if state_attr('climate.sypialnia', 'battery_status') -%}<ha-icon icon="mdi:battery-low"></ha-icon> Bateria do wymiany.
{%- else -%}
<ha-icon icon="mdi:battery-high"></ha-icon> Bateria OK.
{%- endif %}
Bateria: {{ states('sensor.sypialnia_battery_status') }} %


Ale poziom otwarcia głowicy i czas synchronizacji to super sprawa, w końcu widać co się w instalacji dzieje

Ta bateria, to jakieś czary - niezależnie od implementacji metody bool_to_int zwraca zawsze 0

mi to wygląda jakby w ogóle nie czytał statusu tej baterii, w wersji 2.2b5 pokazywał False a tutaj nawet po pominięciu konwertera zawsze jest 0

Ta bateria, to jakieś czary - niezależnie od implementacji metody bool_to_int zwraca zawsze 0 Póki co zostawiam rozwiązanie z czytaniem atrybutu.

Cytuj

Ta bateria, to jakieś czary - niezależnie od implementacji metody bool_to_int zwraca zawsze 0

mi to wygląda jakby w ogóle nie czytał statusu tej baterii, w wersji 2.2b5 pokazywał False a tutaj nawet po pominięciu konwertera zawsze jest 0

Na razie nie potrafię tego wytłumaczyć. Zajmie to trochę więcej czasu żeby przeanalizować w kodzie co może być problemem. Może na weekend będę miał chwilę. Jak znajdę to oczywiście dam znać.

A na ten moment dzięki za kawki Panowie i kolego @Cezary.K

Absolutnie nie ma pośpiechu, dla mnie to co już jest, jest SUPER!

MAM TO!
Dobrze, że jest coś takiego jak Python online np. https://www.programiz.com/python-programming/online-compiler/ czyli nie trzeba uruchamiać całego komputera, żeby móc sobie na szybko coś sprawdzić w Pythonie

Okazuje się, że Python to taki dziwny język, że funkcja sprawdzająca typ argumentu traktuje True i False jako typ int...nie rozumiem dlaczego i nie ma to dla mnie żadnego sensu, ale niestety tak jest. A co za tym idzie w przypadku, gdy stan baterii to wartość logiczna czyli dokładnie przypadek RGT-01 to funkcja boolint_to_percent zawsze zwróci wartość wejściową. Potem jest to mnożone przez mnożnik 100 (kolejna dziwna rzecz w Pythonie: działanie True lub False * 100 daje wynik typu int a nie błąd niezgodności typów).

Rozwiązaniem jest zmiana detekcji typu wartości baterii - zamiast wykrywać int trzeba było zmienić na wykrywanie bool i odwrócić logikę.

Podmieńcie kod na https://github.com/dgtal1/extalife_custom_component/blob/climate-config-sensors/extalife/helpers/utils.py i będzie dobrze

Teraz widzę, że te funkcje mają bezsensowną nazwę, bo zamiast 0 i 100 to zwracają 0 lub 1, ale zmienię to później w kolejnej wersji, bo to też wymaga zmiany w kodzie sensor.py, aby zmienić mnożnik na 1.

Sprawa rozwiązana

Ja sprawdzę dopiero po 17...

Jednak dzisiaj 17 jest wcześniej, podmieniłem plik i wszystko jest ok THX!

BTW
VPN i SamsugDEX robią robotę

Jednak dzisiaj 17 jest wcześniej, podmieniłem plik i wszystko jest ok THX!

I tak ma być!  choć Python ma jeszcze na pewno dla mnie wiele niespodzianek 

BTW
VPN i SamsugDEX robią robotę

Ja też mam VPN do domu i faktycznie czasem się to przydaje, ale mam też dostęp do HA z zewnątrz, a w HA addon VS Code oraz File Editor, więc mógłbym nawet bez VPN zmienić konfigurację HA w tym pliki integracji. Tego mi właśnie brakuje w AIS - addony. Chociaż z drugiej strony mamy szybko działający HA. Ja od 1.5 roku mam HA w VM na Synology i jestem zadowolony, bo mam addony, ale działą zdecydowanie wolniej niż po prostu w docker czy VEnv, który wykorzystuje AIS. A na PC to HA w ogóle działą jak rakieta. W VS Code, w którym programuję integrację HA startuje w ok 5 sekund. A mój produkcyjny w VM na Synology startuje ok minutę...

A z tym Samsung DEX to co masz na myśli?

Potwierdzam, bateria działa