ZAMEL - ZAPROSZENIE DO TESTÓW mSRW-01 :)

[klew]

Mam możliwość zastosowania przycisku potrójnego do rolet gdzie zewnętrzne klawisze są monostabilne, a wewnętrzny bistabilny. Może da się zrobić , o ile to technicznie na sprzęcie możliwe by po zwarciu In1 z In2 roleta nie była w stanie wykonać jazdy z harmonogramu, ale dalej reagowała na polecenia z apki? Chyba że tak się nie da to będę tym bistabilny odcinać zasilanie dla srw ale to tak jakoś nie po suplowemu.

Niestety aktualnie nie da się rozróżnić na poziomie urządzenia skąd pochodzi request.

Tego typu smaczki powinny być dodane w tzw. "logice" i powinny być obsługiwane po stronie serwera. Np. coś w stylu:
"jeśli kontaktron na oknie A jest naruszony, to nie wykonuj na nim poleceń z harmonogramu"

[klew]

Co do wizualizacji w apce to muszę stwierdzić że mi się nie pokrywa
Moja roleta ma ~230cm wysokości. Wizualizacja do połowy okna w apce to odpowiednik 42% i jak na tyle ustawię to w apce mam przysłonięte okno do połowy. Fizycznie natomiast od silnika w dół wisi ~130cm rolety, a do podłogi jest prześwit ~100cm.

Też mam ten "problem"
Wynika to z tego, że roleta szybciej rozwija się na początku, a wolniej na końcu. Silniki z reguły kręcą w tym samym tempie, jednak jak roleta nawija się, to z każdym kolejnym obrotem zbiera więcej centymetrów pancerza.

Niestety nie ma tutaj prostej reguły aby odgadnąć jak szybko roleta się będzie rozwijać. Ja u siebie próbowałem na 3 roletach (jednej małej ~50 cm, jednej 140 cm, jednej 230 cm) i w każdym przypadku to wygląda inaczej. Albo może taka prosta reguła jest, tylko trzeba ją wymyślić

Także jest tutaj jeszcze pole do usprawnień, ale pytanie czy gra jest warta świeczki, bo pewnie skończyłoby się na dodawaniu jakiegoś nowego parametru...

[lesny8]

Co do wizualizacji w apce to muszę stwierdzić że mi się nie pokrywa

Na pewno powinno być lepiej z określeniem dolnej pozycji niż bez.
Problem z wizualizacją jest taki, że czas zamykania nie jest liniowy.
Musielibyśmy dodać jeszcze jeden parametr określający długoś rolety
po to by szacunkowo określić zmienną średnicę rolki. Na tej podstawie dopiero moglibyśmy
precyzyjnie wizualizować pozycje rolety.

Zgadza się, jest lepiej, bo bez określenia dolnej pozycji jest ~148cm / ~82cm

[klew]

- silnik podłączony, autokalibracja zdobiona na koniec mam taki komunikat " kalibracja została utracona" - nie wiem o co chodzi

Ten komunikat pojawia się, gdy mSRW oczekuje, że roleta zakończy swój ruch, a jednak nadal pojawia się pobór prądu (czyli silnik nadal pracuje).
Spróbuj może skalibrować roletę ponownie.

[pzygmunt]

Albo może taka prosta reguła jest, tylko trzeba ją wymyślić

Jeśli założymy, że grubość lameli jest wszędzie podobna i oprócz czasu otwarcia/zamknięcia będziemy znali długość rolety ewentualnie wysokość okna to można to w miarę precyzyjnie policzyć... ale może mi się tylko wydaje i trzeba by poeksperymentować z kilkoma roletami.

[klew]

Albo może taka prosta reguła jest, tylko trzeba ją wymyślić

Jeśli założymy, że grubość lameli jest wszędzie podobna i oprócz czasu otwarcia/zamknięcia będziemy znali długość rolety ewentualnie wysokość okna to można to w miarę precyzyjnie policzyć... ale może mi się tylko wydaje i trzeba by poeksperymentować z kilkoma roletami.

Ja używam SRW do markiz dachowych Fakro. Tam jest nawinięta tkanina...
Tam też nie ma domykania i 50% bez żadnych korekt działa całkiem dobrze. Nie mierzyłem, ale na oko wyglądało jakby nie było zauważalnego błedu.
Także przydałaby się: średnica rury na którą nawija się roleta, grubość pancerza oraz długość
Ewentualnie wprowadźmy jeden parametr: "nieliniowy korektor pozycji" . Można też próbować dodać "pozycja połowy okna" (analogicznie do "dolnej pozycji") i z tego ekstrapolować ...

[lesny8]

A może wizualizacja w apce powinna się poruszać ruchem jednostajnie opóźnionym podczas rozwijania i jednostajnie przyspieszonym podczas zwijania?

[klew]

A może wizualizacja w apce powinna się poruszać ruchem jednostajnie opóźnionym podczas rozwijania i jednostajnie przyspieszonym podczas zwijania?

To by zepsuło wizualizację dla cienkich rolet, jak np. moje markizy dachowe z Fakro

[lesny8]

A może wizualizacja w apce powinna się poruszać ruchem jednostajnie opóźnionym podczas rozwijania i jednostajnie przyspieszonym podczas zwijania?

To by zepsuło wizualizację dla cienkich rolet, jak np. moje markizy dachowe z Fakro

Niekoniecznie. Jeśli przyspieszenie wyliczane byłoby na podstawie dolnej pozycji to przy ustawionym 0 przyspieszenie by było równe 0

[lukfud]

Aktualizacja stanu jest wysyłana na zasadzie "nie częściej niż co X s". Inne SRW powinny tutaj zachowywać się identycznie z takim samym czasem.

Nie miałem okazji używać SRW, mam porównanie jedynie do arduinowej biblioteki, gdzie wizualizacja jest płynna.

Tak, to jest celowe. Między kolejnymi załączeniami silnika ma być chwila przerwy (chyba około 1 s). Wcześniej w sofcie był dobrny błąd, który powodował, że ten odstęp nie był dodawany przy obsłudze przycisków z lewej strony. Teraz to jest poprawione. Wszystkie SRW dostaną/dostały aktualizację z tą poprawką.

Co mają na celu powyższe zabiegi? Przerwa i "skacząca" wizualizacja.