Wynika to również z kompensacji. Po prostu, czasem diody dostaną ciut więcej napięcia i zaczynają źreć prąd, układ stabilizacji próbuje dziobnąć im ten prąd i wtedy mruga. Można to nawet nazwać zjawiskiem "interferencji" czasem jest to nawet "falowe" w sensie, że wpada w dziki rezonans, dokąd się nie uspokoi.
Po prostu, prymitywne przetwornice są prymitywne a klasa diod, klasą diod. Może to być nawet spowodowane nieliniowością samych diod, gdzie każda zachowuje się inaczej (rozbieżność) i wystarczy kilka mV żeby sobie wzięła więcej niż pozostałe. One pracują często parami (nie szeregowo wszystkie) i wtedy też będzie mrugało.
Kup lepsze i po kłopocie.
Ja właśnie kupiłem inne/lepsze. Co ciekawe stare, które mi świeciły 2 lata, zdechły z powodu upalenia jednej z diod. Z 2szt lampek złożyłem jedną, dla zabawy i zobaczymy kiedy padnie. One w ogóle pracują w warunkach krytycznych, gdzie dioda, pracując w "nominalnych" powinna świecić ok 100lat. Cóż, "zmowa producentów lampek" :)
To akurat jest jasne. Nie cytować bzdur, wiedzę czerpać z podręczników i wykładów, nigdy z dziadowskich źródeł typu Wikipedia. Jeśli z Internetu, to WYŁĄCZNIE ze stron uczelni, można tam znaleźć mnóstwo rzetelnej wiedzy.
Dzięki, ale wpadłem napisać że od soboty rano się dzieje! Nie pisałem zbyt pochopnie, bo myślałem że może PV w okolicy zaczęły pracować, ale mamy 5 dzień i nocne napięcie z 226-227V to teraz 231-232V. W ciągu dnia mocno stabilne 226V z rzadkimi i chwilowymi spadkami w okolice 220-221V.
Co prawda załączenie obciążenia po mojej stronie, generuje relatywnie takie same spadki jak wcześniej ale mam nadal wtedy więcej niż 210V, a nie okolice 200V jak poprzednio.
PGE wysłuchało moich próśb*? Już po dwóch tygodniach od zgłoszenia? Otwierać szampana? ;-)
*u nich niestety skrzynka kontaktowa czy zgłoszenie telefoniczne, to jak czarna dziura. Ani potwierdzenia przyjęcia, ani czy się ktoś zainteresował...trzeba trzymać kciuki i patrzeć czy się coś zmienia.
Z tym wszystko bym nie szalał, chyba że wiesz jak:
- da się sięgnąć w wyrażeniu "Warunek wykonania sceny" do stanów historycznych np. odczytać temperaturę 1h temu?
- są warunki jak "temperatura się zmieni", "wzrośnie/spadnie poniżej",...a da się zareagować na zmianę trendu?
- "Wyzwalacz sceny w oparciu o stan kanałów" działa dla czujnika temperatury? Edytor na stronie podpowiada, ale po sparsowaniu "Wyrażenie używa następujących kanałów: 16144." i zmianie temperatury na czujniku, dana scena się nie odpala :-?
- jak skonfiguruje nawet jakiś bardziej złożony warunek wykonania sceny, to nadal tę scenę jakoś trzeba odpalić. Z braku innego wyzwalacza ustawiam "* ** * *", ale to powoduje wykonanie sceny N razy jak tylko warunek zostanie spełniony. A potrzebowałbym aby po pierwszym wykonaniu, warunek się zmienił - chodzi mi o osiągnięcie stanu a la bistabilnego - czekam na jeden warunke...jest! Odpalamy akcję. To teraz czekamy na drugi...Jest! Odpalamy akcję i wracamy do czekania na pierwszy...
Możliwe ale nigdy tego wyrażenia nie potrzebowałem. ZTCW to można nawet korzystać z danych pogodowych definiując datę. Sądzę że jest tam taka funkcja
Oczywiście, sam tego używam.
Oczywiście.
Matko. Ja mam tak poustawiane zależności, że chyba byś nie ogarnął tego naraz :D
Praktycznie zbudowałem sobie autonomiczny "system". Przykładowo:
Przychodzę na działkę i otwieram drzwi altany i szopki z narzędziami. W zależności które drzwi otworzę pierwsze to wykona się scena a lub b.
Podobnie jak wychodzę, system dokonuje sprawdzenia poprawności wszystkich urządzeń i jeśli jest OK, to mam powiadomienie że jest OK. jeśli nie, mam powiadomienie że coś nie domknąłem/wyłączyłem/włączyłem.
U mnie głównym "czujnikiem" jest woltomierz akumulatora i w zależności od napięcia włączają się i wyłączają, pompy, kamery, siłowniki. Nie mam tam prądu z energetyki więc muszę pilnować drenażu akumulatora i temperatura, która włącza i wyłącza siłowniki, pompy itd.
Jest możliwość pobierania danych i ich parsowania przez getUrl. A dane historyczne można dzięki temu pobrać przez API supli np.
formatting link
{channel}/logs... Analogicznie można dane pogodowe/cokolwiek skoro można wykonać zapytanie GET. Od biedy na serwerze może być logika, a dane przyjdą w parametrach przekazanych w zapytaniu...okrężna droga, ale w ten sposób można faktycznie powiedzieć że "niemal wszystko da się zrobić" ;-)
Ok, teraz już wiem że to powyżej spełnia "Wyzwalacz sceny w oparciu o stan kanałów" - tylko to nie jest czytelne tak od razu więc wyjaśniam że podaje się tam warunek np.
{{(state({zasilanie_CO}).temperature > (state({powrót_do_pompy}).temperature + 2)) and not (state({zasilanie_CO}).temperature < (state({powrót_do_pompy}).temperature - 1))}}
i scena wywoła się raz za każdym razem kiedy cały warunek zmieni stan między spełniony/niespełniony. W tym przypadku wykryje rozpoczęcie oraz zakończenie procesu ogrzewania CO z pominięciem defrostów. Nice! :-)
Oby tylko w takim razie nie zaczął mieć kaprysów, bo inaczej Cię nie wpuści do tej altany :-D
Możesz równie dobrze odpalić sobie sekwencję czasową (dodatkowa scena), że co 10* min sprawdzany jest stan i jeśli warunek jest spełniony to się odpala wtedy nie ma możliwości "pominięcia" zmiany stanu. Takie zabezpieczenie wyrażenia.
Generalnie po kliknieciu w scenach "?" masz opisy jak definiować skrypty a jeśli masz większy problem to na forum są autorzy i chętnie odpowiadają...lub są już opisane takie zdarzenia. Wystarczy poczytać
Domyślnie najniższą wartością jest 10min ale można skorzystać z
formatting link
i tam możesz sobie ustalić co minutę.
Do altany mam klucz a nie zamek szyfrowy...i alarm "dla mnie" jest w telefonie. Będąc na działce, praktycznie nie wyłączam tego, przy okazji mam test, że wszystko działa poprawnie.
Na razie zadałem pytanie - jak się mnie wydaje - o rzecz dość prostą: Jak wykonać zapytanie o dane historyczne? Uzyskać trend dla czujnika? Wykonać akcję gdy temperatura rośnie lub spada?
formatting link
?p=164582#p164582 Oczywiście chodzi o to, jak to zrobić "z paczki". Nawet zaoferowałem czteropak dla tego, kto wskaże jak :-)
Ale o co chodzi? Ustawić że gdy wzrośnie powyżej X - to grzeje, a gdy spadnie - to nie grzeje? Nie do końca. Urządzenie grzewcze posiada zawór trójdrogowy, jego przełączenie wyzwoli ten warunek a żadnego grzania jednak nie będzie.
Tak, ale wymaga to uwierzytelnienia za pomocą nagłówka - czego SUPLA SCRIPTS "getUrl" najwyraźniej nie wspiera (z kodu na githubie tak to dla mnie wygląda).
Tutaj już się udało, dzięki.
Korzystasz z powiadomień w oficjalnej aplikacji SUPLA czy z Pushover? Ja próbuje póki co oba i różnie bywa - tzn. część notyfikacji dochodzi, a część nie. Nie chce marudzić, ale w eWeLink to po prostu działa. Ale taki minor póki co, zostawmy ;-)
Tak przeczytałem. Też się na razie bawię z suplą - jak to często sam podkreślasz.
Póki co pozytywnie oceniam kontakt z tą platformą. Ma niepodważalne zalety względem np. oryginalnego sonoff-a. Ale sprowadzają się one IMHO przede wszystkim do obszarów gdzie trzeba zrobić coś nietypowego: postawić lokalny serwer, dołączyć do systemu nietypowe urządzenie, spersonalizować swój system. Supla wydaje się koncentrować na większej funkcjonalności, ale kosztem wyższego progu wejścia.
To nie zarzuty z mojej strony. Staram się opisać czym kierować przy wyborze platformy. I wydaje mi się, że przede wszystkim trzeba określić "co się chce osiągnąć", a dopiero potem wybierać.
PS. Przy okazji odkryłem zdaje się SQL-Injection przy zapisie warunku, co mam nadzieje dotrze do autora.
Albo to że w odpowiedzi nie da się użyć znaków unicode. Funkcje nl2br czy raw, także nie zwracają poprawnego wyniku - tutaj nie wiem czy to nie jest zamierzone. Ale hej! Jest napisane że można używać tego Twiga, to używam a tu nie działa.
To są sceny podpięte pod stan kontaktronu drzwi. W momencie, kiedy kamery nie pracują, bo jest za niskie napięcie i zostały wyłączone (noc) to otwarcie drzwi powoduje uruchomienie kamer i wysłanie powiadomienia.
Tutaj mam czujkę ruchu, która włącza kamery i wysyła powiadomienie.
Ten układ ma za zadanie reagować na temperaturę wody i otoczenia. Kiedy temperatura wody jest wyższa niż otoczenia to klapa oczka (styropian w ramie) się zamyka. Ma to na celu minimalizowanie parowania wody i ograniczania spadku temperatury (mam tam rybki).
{{not state(1234).on and state(1235).connected and state(1236).temperature < state(1237).temperature}}
To reakcja na stan akumulatora (mam wiele takich scen, żeby ograniczyć pobór prądu, kiedy akumulator nie jest ładowany).
Wiatrak ma pomiar napięcia i zależności. Jeśli jest ładowanie z PV to nie pozwalam wiatrakowi ładować. Kiedy zawieje wiatr i napięcie osiągnie próg, włącza się hamulec elektromagnetyczny i wiatrak się zatrzymuje.
Ograniczam tym samym zużywanie się łożysk wiatraka. Czasem jednak włączam mu "kotwicę" to siłownik, który całkowicie unieruchamia wiatrak. Używam kotwicy, kiedy jest huragan i wtedy wiatrak nie pracuje, bo bym go zbierał na Marsie :)
A to już termometr w domu, do kontroli pieca węglowego/zasypowego. Kiedy temperatura osiąga 40C to mam powiadomienie, że jest OK i w drugą stronę, kiedy przygasa i trzeba iść dołożyć. To też pomaga bo zdarzało się, że zgasło i trzeba było rozpalać na nowo.
Przecież to można rozwiązać scenami i niepotrzebna jest tutaj wiedza "historyczna".
To co ja mam do klapy oczka działa właśnie na porównaniu dwóch termometrów:
{{not state(1234).on and state(1235).connected and state(1236).temperature < state(1237).temperature}}
Ale w domu z piecem mam zrobione to na jednym termometrze ale dwa różne działania, przy wzroście temperatury i przy opadaniu.
Po prostu, scena 1 uruchamia się przy wzroście temperatury '>' a scena 2 przy opadaniu '<'.
Też mam oba typy powiadomień ale u mnie działa zawsze. Warunkiem jest jednak dość dobry zasięg Internetu.
Niekoniecznie. Ja używam tego z obcym cloudem, czyli jak sonoff ale mam dodatkowe "bajery" których sonoff nie ma (właśnie skrypty) no i oczywiście możliwość "zarażania" Suplą wszelakich ESP.
Heh, bo sobie źle założyłeś :D Nie można tam używać "własnych" wyrażeń. Po postawieniu nawiasu klamrowego w okienku, rozwija Ci się "menu" opcji z dostępnych urządzeń. Dalej jedynie możesz to łączyć czy udziwniać, łączyć, stosując "and" , "or" + inne dopiski do wyrażeń czyli np wyłączanie czegoś o zmierzchu:
{{state(12345).on and state(12345).connected and time('-5 minutes') > sunsetTime()}}
{{state(12345).temperature > 42}} to kiedy rośnie {{state(12345).temperature < 41}} to kiedy spada
Liczby sobie sam podstawisz w zależności progu zadziałania. Ja mam jeszcze dopisane opóźnienie (600sek) tylko dlatego, żeby mi nie "plimplało" co sekundę w momencie przechodzenia przez próg, co się zdarzało, że w danej sekundzie rosło, lub malało. Tutaj też jest logika, że jeśli scena się odpaliła i trwa, to nie wykona się ponownie przez 600sek.
No to wisisz 2 or 8pak, bo działa ale nie potrzeba sprawdzać historii :]
Możliwe że czegoś nie widzę, ale ja nie mam progu. Są trzy czujniki: zasilanie CO, zasilanie CWU i wspólnego powrotu (zawór trójdrożny).
Przykładowy scenariusz A: Rozpoczyna się grzanie CO, temperatura na zasilaniu zaczyna rosnąć, wytwarza się różnica w przedziale 3-8C po czym zaczyna rosnąć powrót. Przy czym powrót rozpoczął np. przy 22C a zakończy przy 25C. Aktualny warunek jaki mam, to: {{state(zasilanie).temperature > (state(powrot).temperature + 2)}}. Jak byś chciał zapisać to za pomocą progu? Podpowiem, że w przypadku -15C na zewnątrz start będzie przy 25C, a zakończenie przy 29C.
Przykładowy scenariusz B: Rozpoczyna się grzanie CWU, temperatura początkowa może być 20C a końcowa 50C (zasilania). Tutaj podobnie, różnica w przedziale 3-8C. Woda osiąga zakładaną temperaturę, różnica zasilania i powrotu spada poniżej 2C (tak samo w przypadku CO, możemy założyć że zawsze tym warunkiem złapiemy "zakończenie grzania"). I teraz clue. Temperatura w rurze na zasilaniu jest zbliżona do temperatury dopiero co zagrzanej wody 45C. Urządzenie przechodzi w grzanie CO, przełącza zawór trójdrożny, załącza się grzanie, pompa obiegowa na tym układzie, temperatura na powrocie (wspólnym) spada do temperatury powrotu z CO czyli np. 23C. Różnica między zasilaniem CWU, a powrotem jest > 2C - warunek spełniony, dostaje powiadomienie że rozpoczęto ponownie grzanie CWU - co nie jest prawdą.
Widzisz jak rozwiązać te przypadki za pomocą progu?
Ja dotrzymam słowa, ale musisz mi jeszcze trochę pomóc.
PS. Dlaczego 2 lub 8? Twojego piwa nie ma w zgrzewkach po 4? Zawsze może być 2x2 ;-)
Okazuje się że gdy w warunku jest więcej niż jeden kanał z tego samego urządzenia, to "update" mają "w tym samym czasie" i gdy zmieni się wartości więcej niż jednego z tych kanałów w wysłanej aktualizacji, to scena wykonuje się kilkukrotnie w tej samej sekundzie.
W moim przypadku dostaję np. trzy notyfikacje na raz.
Do "Cloud" supli także zgłosiłem, że skoro udostępniają reakcję "Na zmianę wartości" to wartość aktualną muszą porównywać z wartością poprzednią - to skoro to mają, to mogli by udostępnić możliwość wskazania czy reakcja ma nastąpić na "zmianę", "spadek" czy "wzrost wartości".
formatting link
Ee, skoro sam Frucz pokazuje w przykładach żeby korzystać z całego Twig...
formatting link
Po prostu przyszedłem z "zewnątrz" i zacząłem używać tych funkcjonalności w sposób "oczywisty" dla mnie. A tu niespodzianka "tu i tam" coś wybucha ;-)
W dniu 03.11.2023 o 10:22, Mateusz Bogusz pisze: [...]
To nie jest błąd. Po prostu nie ogarnąłeś warunków (odpisałem na forum)
I bardzo dobrze. Ile chcesz razy dostać w ciągu sekundy?
Wartość poprzednia jest wartością logiczną. Skoro teraz jest 3 i wzrasta, to znaczy że było 2 i odwrotnie. Nie łapiesz chyba tej logiki.
Inna sprawa, skąd weźmiesz marker czasowy, jeśli zmiana parametru była 3 dni temu? Będziesz szukał wstecz co sekundę?
FRĄCZ
Nic nie wybucha, bo znów sobie dałeś złe założenia. Twig jako język traktuj jako język, natomiast konkretne zmienne nie mogą być "z dupy" i powinieneś je traktować jak posługiwanie się kluczem do zamka. Masz 100 kluczy do 100 zamków, każdy inny. Jeśli sobie doszlifujesz randomowo swój kluczyk, może nie pasować do żadnego zamka. Twig = Yale to tak w rozumieniu jaki to "język/system".
To może w końcu napisz, co chcesz uzyskać? Będzie prościej w sensie co i kiedy ma się włączyć lub wyłączyć.
j/w Tak w ogóle dziwię się, że chcesz bazować na wskazaniach z różnych punktów a nie na logicznych (slawe) wskazaniach. Chodzi o temperaturę na powrocie. Ona zawsze jest niższa niż na wyjściu i zawsze jest wynikową systemu. Temperatura "Master" czyli na wyjściu jest tutaj kluczowa i od niej ustalałbym progi (tak mam u siebie) czyli termometr "na rurze"...ale można to sprząc z pompą, zaworem, cokolwiek.
Zapewne zawsze dochodzi do przekroczenia progu temp Max, co uznałbym za próg "koniec grzania" oczywiście z jakimś tam wyliczeniem (buforem czasowym) na zmiany dynamiczne.
Spox
Bo możesz stwierdzić, że pomogłem Ci połowicznie albo stwierdzić że szedłeś złą drogą i wtedy zarobię 2x4pak rozwiązując Twój problem i wskazując właściwą drogę na dalsze zabawy :D
Nie zrozumiałem Cię. Dostaję trzy, bo mam trzy kanały wewnątrz warunku wyzwalacza. Jakbym miał dziesięć, to pewnie bym i dziesięć notyfikacji dostał. IMO Ty piszesz o limicie w czasie, a ja o tym że w ogóle tam nie powinno być więcej niż jedna notyfikacja na zmianę stany (wyzwalacza).
Piszesz o tym samym co ja? Ja odnoszę się do reakcji zatytułowanej "Kiedy zmieni się temperatura" -
formatting link
Zaznaczenie tego powoduje wyzwolenie reakcji za każdy razem kiedy zmieni się wartość na czujniku np. z 20.25°C na 20.56°C. O jakiej wartości logicznej Ty piszesz? Jak dla mnie to muszą mieć zapisaną poprzednią wartość żeby sprawdzić czy A != B.
Ja tam zapytałem o wartość poprzednią - obojętne jak odległa w przeszłości by ona nie była (np. ESP nie miało zasilania przez tydzień)
- przecież IMO oni tak samo to porównują dla reakcji "Kiedy zmieni się temperatura".
Jest pole "Odpowiedź" - "Odpowiedź jest widoczna przy wywoływaniu sceny za pomocą jej adresu URL." - z tekstem zwracanym przy wywołaniu sceny.
Jest do tego film -
formatting link
- jak zrobić "widget" na pulpicie telefonu - po czym zamiast widgetu, to pokazane jest jak zrobić skrót który po naciśnięciu pokazuje tekst w okienku. Można lepiej i użyć np. widgetify lub widgetery,...aby ten tekst się od razu wyświetlał we wskazanym prostokącie - tak jak działają prawdziwe widgety w androidzie. Tylko wiesz co? Do pełni szczęścia brakuje możliwości wstawienia entera w tym tekście odpowiedzi. A właściwie to kodu HTML. I to nie jest coś co trzeba dopisać, a IMO ta funkcjonalność jest w konfiguracji pola "Odpowiedź" po prostu wyłączona
- intencjonalnie czy nie - dlatego zapytałem na forum.
Ktoś inny nawet się pytał jak wprowadzić "spację" -
formatting link
Nie chce być uszczypliwy, ale wielokrotnie czytałem wcześniej tutaj na grupie
I jak spróbowałem, to się okazuje że "wszystko" ale tak po trochu, pod warunkiem że tego i tamtego to nie chcesz, jak dostajesz 10 powiadomień w tej samej sekundzie z jednej sceny to dlatego że "nie ogarniasz" i "się nie znasz" albo "sobie źle założyłeś" ;-)
A ja póki co chce tylko wiedzieć czy temperatura na termometrze rośnie czy spada :-D
ALE żeby oddać uczciwości, to ZGRUBNIE tę informację dostaję. Po prostu sprawdzam czy na zasilaniu jest o próg (2C) temperatura większa niż na powrocie i to realizuję w wyzwalaczu - więc działa analogicznie jak termostat.
Twój pomysł ze scenami też przemyślałem i na inny sposób, też przybliża dokładniejszą odpowiedź. Jak zrozumiałem, mógłbym np.
W scenie A zareagować na warunek jak wyżej, po czym dodać opóźnienie na wykonaniu np. 1 min i wyzwolić scenę B w której sprawdzał bym z kolei czy przekroczyło próg 3C - w ten sposób bym wiedział że faktycznie różnica rośnie ale:
- wprowadzam opóźnienie w wywołaniu faktycznej akcji
- dodatkowo komplikuje, bo trzeba żonglować tymi progami i czasami aby dobrać je "pod siebie"
- trzeba by dołożyć do warunku trzecią temperaturę (idealnie stałą) aby mieć punkt odniesienia, żeby nie było tak że przez spadek temperatury na powrocie, złudnie wyda się że temperatura zasilania rośnie
Pierwsza i jedyna potrzeba z początku, to było informowanie o przełączeniu zaworu trójdrożnego. I to pi razy oko jako informacja dla mnie - otrzymuje.
A teraz - tak jak Ty - bawię się mając oczujnikowaną całą maszynownie i próbuję skonfigurować powiadomienie o pracy urządzenia grzewczego - oddzielnie dla CO i CWU. Pisząc serio - kilkukrotnie czytałem tutaj na grupie duże pochwały w kierunku Supli, to teraz gdy ją mam to staram się sprawdzić co "pożytecznego" mogę z niej wycisnąć.
Łatwiej jest może "dobrać" warunki gdy się widzi dane, toteż podrzucam ostatnie 24h -
formatting link
Mam też dane dla temperatury podłogi jak i zbiornika CWU -
formatting link
i może dołączenie ich do warunków pomoże.
Z ciekawostek, za pomocą czujnika temperatury można zobaczyć jak pracuje pompa w hydroforze ;-)
formatting link
Albo że mój zamrażalnik włącza się 45 razy w ciągu doby -
formatting link
Za powrót myślałem o temperaturze podłogi (ta jak napisałem wyżej jest zdecydowanie stabilniejsza), ale ja tu widzę co najmniej jeden problem i jedno coś za coś.
To pierwsze, to że w przypadku defrostu jak widać na wykresie, temperatura zasilania może być niższa nawet niż temperatura powrotu podłogi.
Drugi to czas reakcji. Szukam rozwiązania żeby dostać powiadomienie w ciągu ~minuty(?) od rozpoczęcia działania grzania. Temperatura na podłodze (powrót z niej) - jak widać na wykresie, to 1C na ~30min i to na dzisiejsze warunki i z początku grzania. Widać że potem moment się wypłaszcza.
Ale max czego, zasilania? To jest różne w zależności od warunków pogodowych i ustawionej oczekiwanej temperatury na powrocie. Ta z kolei wynika z krzywej pogodowej. O to ostatnie w supli, nawet nie pytam ;-)
Ja nie mówię że się nie da. Supla stawia na wszechstronność i możliwości integracji. Przypuszczam że metodą prób i błędów w iluś tam scenach i jakiś zależnościach pewnie bym dobrał konfigurację taką, żeby wyeliminować wszystkie false wyzwolenia.
Można by też pewnie napisać kilkadziesiąt linii kodu i wrzucić na jakiś kolejny ESP co by pobierał te dane (niech będzie nawet lokalnie), przetwarzał je lokalnie, a do supli cloud wysyłał na kilku wirtualnych kanałach już przetworzone stany - grzeje 0/1.
No ale dla siebie w liczbie sztuk jedna takie wygibasy? ;-)
Podsunąłeś dopisanie warunku wyzwalacza do warunku wykonania. Zamiast jeden sceny zrobiłem dwie i mam teraz powiadomienia Start grzania i Stop grzania. Już w połowie drogi ;-)
Teraz to mnie te notyfikacje najbardziej frapują, bo dla mnie to wygląda jak ewidentny błąd (nieobsłużony przypadek graniczny) i bez interwencji autora scripts czy tam kogoś od supli, raczej tego nie obejdę - a raczej nie chce się skupiać na czymś na czym nie ja powinienem.
Ewentualnie w supla cloud jakby dodali obsługę "trendu" (jak poprosiłem na forum), to myślę że wtedy aktualne potrzeby rozwiązałaby podstawowa supla.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.