Dimmer sterowany jednym przyciskiem

[klew]

To nie bug, to feature
Ustawienie na 1-3% to taka blokada fizycznego przycisku

Sprawdzę i poprawię

[YoMan]

To nie bug, to feature
Ustawienie na 1-3% to taka blokada fizycznego przycisku

Sprawdzę i poprawię

Coś już pisałem o sarkaźmie ?

[LukaszH]

Troszkę chciałem przypomnieć się z tematem poprawek do dimmera. Jak jest wyłączony kanał to przytrzymanie nie powinno uruchamiać rozjaśniania czyli uruchomić go (najlepiej od 1%) ? To kwestia biblioteki czy ustawień GG ?

[YoMan]

Troszkę chciałem przypomnieć się z tematem poprawek do dimmera. Jak jest wyłączony kanał to przytrzymanie nie powinno uruchamiać rozjaśniania czyli uruchomić go (najlepiej od 1%) ? To kwestia biblioteki czy ustawień GG ?

@klew się kazał przypominać co pół roku więc najbliższe przypomnienie wypada 28.05.2023

[LukaszH]

Racja, chociaż każdy ma inny termin przypominania
Trochę jeszcze pomęczę w sprawie dimmera szczególnie pod kątem tego projektu: 3xDimmer @lukaszh
1. Prośba o zmianę pinów w płytce: przyciski to 1=GPIO5, 2=GPIO4, 3=GPIO16; Wyjścia dimm: 1=GPIO14, 2=GPIO12, 3=GPIO13 i ostatnie dodanie DS18b20 na pinie GPIO 2. Dodatkowo z uwagi że są tam PC817 to nie może być zaznaczona opcja pull up dla przycisków, ponieważ robi się dzielnik napięcia i nie zbija do 0V (przez co przyciski nie reagują prawidłowo).
2. Do NTC10k niestety użyłem 100k rezystora, a soft jest na 150k. Można coś zaradzić np. dodanie pola wyboru jaki rezystor podciągający do VCC?

Dodatkowe funkcjonalności jeśli możliwe:
3. Możliwość warunkowania także kanału dimmera (RGBW) - dzięki czemu można by ustawić zabezpieczenie po przekroczeniu wysokiej temperatury na NTC10k np 80 stopni aby wyłączyło kanał.
4. Dodanie AT do przycisku dimmera. Aktualnie albo coś nie umiem ustawić albo przyciski nie reagują na AT (w cloud się pokazują). Chciałbym je wykorzystać że np. 2x click to 5%, 3x click to 100%. Jedno kliknięcie i przytrzymanie pozostało by do funkcji dimmera.

Oczywiście nadal brakuje wystartowania ściemniacza od "0" przez przytrzymanie buttona ale to rozumiem że biblioteki i trzeba poczekać na poprawki od @klew ?
Temat logarytmicznej funkcji do ściemniaczy to jak kiedyś będzie więcej czasu

[YoMan]

Racja, chociaż każdy ma inny termin przypominania

@klew tak sugerował

4. Dodanie AT do przycisku dimmera. Aktualnie albo coś nie umiem ustawić albo przyciski nie reagują na AT (w cloud się pokazują). Chciałbym je wykorzystać że np. 2x click to 5%, 3x click to 100%. Jedno kliknięcie i przytrzymanie pozostało by do funkcji dimmera.

pisałem o tym do @krycha88 - obiecał w wolnej chwili dołożyć

Oczywiście nadal brakuje wystartowania ściemniacza od "0" przez przytrzymanie buttona ale to rozumiem że biblioteki i trzeba poczekać na poprawki od @klew ?

chyba od tego zaczęliśmy

Temat logarytmicznej funkcji do ściemniaczy to jak kiedyś będzie więcej czasu

tutaj coś się poprawiło ostatnio. Jest płynniej i bardziej liniowo dla oka. @krycha88 pisał, żeby podać wzór to on go zaimplementuje 1:1 ale chyba nikt nie chce wziąć na siebie tej odpowiedzialności. Pisałem na forum prawdopodobny wzór ale trzeba by go zastosować i przetestować. Próbujemy?

