[Sprzęt] MIBOXER_FUT035Z+ (_TZB210_ue01a0s2::TS0502B) [bramka ZigBee]

[zzrr]

...
A atrybut STARTUP ON/OFF (bez TUYA)?

też restart

[vajera]

...
A atrybut STARTUP ON/OFF (bez TUYA)?

też restart

Ok, to jeszcze configure-reporting:
1. klaster LEVEL CONTROL, atrybut CURRENT LEVEL => 1, 3600, 1
2. klaster COLOR CONTROL atrybut 7 => 0, 3600, 1

[zzrr]

...
Ok, to jeszcze configure-reporting:
1. klaster LEVEL CONTROL, atrybut CURRENT LEVEL => 1, 3600, 1
2. klaster COLOR CONTROL atrybut 7 => 0, 3600, 1

klaster LEVEL CONTROL, atrybut CURRENT LEVEL => 1, 3600, 1 tutaj każda wartość i write dawała reset
klaster COLOR CONTROL atrybut 7 => 0, 3600, 1 tutaj też

[zzrr]

...
Ok, to jeszcze configure-reporting:
1. klaster LEVEL CONTROL, atrybut CURRENT LEVEL => 1, 3600, 1
2. klaster COLOR CONTROL atrybut 7 => 0, 3600, 1

klaster LEVEL CONTROL, atrybut CURRENT LEVEL => 1, 3600, 1 tutaj każda wartość i write dawała reset
klaster COLOR CONTROL atrybut 7 => 0, 3600, 1 tutaj też

sorki jeszcze raz... configure reporting a nie write.

[zzrr]

...

1. klaster LEVEL CONTROL, atrybut CURRENT LEVEL => 1, 3600, 1
2. klaster COLOR CONTROL atrybut 7 => 0, 3600, 1
[/quote]
1. klaster LEVEL CONTROL, atrybut CURRENT LEVEL => 1, 3600, 1
wpisywałem wartości 1,3600,1 i za każdym razem to poniżej
Configure reporting successful!
Attribute id is 0x0, data type is U8(0x20)
Min interval is 0(0x0), max interval is 0(0x0)
Delta is 0(0x0)

2. klaster COLOR CONTROL atrybut 7 => 0, 3600, 1
jak wpisywałem wartości 0,3600,1 to za każdym razem po configure-reporting bylo to poniżej
Configure reporting successful!
Attribute id is 0x7, data type is U16(0x21)
Min interval is 0(0x0), max interval is 0(0x0)
Delta is 0(0x0)

[vajera]

...

To jeszcze dla kompletu:
1. C&A.
2. Klaster TUYA (0xE001).
3. Atrybut STARTUP_ON/OFF.
4. Wybierz np. ON.
5. WriteAttribute.

[vajera]

Robimy jakieś pomieszczenie, a tak mam w planach na oddzielnej bramce bez UPS.
Mamy ogólny brak zasilania w domu. Wyłącza się sterownik i bramka. Teraz po powrocie zasilania bez względu co się uruchomi pierwsze pasek CCT idzie na 0%. Więcej... po włączeniu przyciskiem jeśli pierwszy uruchom się sterownik po powrocie zasilania suwak jasności idzie na max ale taśma się nie zaświeca. Masz jeszcze do tego cierpliwość czy się właśnie skończyła? Zaczynam się zastanawiać czy ktokolwiek i gdziekolwiek zabezpiecza się na takie ewentualności i czy to by było tak idealnie tylko w bramce Z2S. W sumie mogę sprawdzić na bramce TUYA tylko co nam to da jak to nie jest żadna wyrocznia. No nie wiem. Co myślisz o tym Łukasz(@vajera)? Warto jeszcze tym zawracać głowę? A może akurat masz na to jakiś swój sposób, jak by nie było tą wcześniejszą nie złą łamigłówkę jednak rozgryzłeś. Sam nie wiem. Hmm

Tak na marginesie, to dotykasz bardziej złożonego problemu, jakim jest zdefiniowanie relacji bramka/sterownik - w sensie, kto w danej sytuacji ma tzw. priorytet.
Możliwe są różne scenariusze:

1. Bramka zapisuje sobie w pamięci FLASH wartości brightness i whiteTemperature (obecnie tak się nie dzieje) i zawsze po ponownym uruchomieniu wysyła je do sterownika zaraz po nawiązaniu kontaktu.
2. Bramka próbuje odczytać stan sterownika i dostosować się do niego - ten scenariusz uwzględnia fakt, że w okresie, gdy bramka była nieczynna, użytkownik mógł zmienić ustawienia sterownika.

Można tutaj pomyśleć o kodzie na wzór HVAC, ale...w przypadku tego kodu działa mechanizm bezwładności (około 5 sekund) niezbędny do uniknięcia pętli śmierci (zmiana w urządzeniu -> bramka -> urządzenie -> itd.), który w przypadku źródeł światła może dawać efekty niepożądane, np. światło będzie się zapalać i gasnąć albo jasność będzie się zmieniać skokowo w jedną i w drugą stronę.

