Czyżby wycofali wersję 2.0.0? U mnie znikła z aktualizacji.
No cóż wydanie 2.0.0 równocześnie z radykalnymi zmianami w HA było raczej głupim posunięciem… więc jakoś nie jestem zdziwiony, ale skoro już jestem na tym wydaniu, to poczekam na rozwój wypadków.
Jeśli mówisz o Dodatku to jednak jest już
tylko najwyraźniej źle opublikowany
Twoja propozycja nazw domen trochę mnie rozbawiła… 
włączyły mi się lekko pejoratywne skojarzenia. Ale pewnie i tak wszyscy wiedzą, że chodziło o:
input_number
input_boolean
To tylko uwaga na rzecz higieny postów, nie bierz jej do siebie…
Wracając do tematu, mam 2 pytania:
-
Czy przed aktualizacją Z2M do 2.x powinienem zrobić także update
firmwarekoordynatoraSkyConnect. Czy może lepiej po? Moja aktualna wersja to 7.3, ale jest już dostępna nowsza wersja.
Znalazłem jednak na stronach produktu takie oto zastrzeżenie:
Tymczasem mój SkyConnect ma już prawie 2 lata, więc jak mogę zrobić update uwzględniając powyższe? -
Wszystkie opisy procedury update’u odnoszą się gł. do adaptera
zstack. A co z adapteremember? Czy procedura jest dokładnie taka sama, czy też są jakieś różnice?
-
mogłeś podać całego linka bo widzę, że to nie jest jedyne zastrzeżenie i w ogóle obecnie odradzają zmianę firmware w Skyconnect
Home Assistant Connect ZBT-1 -
być może nie zalecają flashowania starych egzemplarzy, bo stare wersje mają wadę konstrukcyjną - przegrzewający się stabilizator napięcia, a w trakcie flashowania zapotrzebowanie MCU na prąd jest sporo wyższe niż przy normalnej pracy (ten temat jakoś przycichł - poszukaj po forum zbt-1 )
-
procedura zmiany firmware jest totalnie inna niż dla koordynatorów
zstack(masz całkowicie inny MCU niż TI) -
7.3 raczej nie jest jakoś strasznie stara (w ogóle coś mi ta numeracja się nie zgadza daj mi sprawdzić, bo to dziwnie wygląda - aktualna to ncp_7.4.4.0 więc z pewnością nie ma wersji 7.3 jest co najwyżej 7.3.0.0 albo 7.3.1.0 ewentualnie 7.3.2.0 ),
ja bym jednak zrobił update przed próbą aktualizacji Z2M, jeśli aktualizację chcesz robić z poziomu HA to Z2M powinno być wyłączone (sugeruję jednak fizycznie odłączyć dongla i zaktualizować na innym komputerze), edit - skreślenie w świetle punktów 0. i 1. (które dopisałem później, ale uszeregowałem w/g ważności)
- to nie jest prawda, poszukaj po forum - edit chyba nie zrozumiałem stwierdzenia - w punkcie pierwszym piszesz o firmware, a w drugim jest nagły przeskok do z2m? to w takim razie nie ma różnicy, bo koordynatory SiLabs zawsze wymagały określenia z jakiego sterownika się korzysta (szczególnie, że zależnie od wersji firmware są 2 różne sterowniki)
- Dodatek w wersji 2.0.0-x “w tej chwili” wywiało ze Sklepu, więc nie ma możliwości aktualizacji do momentu prawidłowej publikacji poprawionej wersji
I just updated to 2.0.0-1 yesterday afternoon by mistake, without any preparation. A New Frontend is available message popped up in the Android App on the bottom, and when I hit the RELOAD on that, I was on the Z2M update page. It took the press to update Z2M.
A few minutes later, I relaized, that I have updated by mistake, so checked the logs, it was failing. So added the required lines to the configuration:
advanced:
homeassistant_legacy_entity_attributes: false
homeassistant_legacy_triggers: false
legacy_api: false
legacy_availability_payload: false
device_options:
legacy: false
And the most important, which was the reason of failing:
serial:
adapter: zstack
Restarted the addon and all worked out fine.
I had to update 2 or 3 Automations, because it was using single click, instead of single action from an Aqara button.
1 polubienie
Oczwiście masz rację. Mój firmware to 7.3.1.0, napisałem na skróty (co nie jest - jak widać - dobrą praktyką).
W oryginale pierwotnym (po zakupie) mój SkyConnect zgłaszał się w Z2M jako ezsp. Potem ogłosili zakończenie wsparcia dla tego typu (pytanie: typu czego?) i sugerowali przesiadkę na ember. Zrobiłem więc zgodnie z zaleceniem update firmware właśnie do wersji 7.3.1.0 i ustawiłem typ adaptera na ember. Dziś widzę go tak:
bo w konfigu mam tak:
Na tym drugim obrazku słowo [Adapter] jest dla mnie mylące: dotychczas myślałem, że
SkyConnect to marka dzyndzla, a ember to nazwa sterownika zaszytego w firmware wgranym do dzyndzla.
Mam więc w głowie totalne pomieszanie pojęć. Czy mogłbym prosić o kilka słów porządkujących lub chociaż jakiś edukujący link do poczytania?
Tzn:
- Czym jest SkyConnect? Czy to marka produktu, nazwa produktu, czy jego typ?
- Czym są wobec tego:
ember,ezsp,zstack,deconz. Czy są też inne? - Czy każdy dzyndzel na rynku rekomendowany dla HA+Z2M może być dowolnego typu w kontekście pyt.2? Czy to jest wymienne? Od czego jest zależne?
- Czy sterownik jest częścią firmware’u (logika mi mówi, ze tak właśnie jest), czy też odwrotnie?
- Czy jeden firmware może zawierać wiele sterowników?
- Dla mnie koordynator to hadware, sterownik to software. Ale poniższy post zabija we mnie nadzieję na zrozumienie:
Z tego wnioskuję wprost, że zstack to jednak koordynator (hardware) a nie jego sterownik. W takich chwilach buntuje się mój procesor logiczny…
Byłbym bardzo wdzięczny na jednoznaczne odpowiedzi z wyjaśnieniami, inaczej nadal będę jak dziecko we mgle…
Dobra tłumaczę, bo zrobiłeś zmiany, a nie zadałeś sobie trudu by znaleźć u źródła czemu… ember i ezsp wskazują na sterownik jaki ma użyć Z2M
ezsp był pisany bardzo dawno (być może trochę “na kolanie”, czyli na siłę by tylko uruchomić sprzęt, ale w dużym skrócie nie był napisany optymalnie) i nie był (a w każdym razie już nie jest) rozwijany wraz ze zmianami w SDK SiLabs, więc nie nadaje się do użytku z firmware opartych na nowych wersjach SDK, więc nadaje się do użytku z wersjami załóżmy, że <7.0.0.0 bo nie pamiętam (jest to do sprawdzenia w dokumentacji).
Ktoś inny (tak mi się wydaje, ale szkoda mi czasu na sprawdzanie) od pierwotnego autora ezsp podjął się roboty związanej z pisaniem sterownika od zera i to całkiem niedawno, no i wyskrobał sterownik ember, ale on do działania wymaga jakiejś tam minimalnej wersji firmware (załóżmy że >=7.0.0.0 bo nie pamiętam, ale generalnie wersjonowanie firmware jest powiązane z wersjami SDK które wypuszcza sam SiLabs), bo nowy kod sterownika nie zawiera obsługi starych funkcji porzuconych w nowszych firmware (dzięki temu też może działać optymalnej), za to są nowe, których nie było dawniej.
Aby było weselej EZSP to skrót od pełnej nazwy EmberZNet Serial Protocol (a to już wymyślił sam producent MCU czyli Silicon Labs, a oficjalnie skrótowo SiLabs) więc nazwy OBU sterowników pochodzą od tego samego…
TYLE
no weź, poważnie pytasz?… nazwa handlowa, można powiedzieć, że typ i marka (marketingu nie kończyłem, ale ta nazwa nijak się nie kojarzy z Zigbee, jeszcze ktoś by pomyślał, że to do łączenia się z satelitami Muska i co?), ale ktoś w NabuCasa się technicznie wziął do roboty i zmienili nazwę modelu na bardziej techniczną: ZBT-1
edit, bo nie wspomniałem - ZBT wygląda na literki wzięte z 2 słów: ZigBee/Thread co jako-tako odzwierciedla możliwości sprzętu i nie kojarzy się z osprzętem satelitarnym
to nazwy sterowników sprzętu (konkretnie koordynatora Zigbee) używanego przez Z2M, są też inne conbee (tu się nazwa zbiega też z pierwszym modelem linii sprzętu Conbee) zigate (podobnie) czy zboss oczywiście każdy z nich pasuje do jakiegoś konkretnego sprzętu pracującego na jakimś określonym firmware (bo koordynator jest na tyle skomplikowanym urządzeniem, że ma własny system operacyjny i oprogramowanie które w nim pracuje, co umownie nazywamy całościowo jako firmware)
weź przeczytaj sobie całą dokumentacją Z2M,
są takie które są OK i takie gdzie to raczej zabawa i eksperyment (ale np. taniość sprzętu jest zachęcająca do rozwoju)
zależy jak rozumiesz wymienne, jeśli sobie cała sieć zbudujesz od nowa to każdy z każdym jest wymienny, jeśli nie chcesz budować od zera, to jesteś skazany na ten sam typ lub rodzinę sprzętu (by móc przeprowadzić JEDNORAZOWĄ migrację sieci na inny koordynator, UWAGA to proces jednorazowy i nieodwracalny, bo zmienia sprzętowy adres koordynatora co jest możliwe do wykonania tylko raz, to jest czynność serwisowa i z grubsza tak zaprojektowana by ktoś nie mógł w prosty sposób niskopoziomowo przejąć sieci)
ani jedno, ani drugie
czy sterownik myszki komputerowej jest składnikiem jej firmware?
5 - patrz 4
6 skrót myślowy tam zastosowałem, czy każdemu trzeba pisać jak krowie na rowie
koordynatory na bazie MCU Texas Instruments (oficjalny skrót tej długiej nazwy to… TI) używają firmware o nazwie zstack firmware
A tak się jakoś składa, że zwykle gdy powstaje wielki projekt to na jego początku nikt się nie zastanawia nad różnymi nazwami dla różnych jego fragmentów, więc z tym firmware współpracuje sterownik o nazwie… zstack
Ten sam numer dotyczy EZSP… (tylko tam masz MCU Silicon Labs)
podobnie jest z deconz (tele że Dresdem Elektronik używa różne MCU od różnych producentów, m.in. dawny Atmel dzisiaj Microchip a ostatnio Silicon Labs do produkcji swoich koordynatorów i tam niezależnie od sprzętu ich autorskie firmware nazywa się deCONZ)
itd. itp.
po drodze jest jeszcze milion szczególików technicznych (bo to rozwiązanie ma o wiele więcej pięter programowych niż takie uproszczenie: sprzęt-firmware-sterownik-serwer )
Działanie jest nieco podobne do sieci komputerowej, więc zajrzyj na wiki
Dodatkowo, słowo sterownik w języku polskim jest wieloznaczne, a w dodatku znaczenia się nie pokrywają w pełni z angielskimi znaczeniami driver
Więc wydaje mi się, że określenie jako adapter jest pasujące (podkreśla nierozerwalność sterownika z modelem/rodzajem sprzętu) tylko “sprawa się rypła”, gdy do jednego rodzaju sprzętu fizycznego powstały różne niekompatybilne firmware i różne sterowniki dla tych firmware.
3 polubienia
Jak dla mnie obecna dokumentacja Z2M, dotycząca obsługiwanych koordynatorów (adapters), jest napisana w sposób dość dobrze obrazująca różnice w nich. Masz podział z grubsza po rodzaju użytego MCU i sterownika:
3 polubienia
@szopen
dopisałem w configuration.yaml to:
advanced:
homeassistant_legacy_entity_attributes: false
homeassistant_legacy_triggers: false
legacy_api: false
legacy_availability_payload: false
device_options:
legacy: false
1 polubienie
U mnie jakoś poszło Na wstępie wyleciały wszystkie przyciski WXKG01LM.
Wróciły po dodaniu do zigbee2mqtt\configuration.yaml
homeassistant:
enabled: true
legacy_action_sensor: true
oraz po ponownej ich konfiguracji w NR.
Dokładnie tak, zamiast ‘click’ jest ‘action’. W NR należy tą encję zaktualizować.
@Szopen, @angler Bardzo Wam dziękuję za superwyjaśnienia 
. Właśnie przetwarzam całą dokumentację Z2M. Czytanka na pół dnia
Mam jeszcze 2 pytania dot. lokalizacji samej konfiguracji. Często w postach widzę odwołania do pliku configuration.yaml z konfiguracją Z2M (nie HA). Swoją drogą, wg mnie ten plik powinien mieć zmienioną nazwę, żeby nie robić zamieszania…
- Aktualna lokalizacja pliku konfiguracyjnego to:
/config/zigbee2mqtt/configuration.yamlGdzie ten plik powinien się znajdować PO migracji do wersji 2.0.2? Czy trzeba go będzie przenieść ręcznie, czy też procedura migracji stworzy nową, odpowiednio zaktualizowaną wersję tego pliku? - Jak się ma zawartość tego pliku do konfiguracji ekranowej samego dodatku Z2M?
Pytam o to jak zawsze dla jednoznaczności informacji. Zauważyłem bowiem, że w plikuconfiguration.yamlznajduje się część wpisów konfiguracyjnych tworzonych na etapie instalowania dodatku Z2M, jak tutaj:
Ale wspomniana część wpisów jest jednak w pliku configuration.yaml uzupełniona o całą masę innych parametrów i ustawień, których nie ma w oknie konfiguracji dodatku. U mnie plik configuration.yaml ma 2kB, podczas gdy yaml z ustawieniami z powyższego ekranu to raptem kilkanaście linijek.
Czym różnią się one logicznie? Czy oba źródła konfiguracji mają ten sam priorytet, czy też któreś z nich jest ‘ważniejsze’? Jaki cel ma trzymanie konfiguracji w dwóch miejscach? To prosta droga do crashu…
Zauważyłem też niekonsekwencje. Np. w oknie konfiguracji parametr rtscts może mieć przeciwną wartość (tutaj: false) do tego samego parametru ale w configuration.yaml (tutaj mam true). Oznacza to dwie różne wartości tego samego parametru…
Nie rozumiem braku konsekwencji… 
Wybaczcie, jeśli moje pytania są lamerskie… ale Wy pewnie też kiedyś tego nie wiedziliście… 
Wyobraź sobie, że te oprogramowanie nie powstało z myślą o użytkownikach HA i nie ma żadnego obowiązku używania tego jako AddOn. Ja używam jako zwykły kontener docker’a. Dlatego nazwa pliku jest moim zdaniem jak najbardziej prawidłowa i spotykana w bardzo wielu projektach. Jest logiczną konsekwencją używania danego oprogramowania.
Niby dlaczego?
W każdym systemie sytuacja gdzie są pliki o tych samych nazwach (których lokalizacja wyjaśnia wszystko) jest normalna.
W dodatku nazwa wyraźnie określa do czego ten plik służy, a rozszerzenie informuje jaki to format danych.
Ad. 1. Autorzy starają się tak zrobić by stało się to automatycznie, ale wszystkiego nie da się przewidzieć, dlatego do tej przełomowej aktualizacji jest dodatkowa dokumentacja.
Ad. 2. To jest trudno wytłumaczyć, ale generalnie praktycznie całość konfiguracji w configuration.yaml ma jakieś odzwierciedlenie w GUI (a w każdym razie taki jest plan docelowy, ale nigdy nie musiało, bo GUI jest tylko “dokładką” do Z2M, sam serwer Z2M go nie wymaga do działania), natomiast konfiguracja Dodatku jest maksymalnie okrojona (zostało tam tylko to czego się nie da na obecnym etapie wyrzucić, a zbędne ustawienia są ignorowane) - celem jest zgodność konfiguracji między różnymi platformami instalacji Z2M (bo przede wszystkim to jest od zawsze samodzielny serwer, a stosunkowo od niedawna jest dostępny też jako Dodatek do HA)
Gdybyś czytał wszystko co napisałem w tym wątku byś znalazł wyjaśnienie
z jednej strony pomysł na przechowywanie ikonek w pliku tekstowym jest słaby (dlatego się ucieszyłem, że z tego zrezygnowano)
z drugiej strony to zapewnia wsteczną zgodność nawet z systemami operacyjnymi sprzed 40 lat gdyby tylko obsługiwały node.js (a niektóre rozwiązania embedded nie korzystają z najnowszych cudów techniki - świetny przykład z dziedziny Zigbee - CC2531 zawiera w środku MCU zgodny w 100% z intel P8051 - czyli konstrukcją sprzed 45lat, by być bardziej konkretnym jest to unowocześniona konstrukcja MCU która tam zastępuje procesor, ale funkcjonalnie jest identyczna z pierwowzorem).
1 polubienie
U mnie podobnie. Po spełnieniu wymagań wstępnych wszystko przeszło bez bólu, choć system wymagał aż dwukrotnego pełnego restartu. Nowe foldery konfiguracyjne /addon_configs/45df7312_zigbee2mqtt są na razie puste, ale w dokumentacji Z2M nie ma o nich słowa, więc się tym na razie nie przejmuję.
Spostrzeżenie: Upgrade miał podnieść wersję do 2.0.2, tymczasem podniósł do 2.0.0. Ale wszystko działa.
@szopen, @angler - jeszcze raz dzięki za wiedzę. Szacun! To naprawdę pouczająca lekcja. Wreszcie zaczynam jarzyć konteneryzację aplikacji… Rzeczywiście mój pomysł ze zmianą nazwy pliku konfiguracyjnego na unikalny dla HA był trochę bez sensu…
Aktualna wersja: 2.0.0-2 już jest, trzeba chwile poczekać, bo czasami sama aktualizacja coś mieli kilka chwil. U mnie pojawiła się dopiero po restarcie HA dla innej aktualizacji.
Bo trzeba odróżnić wersję Dodatku, dziś to 2.0.0-2, od wersji Zigbee2MQTT, którą on zawiera i jest to dziś wciąż 2.0.0, swoją drogą obecne wersjonowanie tego Dodatku (w tej postaci od wersji 1.18.x) wygląda tak S.S.S-K, gdzie S to numer wersji serwera, a K to kolejna wersja kontenera, który go zawiera (wyjątkowo liczona od 1).
Kiedy konfiguracja zostanie przeniesiona w miejsce charakterystyczne dla konfiguracji Dodatków nie wiem, ale ta migracja może zająć miesiące - bo to ma dotyczyć każdego Dodatku w tym setek czy tysięcy nieoficjalnych.
Przy okazji teraz zrozumiałem twoje spostrzeżenie o 2kB konfiguracji, tyle jest normalne (zależy od wielkości sieci, stopnia jej skomplikowania i w sumie wszystkiego, co widać jako jawny tekst), natomiast wcześniej to były wielkości rzędu kilkuset kB czy kilku MB (i w sumie nie wiem jak długo, ale nie “od zawsze”) ikony, z których korzysta GUI były wrzucone do YAMLa metodą jaką się np. wrzuca załączniki do e-maili (by nie zaciągać ich online za każdym razem).
U mnie bardzo dziwny objaw, piloty IKEA które mam dodane po Zigbee przestały działać, może ktoś ma podobnie… w logu Zigbee2mqtt widzę jak przyciskam przycisk na pilocie info w logu jak na zrzucie
Natomiast w HA a co za tym idzie w Node Red nie mam już encji sensor.XXXX_action za pomocą której wywoływałem zgodnie z opisem danego pilota funkcję na konkretne kliknięcie np.
toggle , brightness_up_click , brightness_down_click teraz nie mam już takiej możliwości… mam za to w HA encję o nazwie danego pilota Zidentyfikuj ale jej wywołanie nie działa i nie jestem w stanie z pilota jej wywołać, ktoś poradził sobie z tym?Pozostałe urządzenia np. binarne czujniki otwarcia drzwi działają i wykonują swoje czynności.
A czytałeś notatki do wydania? (linki są u góry czytaj całość)
Po to ten wątek tu wisi od miesiąca, aby ostrzec innych przed breaking changes…
(teraz powiesiłem go na samej górze jeszcze na pół roku)