[LukaszH]

@krycha88 chciałem troszkę się tutaj też przypomnieć odnośnie poprawek jakie pisałem 2 posty wyżej:) Dodatkowo to co pisze YoMan ale ja się nie podejmuje napisania wzoru na logarytmiczną funkcję, chociaż kilka przykładów w necie znalazłem (wydaje mi się że to i tak część biblioteki i trzeba poczekać na @klew)

[Hrumque]

Temat logarytmicznej funkcji do ściemniaczy to jak kiedyś będzie więcej czasu

tutaj coś się poprawiło ostatnio. Jest płynniej i bardziej liniowo dla oka. @krycha88 pisał, żeby podać wzór to on go zaimplementuje 1:1 ale chyba nikt nie chce wziąć na siebie tej odpowiedzialności. Pisałem na forum prawdopodobny wzór ale trzeba by go zastosować i przetestować. Próbujemy?

Ja na kolanie w jednym module zmodyfikowałem sobie (w kodzie, na sztywno, więc to tak bardzo "na plasterek" rozwiązanie do testów) i wnioski wkleiłem tu:
https://github.com/krycha88/GUI-Generic/issues/103
oraz (bo sam problem istnieje w supla-dev z którego GG ciągnie rozwiązanie dimmera)
https://github.com/SUPLA/supla-device/i ... 1371225414

w skrócie: Obecnie jest w kodzie tylko proste przepisywanie wartości (np z chmury/z aplikacji) - z chmury przychodzą parametry

Code: Select all

uint32_t red,                                                     
uint32_t green,                                                     
uint32_t blue,                                                      
uint32_t colorBrightness,                                                      
uint32_t brightness

które mogą mieć od 0 do 1023 wartość.

Więc funkcją map() jest to przemapowywane na zakres 0-255 który jest domyślny dla analogWrite() które ustawia PWM na wyjściu gpio. tutaj: https://github.com/krycha88/GUI-Generic ... ds.cpp#L41

Ja sobie to zmieniłem, zamiast funkcji map() użyłem drabinki :

Code: Select all

#define brightness_level0 0 # procentowa jasnosc, logiczne ze zero to zero, ale dla formalnosci
#define brightness_level1 1 # procentowa jasnosc (wartość pwm) 
#define brightness_level2 2 
#define brightness_level3 3
#define brightness_level4 5
#define brightness_level5 10
#define brightness_level6 20
#define brightness_level7 30
#define brightness_level8 45
#define brightness_level9 60
#define brightness_level10 100

if (brightness<=10) { brightnessAdj=(brightness_level0*255/100);  } # off dla wartość blisko zera
if (brightness>10)$(brightness<=102) { brightnessAdj=(brightness_level1*255/100);  } # przeliczenie z % na 0-255
if (brightness>102)$(brightness<=205) { brightnessAdj=(brightness_leve2*255/100);  } # 
if (brightness>205)$(brightness<=307) { brightnessAdj=(brightness_level3*255/100);  } # 
if (brightness>307)$(brightness<=410) { brightnessAdj=(brightness_level4*255/100);  } # 
if (brightness>410)$(brightness<=512) { brightnessAdj=(brightness_level5*255/100);  } # 
if (brightness>512)$(brightness<=614) { brightnessAdj=(brightness_level6*255/100);  } # 
if (brightness>614)$(brightness<=717) { brightnessAdj=(brightness_level7*255/100);  } # 
if (brightness>717)$(brightness<=819) { brightnessAdj=(brightness_level8*255/100);  } # 
if (brightness>819)$(brightness<=922) { brightnessAdj=(brightness_level9*255/100);  } # 
if (brightness>922) { brightnessAdj=(brightness_level10*255/100);  } # wartości liczb jak 922 to po prostu 1023 podzielone na 10 kroków