[zzrr]

...

To jeszcze dla kompletu:
1. C&A.
2. Klaster TUYA (0xE001).
3. Atrybut STARTUP_ON/OFF.
4. Wybierz np. ON.
5. WriteAttribute.

Próbowałem ON i OFF i w obu przypadkach jest restart bramki po naciśnięciu write

[zzrr]

Robimy jakieś pomieszczenie, a tak mam w planach na oddzielnej bramce bez UPS.
Mamy ogólny brak zasilania w domu. Wyłącza się sterownik i bramka. Teraz po powrocie zasilania bez względu co się uruchomi pierwsze pasek CCT idzie na 0%. Więcej... po włączeniu przyciskiem jeśli pierwszy uruchom się sterownik po powrocie zasilania suwak jasności idzie na max ale taśma się nie zaświeca. Masz jeszcze do tego cierpliwość czy się właśnie skończyła? Zaczynam się zastanawiać czy ktokolwiek i gdziekolwiek zabezpiecza się na takie ewentualności i czy to by było tak idealnie tylko w bramce Z2S. W sumie mogę sprawdzić na bramce TUYA tylko co nam to da jak to nie jest żadna wyrocznia. No nie wiem. Co myślisz o tym Łukasz(@vajera)? Warto jeszcze tym zawracać głowę? A może akurat masz na to jakiś swój sposób, jak by nie było tą wcześniejszą nie złą łamigłówkę jednak rozgryzłeś. Sam nie wiem. Hmm

Tak na marginesie, to dotykasz bardziej złożonego problemu, jakim jest zdefiniowanie relacji bramka/sterownik - w sensie, kto w danej sytuacji ma tzw. priorytet.
Możliwe są różne scenariusze:

1. Bramka zapisuje sobie w pamięci FLASH wartości brightness i whiteTemperature (obecnie tak się nie dzieje) i zawsze po ponownym uruchomieniu wysyła je do sterownika zaraz po nawiązaniu kontaktu.
2. Bramka próbuje odczytać stan sterownika i dostosować się do niego - ten scenariusz uwzględnia fakt, że w okresie, gdy bramka była nieczynna, użytkownik mógł zmienić ustawienia sterownika.

Można tutaj pomyśleć o kodzie na wzór HVAC, ale...w przypadku tego kodu działa mechanizm bezwładności (około 5 sekund) niezbędny do uniknięcia pętli śmierci (zmiana w urządzeniu -> bramka -> urządzenie -> itd.), który w przypadku źródeł światła może dawać efekty niepożądane, np. światło będzie się zapalać i gasnąć albo jasność będzie się zmieniać skokowo w jedną i w drugą stronę.

Tak na szybko analizując te scenariusze. To wydaje mi się że bardziej prawdopodobny jest pierwszy. Jeśli będziemy mieli zestaw sterownik bramka to należało by założyć że chodzi to w komplecie. Raczej jeśli to będzie oddzielny system nie będzie na bramce UPS i zapisywanie ustawień w pamięci dla tego typu sterowników wydaje się być dobrym kierunkiem. Zakładając dalej brak zasilania pierwszy raczej podniesie się sterownik. W bramce może być ustawione opóźnienie startu też np. Wtedy ustawienia powinny spłynąć z bramki z opóźnieniem na sterownik. Raczej bym odrzucił opcję że użytkownik coś zdąży przestawić w sterowniku nim bramka dołączy do pracy. A takiej opcji że bramka nie pracuje przez jakiś czas też bym nie brał raczej pod uwagę bo jeśli to ma działać razem to tylko razem.Jeśli użytkownik wyłączy bramkę i będzie używał sterownika bez bramki to będzie to robił raczej świadomie wiedząc że po włączeniu bramki ustawienia musi sobie skorelować ręcznie.

[vajera]

...

To jeszcze dla kompletu:
1. C&A.
2. Klaster TUYA (0xE001).
3. Atrybut STARTUP_ON/OFF.
4. Wybierz np. ON.
5. WriteAttribute.

Próbowałem ON i OFF i w obu przypadkach jest restart bramki po naciśnięciu write

To jeszcze jedna prośba, o ile Ci się to jeszcze nie znudziło Usuń sterownik z bramki - najlepiej z poziomu Cloud, wgraj wersję 1.5.99-22/06/26 i sparuj go ponownie z bramką.
Następnie powtórz te próby z C&A - klaster ON/OFF atrybuty STARTUP i TUYA STARTUP, klaster TUYA(0xE001) atrybut STARTUP ON/OFF.
Poprawiłem złośliwy błąd w GUI, więc nie powinno być już restartów - najwyżej dostaniesz Unsupported attribute.