Cześć
Posiadam kilka czujników temperatury i wilgotności od Xiaomi, model LYWSD03MMC.
Po powrocie z urlopu zauważyłem że wskoczyło kilka aktualizacji w HACS oraz że moja integracja nie działa. Zrobiłem aktualizację ale dalej nie ruszyło. Czy ktoś może mi powiedzieć co się zmieniło i jak dalej to uruchomić?
Tylko Ty wiesz jaka to integracja, 
ja mogę tylko zgadywać czego możesz używasz więc trudno Ci pomóc na podstawie tak ogólnego posta, bez informacji technicznych. Możemy oczywiście zagrać “w 100 pytań do” 
żeby zdobyć wszystkie potrzebne informacje.
1 polubienie
Oczywiście masz rację.
W HACS miałem Passive BLE Monitor integration a w integracjach Bluetooth Low Energy Monitor. Miałem też wpis w configuration.yaml. To fragment kodu.
#Mi temp
ble_monitor:
hci_interface: 0
discovery: False
active_scan: False
report_unknown: False
batt_entities: True
decimals: 1
period: 60
log_spikes: False
use_median: False
restore_state: False
devices:
- mac: ‘A4:C1:38:A5:92:01’
encryption_key: ‘68a6153798ec2a2113a77425ec8a1cce’
name: ‘Zewnętrzna’
temperature_unit: c
PS Jeśli się nie mylę ten YAML można było usunąć lub zakomentować daaawno temu, bo wskazana integracja od dawna obsługuje konfigurację GUI (nie chce mi się szukać, ale jakaś dawna aktualizacja miała opisaną możliwość przejścia z YAML do GUI, nie pamiętam, ale być może było to automatyczne? - no nie jest to pierwsza integracja którą migrowałem z YAMLa do GUI).
Oprócz tego Passive BLE Monitor ma w najnowszym wydaniu breaking changes
Przypuszczam ze faktycznie wpis z configuration.yaml trzeba usunąć. Teraz jak wszedłem w “Bluetooth Low Energy Monitor” to pokazuje takie coś.
Edit:
Przyznam że ciągle nie udało mi się uruchomić tej integracji. Mimo że pobrałem ponownie Passive BLE monitor i usunąłem z configuration.yaml wszystkie wpisy. Co ciekawe, w opcjach Passive BLE zapisane są wszystkie dane dotyczące moich czujników LYWSD03MMC. Nie wiem czy ja je powinienem usunąć i od nowa dodać?
Po pierwsze edytuj posty.
Co do integracji - w katalogu ‘custom_components’ masz folder ‘ble_monitor’ w którym ostania aktualizacja utworzyła kolejny folder ‘ble_monitor’ do którego “przeniosła” wszystkie pliki konfiguracyjne.
Struktura wygląda tak:
config\custom_components\ble_monitor\ble_monitor\ i dopiero tutaj pliki konfiguracyjne
musisz pliki konfiguracyjne skopiować z “drugiego folderu” ‘ble_monitor’ przekopiować do pierwszego aby struktura wyglądała jak poniżej:
config\custom_components\ble_monitor\ i tutaj pliki konfiguracyjne
następnie sprawdzenie konfiguracji i restart HA i wszystko powróci Ci do normy .
P.S.
Wpisy w configuration.yaml są nadal dopuszczalne i z nimi integracja działa.
Konfiguracja YAML jest nadal obowiązująca w przypadku tej integracji (ale trzeba się zdecydować - albo całość w YAML, albo całość w GUI).
W przypadku konfiguracji YAML na czas walki z problemem spowodowanym przez HACS wystarczy ją w całości zakomentować (lub chwilowo usunąć), bo problem z nieistniejącą integracją blokuje możliwość restartu HA (więc zostajemy w pętli nieusuwalnego problemu - walidator YAMLa nam przeszkadza).
Rozwiązanie problemu zostało już 3x podane: w linku do jdtech (nie chciało mi się tego przepisywać sorry) oraz przez @mstefanowicz i dodatkowo @rafkan
PS Jeśli po usunięciu problemu (zakładam, że nie usuwałeś konfiguracji bez backupu lub skopiowania fragmentu konfiguracji w inne miejsce) utracisz część encji (zmienią im się nazwy) to wynika to z breaking changes w Passive BLE Monitor.
PPS rozwiązanie numer 2 - przywracasz backup z czasów, gdy wszystko działało OK (sprzed urlopu?) i robisz aktualizacje komponentów do bieżących wersji (w ten sposób przeskoczysz wersję HACS z problemem)
Sorki, zapomniałem się i utworzyłem nowy.
Mam backup z 7.01 więc przywróciłem sobie wszystko i jeszcze raz spróbuje to zaktualizować tylko o dziwo:
Passive BLE monitor integration mam w wersji 6.3.0 aktualna to 6.9.3
Local Tuya v3.2.4 aktualna to v3.3.0
HACS 1.18.0 aktualny to v1.19.0 albo nawet 1.19.2
Ma to znaczenie w jakiej kolejności będę aktualizował?
Co do “Local tuya” nie wiem jeśli chodzi o pozostałe - bez znaczenia.
HACS 1.19.0 jest trefny i uszkadza komponenty - nawet nie próbuj go instalować - ostatnia wersja to 1.19.2 i ona jest OK
Kolejność niby nie ma znaczenia (tzn. ja nie zauważyłem wpływu, póki oczywiście dany komponent nie jest trefny 
) - jak mam “zapuszczony” HA to aktualizuję hurtem, tylko sprawdzam czy nie ma po drodze breaking changes.
Passive BLE monitor miał dużo radykalnych zmian w ostatnich dniach, więc numery wersji ostro poszybowały do góry
BTW te ostatnie breaking changes dotyczyły raczej u nas mało popularnego sprzętu: Inkbird iBBQ-4.
Natomiast już 6.5.0 wprowadza obsługę termostatu lub higrostatu DIY i czujnika drzwi lub okien DIY (generalnie to po prostu czujnik binarny do zrealizowania np. z użyciem kontaktronu) na bazie LYWSD03MMC (modyfikacja raczej dla hardkorowców, ale możliwa do wykonania), wymaga alternatywnego firmware od pvvx (zalecam aktualną wersję, na dziś to 3.5), tak wyglądają te dodatkowe możliwe do uruchomienia encje (by z nich korzystać trzeba odpowiednio skonfigurować soft pvvx oraz podpiąć sprzęt metodami DIY)
Przywróciłem starą wersję i zaaktualizowałem po kolei HACS, BLE i Tuya. Wywaliłem z configuration.yaml wpis odnoszący się do moich czujników. Sprawdziłem czy w custom components nie zrobił się dubel. Na wszelki wypadek odinstalowałem i zainstalowałem ponownie Bluetooth Low Energy Monitor. Następnie ustawiłem go tak jak na obrazku i cisza. Nie znajduje mi ani jednej encji. Czy ja mam źle skonfigurowany ten dodatek? Powinienem ręcznie jakoś dodać te czujniki czy on sam powinien je znaleźć? Czy powinienem zainstalować jeszcze raz apkę od Xiaomi na telefon i tam dodać czujniki oraz wyciągnąć jeszcze raz encryption key (one się zmieniają?).
Po pierwsze GUI nie jest obowiązkowym rozwiązaniem - możesz nadal mieć ten YAML, który działał wcześniej (tylko musisz go skonfrontować z dokumentacją czy się coś nie zmieniło, u siebie zmigrowałem do metody GUI, bo tych czujniczków jak z tematu przeszło sporo przez moje ręce - robiłem testy z różnych partii czy wskazania są dość wiarygodne, a sporo z nich rozdałem po rodzinie (i wydawało mi się, że to bardziej przyszłościowa metoda biorąc pod uwagę zmiany w samym HA, gdzie developerzy nas zmuszają w wielu integracjach do odejścia od YAML do GUI).
Po drugie jeśli w LYWSD03MMC masz firmware fabryczne, to wymagają one podania tokena (również w GUI), więc się nie skonfigurują automatycznie .
Po trzecie na tym obrazku nie do końca widać wszystko, ale wstawiam kilka przykładowych (widać u mnie 2 dongle BT, ale korzystam tylko z jednego - to krok w stronę przeróbki sprzętu - będzie z niego wyrzucona karta WiFi+BT by zwolnić gniazdo m.2 key-E), niestety nie mam żadnego wolnego sprzętu by go dodać do instalacji (a to moja "produkcyjna, więc nie chcę wywalać niczego co działa, bo to za dużo roboty), interfejs GUI nie jest intuicyjny, ale gdy się przeklikasz to pójdzie gładko.
Po czwarte - skoro już jesteś na takim etapie, że chcesz tworzyć wszystko od nowa, to może warto zmienić soft w LYWSD03MMC na wersję od pvvx? (ma to głębszy sens jeśli nie zamierzasz ich używać z ekosystemem Xiaomi lecz jedynie w HA, bo wtedy można wybrać bardziej energooszczędny protokół) na obrazku porównanie (czujniki pracują w tzw. ciężkich warunkach, ale ponieważ spodziewałem się wyniku, to ten który szybciej traci % baterii a pracuje z protokołem Xiaomi jest w nieco lepszych warunkach (temperatura średnio wyższa o kilka stopni)
@szopen Mam wszystkie termometry flashowane firmware od ATC, ale u mnie producent dalej wyświetla się Xiaomi (MiBeacon). Nie wiesz dlaczego? 
@mstefanowicz
Dlatego, że nie skonfigurowałeś ich po wgraniu firmware “pod siebie” (i teraz rozgłaszają bodajże we wszystkich protokołach, a domyślny w integracji jest fabryczny Xiaomi), aby skorzystać z “energooszczędności” trzeba przełączyć protokół na custom (swoją drogą przy wykorzystaniu tych gadżeciarskich rozszerzeń DIY jak czujnik otwarcia itd. to jest obowiązkowe).
To się robi z poziomu flashera.
Prawdopodobnie będziesz musiał je też odpowiednio przekonfigurować w integracji (w przypadku GUI wystarczy je ponownie rozpoznać).
PS ja mam większość z nich na sofcie pvvx (nie na atc1441 - tamten widoczny na wykresie powyżej jest tylko dla porównania, ale przy okazji kolejnej wymiany baterii wszystkie przerzucam na pvvx).
Tak, ale powiem krótko - soft od pvvx jest znacznie bardziej dopracowany i nawet Aaron Christophel (atc1441) zaleca soft od Victora (pvvx).
Jak dla mnie kluczową różnicą była możliwość zapisu konfiguracji do flasha na sofcie pvvx (soft atc1441 tego nie robił i po wymianie baterii czujnik zostaje zresetowany do ustawień domyślnych, które mi nie odpowiadają - domyślnie startuje z protokołem a la xiaomi), być może atc1441 też już to wprowadził, ale nawet nie będę sprawdzał.
Ujednolicenie wszystkiego ma swoje plusy (teraz mam taki rozpierdziel ze względu na nieprzerwany eksperyment, a skoro już się potwierdziło to co zamierzałem sprawdzić, to nie widzę większego sensu jego dalszej kontynuacji).
Natomiast nie flaszuję teraz ze względu na potencjalną możliwość uwalenia sprzętu w sytuacji gdy ogniwo zasilające nie jest świeże - proces flashowania jest wyjątkowo energożerny - przykładowo aktualizowałem soft w czujniku po pół roku pracy i wskazany stan baterii spadł z około 80% co jest stanem “wyjściowym” dla pvvx który wskazuje stan baterii nieco inaczej, do bodajże okolic 50%). Słowo wyjaśnienia - fabryczny soft sygnalizuje tylko 3 stany 100%, 50% i 10%, atc1441 wskazuje od 100% w dół ale algo opiera się z grubsza na fabrycznym, natomiast pvvx umożliwia pomiar w szerszym zakresie niż 100%, więc wskazanie jest “przeskalowane” i tzw. 100% odpowiada wskazaniu 80% w pvvx (umożliwia to ocenę jakości użytego ogniwa - wskazanie rzędu 100% oznacza dobre i świeżutkie ogniwo, prawdopodobnie od dobrego producenta, które ma również dość wysokie napięcie początkowe i małą rezystancję wewnętrzna)
Soft pvvx domyślnie zapisuje pomiary we flashu (fabryczny soft bodajże też, choć inaczej), ale ustawiając w nim parametr na 0 można z tego zrezygnować (przy współpracy z HA taki zapis nie ma żadnego sensu, a brak tych zapisów powinien nieco przedłużyć żywotność baterii oraz żywotność samego sprzętu, choć prawdopodobnie prędzej żywot skończy czujnik wilgotności niż flash, to jednak takie szacowanie trwałości jest tylko w sferze mojego “gdybania”).
@szopen czy po wgraniu alternatywnego firmware od pvvx do czujnika, nadal można mieć czujnik podłączony w aplikacji Xiaomi Home? Usunąlem czujnik w aplikacji i próbuje na wszelkie sposoby dodać go od nowa ale nie udaje mi się.
@macek
Nie używam oryginalnej aplikacji (celowo - chodzi o czas pracy tych termohigrometrów, które nie rozgłaszając ramek w formacie xiaomi, a jedynie custom działają znacznie dłużej), ale z tego co kojarzę (nie sprawdzałem), to na sofcie od atc1441 nie ma możliwości połączenia z fabryczną apką (protokół xiaomi jest jedynie emulowany, ale nie zawiera klucza/tokena bo nie jest szyfrowany), natomiast soft od pvvx oferuje procedurę przywrócenia oryginalnego tokena, więc raczej jakaś szansa jest (ale nie jestem przekonany, czy stosowanie fabrycznego protokołu ma jakikolwiek sens).