Jakby coś takiego miało być wdrożone - to te level by trzeba było przenieść stąd, z kodu, do www konfiguratora gui, i zapamiętywać w parametrach eeprom/params,
no i jeszcze ewentualnie dorobić przełącznik "if !schodkowe_pwm {po staremu;} else {to co tutaj zaproponowałem;} " - by użytkownik miał wybór między dziwnymi zachowaniami po staremu, albo schodkową regulacją, ale za to z optycznie poprawnymi wynikami..

Nie wiem czy jest to lepsze rozwiazanie niż "funkcja" log (najlepiej jak kolega pokazał - przez tabelkę wartości pre-definiowanych, nikt nie będzie logarytmów na esp liczyć w czasie rzeczywistym co raz), ale np:
- dając tu 16 kroków - to umożliwia zrobienie np kilku kroków (jeśli wartości się wpisze takie same dla kilku kolejnych poziomów) i osiągniemy dimmer np 4 poziomowy.
- wpisując wartości w kolejności odwrotnej - mamy odwrócony dimmer - co może mieć sens - np gdy mamy wyjście nie najpierw przez mosfet, a wprost "otwarty kolektor" - i stan cały czas niski (pwm 0) oznacza świecenie na maksa
- można zdefiniować już z poziomu GUI dowolną charaktrystykę, np nie zaczynającą się wcale od zera (pożądane np do PWM sterowania wentylatora - 0, 0, 0, a potem od razu skok do np 40% by raczył zacząć się kręcić a nie tylko piszczeć, i od tego poziomu regulacja do 100%)

[kris.sg]

Ja s SDK non os zrobiłem regulację logarytmiczną dimmera i powiem, że fajnie to działa (jasność narasta liniowo)
Tak to zrobiłem w kodzie:

Code: Select all

int brightness_log[200] = {0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,
						   0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,
						   0,  0,  0,  0,  0,  1,  1,  1,  1,  1,  1,  1,
						   1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  2,
						   2,  2,  2,  2,  2,  2,  2,  2,  2,  2,  2,  3,
						   3,  3,  3,  3,  3,  3,  3,  3,  3,  4,  4,  4,
						   4,  4,  4,  4,  4,  5,  5,  5,  5,  5,  5,  5,
						   6,  6,  6,  6,  6,  7,  7,  7,  7,  7,  7,  8,
						   8,  8,  8,  9,  9,  9,  9, 10, 10, 10, 10, 11,
						  11, 11, 11, 12, 12, 12, 13, 13, 13, 14, 14, 15,
						  15, 15, 16, 16, 16, 17, 17, 18, 18, 19, 19, 20,
						  20, 21, 21, 22, 22, 23, 23, 24, 24, 25, 26, 26,
						  27, 28, 28, 29, 30, 31, 31, 32, 33, 34, 34, 35,
						  36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47,
						  48, 49, 50, 52, 53, 54, 56, 57, 58, 60, 61, 63,
						  64, 66, 67, 69, 70, 72, 74, 75, 77, 79, 81, 83,
						  85, 87, 89, 91, 93, 96, 98, 100};

[YoMan]

Nie wiem czy jest to lepsze rozwiazanie niż "funkcja" log (najlepiej jak kolega pokazał - przez tabelkę wartości pre-definiowanych, nikt nie będzie logarytmów na esp liczyć w czasie rzeczywistym co raz), ale np:

nie wypowiem się co do merytoryki i zastosowanej przez ciebie metody ale nie pisałem nic o funkcji logarytmicznej. Podałem wzór i nie wydaje mi się, żeby proste mnożenie i potęgowanie tak obciążyło esp ale .... mogę się mylić
W kwestii merytorycznej jeżeli Wasze rozwiązanie optycznie działa ok (jest płynne, bez "schodkowania", wizualnie rozjaśnia się równomiernie) to tylko pytanie do @krycha88 jak problematyczna będzie implementacja.