swistakm
commented
6 months ago @shibby20 sorry że odpowiadam dopiero po dwóch tygodniach, ale pozostałe zobowiązania i równolegle prowadzone prace nie pozwoliły mi pochylić się nad tym problemem z dostateczną uwagą. Za to miałem dostatecznie czas aby zasięgnąć informacji w zespole Blebox.
Nie wypowiem się co do poprzednich sytuacji gdy nazwy encji się zmieniały ponieważ oficjalnym opiekunem tej biblioteki stałem się całkiem niedawno, a do tego czasu znajdowała się ona raczej na peryferiach mojej uwagi. Co do obecnych zmian, mogę zapewnić, że nie były one intencjonalne. Niestety były też jak się okazuje nieuchronne. Jedyne co w tej chwili jestem w stanie zrobić to wyrazić ubolewanie nad zaistniałą sytuacją i naświetlić okoliczności/powody zaistniałej sytuacji.
A powody są zarówno architektoniczne i historyczne, jak i najzwyczajniej w świecie - ludzkie. Aby to lepiej zrozumieć muszę rozbić problem na czynniki pierwsze.
Jak słusznie zauważyłeś, nastąpiła pewnia niezamierzone zmiana w obrębie nazewnictwa encji dla urządzeń typu switchbox/switchboxd, tj. część encji zmieniła nazwę z <nazwa>_switchboxd_relay_<x> na switchbox_relay_<x>
Moim zdaniem problem ten jest pochodną aktualizacji firmware'u urządzenia. Infiksowa część nazwy (tutaj switchbox albo switchboxd) jest na chwilę obecną tylko i wyłącznie wartością typu urządzenia raportowaną przez samo urządzenie w końcówce API odpowiedzialnej za jego identyfikację (np. /info w nowszych urządzeniach, /api/device/state w starszych)
Tutaj pojawiają się okoliczności historyczne. Według mojej wiedzy, switchbox był urządzeniem z jednym przekaźnikiem a switchboxD urządzeniem z dwoma przekaźnikami. Twórcy urządzeń stwierdzili, że nierozsądne byłoby tworzenie nowych klas urządzeń i dedykowanych wersji API dla większej (dowolnej) liczby przekaźników. Stąd nastąpiła naturalna decyzja o połączeniu obu interfejsów w jeden, tym bardziej, że api switchboxd było już strukturalnie kompatybilne. Z tego co wiem, dotychczasowe urządzenia switchboxd mogą się raportować jako switchbox po pewnej aktualizacji. Zaistnienie owej zmiany nazwy zdaje się być tego oczywistym dowodem. Ostateczną pewność uzyskalibyśmy sprawdzając odpowiedzi z końcówek /info lub /api/device/state
Na obronę twórców urządzeń switchbox/switchboxd mogę tylko powiedzieć, że nie był to efekt łatwy do przewidzenia. Biblioteka blebox_uniapi rozwija się niezależnie i w niepomijalnej mierze z udziałem niezależnych kontrybutorów w ogóle nie powiązanych z firmą BleBox. Tutaj wina jest po stronie architektury biblioteki, która nie przewidziała możliwości wystąpienia tego typu zmiany. Z innej strony, zmiana typu urządzenia wydaje się również bez precedensu. Trudno było przewidzieć że może ona kiedyś nastąpić.
Sprawę zaciemnia dodatkowo fakt, że w najnowszej wersji faktycznie dokonaliśmy pewnych poprawek dotyczących switchbox/switchboxd w tym retroaktywnie dodaliśmy definicje manifestów dla urządzeń ze starszymi wersjami API. To z kolei było konieczne aby odpowiednio różnicować pomiędzy urządzeniami które wspierają pomiar mocy, a tymi które go nie wspierają.
Na sam koniec dodam, że najbardziej niefortunny jest sam fakt adresowania/identyfikowania urządzeń w sposób z jakim mamy do czynienia obecnie. Tym bardziej, że każde z urządzeń raportuje już globalnie unikalny pseudolosowy identyfikator. Jest to niewątpliwie dług technologiczny, który ciągnie się się za nami już od pierwszych dni istnienia biblioteki. Nie tylko powoduje to wspomniane trudne do przewidzenia, przetestowania i wychwycenia zmiany ale utrudnia nam wprowadzenie innych długo wyczekiwanych zmian (np. wsparcie do re-identyfikacji urządzenia po zmianie dzierżawy DHCP, rekonfiguracja encji przy bardziej skomplikowanych produktach jak lightbox).
Niestety, oczywista poprawka tej sytuacji - tj. zastosowanie owego unikalnego identyfikatora - byłaby dużo dalej idąca w skutkach. Jest to dosyć niekomfortowa sytuacja, w której strukturalnie konieczne poprawki spowodują bardzo duże niezadowolenie potencjalnie szerokiej rzeszy użytkowników.
Z mojej strony mogę prosić tylko o wyrozumiałość. Będziemy stopniowo upraszczać architekturę biblioteki tak aby była ona prostsza do zrozumienia i bezpieczniejsza do rozwijania. Mam nadzieję, że stopniowo doprowadzi to do zmniejszenia liczby niespodzianek tego typu, o ile będzie to coś co możemy kontrolować po naszej stronie.
shibby20
Już powijam fakt, że to już kolejny raz gdy aktualizacja zmienia postać encji np. z switch.kuchnia_swiatlo_switchboxd_0_relay_0 na switchkuchnia_swiatlo_switchboxd_relay_0, rozwalając w ten sposób wszystkie: zmiany typów encji, grupy encji oraz automatyki przypisane do tej encji.
Natomiast dziś zauważyłem że doszedł kolejny element taki jak niespójność w nazwach encji i tak:
encje switchboxD nazywają się switch.przedpokoj_swiatlo_switchbox_relay_0 switch.przedpokoj_swiatlo_switchbox_relay_1 a było wcześniej "...switchboxd_relay_0" czyli zniknęła literka "d" z nazwy encji
natomiast encje Simon54 Go Switch D czyli de facto Simon54 z wbudowanym SwitchboxD wykrywane są jako switch.kuchnia_swiatlo_switchboxd_0_relay_0 switch.kuchnia_swiatlo_switchboxd_0_relay_1 czyli tu "d" w nazwie switchboxd pozostało, dodatkowo ma (po staremu) dodatkowe "0" w nazwie.
Skoro jedno i drugie urządzenie to switchboxD to czemu są różnie wykrywane nazwy encji??
Bardzo podobna sytuacja jest przy:
Nie rozumiem tego kompletnego braku logiki.
HA najnowsze tj 2024.2.3 + wymuszone blebox_uniapi 2.2.2 (by mieć poprawkę dla błędów w logach oraz działające Power Consumption)