Witajcie.
Proszę o podpowiedź
Jestem w trakcie rozszerzania sterowania ogrzewaniem podłogowym i napotkałem mały problem.
Parter domu zrealizowany został za pomocą rozszerzenia :
https://www.reichelt.com/de/en/raspberr ... 53984.html
Czujniki ds18b20 przy okazji innych elementów sterowania oświetleniem itp, oraz 3 sztuki podłączone pod gpio4.
do tej pory wszystko śmiga aż miło.
Postanowiłem podłączyć również górę pod ten sam raspberry:
2 skrętki - jedna do czujników ds18b20, druga do starowania przekaźnikami.
Podłączyłem 2 czujniki i jest ok, natomiast trzeci wywala całość i nie mam żadnych odpowiedzi w /sys/bus/w1/devices lub pojawiają się zupełnie dziwne wartości.
Czy istnieje maksymalna liczba podłączonych czujników ? Próbowałem dać dodatkowe zasilanie 3,3v na piętrze, ale nic to nie daje.
Przekaźniki:
Dolna listwa wykorzystuje GPIO 5,6,13,16,19,20,21,26 - Działa jak należy
Na piętrze postanowiłem zastosować zwykłą płytkę x 8 przekaźnikami:
Z zewnętrznym zasilaniem i bez działa w ograniczonym stopniu.
GPIO 2,3,17,27 Działają poprawnie.
Natomiast każdy inny, którego próbowałem niestety nie zmienia stanu przekaźnika, nawet stanu w aplikacji.
Podsumowując jestem w stanie uruchomić maksymalnie 12 przekaźników i 5 Ds18b20, a to troszkę mało.
Nie chciałem angażować dodatkowego raspberry tylko do sterowania piętra.
Dziękuję za każdą pomoc.
raspberry-dev 3b+ przekaźniki i ds18b20
Problem częściowo rozwiązany.
Zmieniłem wspólny pull-up z 4,7k na 3,3k i ds'y zaczęły się pojawiać.
Pozostaję z problemem wysterowania przekaźników.
Dodałem 8 kanałów i wszystkie mam je widoczne w cloud.
Co może być przyczyną działania pierwszych 4 - zmiana stanu w aplikacji i cloud działa poprawnie,
pozostałe 4 nie reagują na żadną z prób załączenia.
Zmieniłem wspólny pull-up z 4,7k na 3,3k i ds'y zaczęły się pojawiać.
Pozostaję z problemem wysterowania przekaźników.
Dodałem 8 kanałów i wszystkie mam je widoczne w cloud.
Co może być przyczyną działania pierwszych 4 - zmiana stanu w aplikacji i cloud działa poprawnie,
pozostałe 4 nie reagują na żadną z prób załączenia.
Niestety do chwili obecnej nie znalazłem rozwiązania mojego problemu i jestem już prawie pewien że problem może być po stronie supli nie sprzętowej.
W czasie poszukiwania rozwiązań trafiłem na kilka przydatnych komend, które może ułatwią życie innym.
gipo readall - wyświetla informacje na temat dostępnych pinów wraz z ich nazwą, numeracją fizyczną lokalizacją oraz trybem w jaki jest ustawiony in/out
ls /sys/class/gpio - wyświetli dostępne i obsługiwane przez jądro piny.
echo 17 > /sys/class/gpio/export - pozwala dodać kolejny port (w tym przypadku gpio17 )
cat /sys/class/gpio/gpio17/direction - wyświetli tryb w jaki został ustawiony dany gpio in/out ( w przykłądzie gpio17, domyślnie in)
raspi-gipo set 17 op - ustawia tryb output dla gpio17
i na koniec :
echo 1 > /sys/class/gpio/gpio17/value - ustawi stan wysoki dla gpio17 ( analogicznie wartosć 0 zmieni na stan niski )
Zapewne całość załatwia sktypt supla ale musiałem sprawdzić każdą możliwość.
Na tym etapie przy ręcznej zmianie stanu moje przekaźniki działają poprawnie.
Teraz już chyba pozostaje mi supla cloud i dev do przeszukania.
Czy ktoś może podpowiedzieć co dalej ?
W czasie poszukiwania rozwiązań trafiłem na kilka przydatnych komend, które może ułatwią życie innym.
gipo readall - wyświetla informacje na temat dostępnych pinów wraz z ich nazwą, numeracją fizyczną lokalizacją oraz trybem w jaki jest ustawiony in/out
ls /sys/class/gpio - wyświetli dostępne i obsługiwane przez jądro piny.
echo 17 > /sys/class/gpio/export - pozwala dodać kolejny port (w tym przypadku gpio17 )
cat /sys/class/gpio/gpio17/direction - wyświetli tryb w jaki został ustawiony dany gpio in/out ( w przykłądzie gpio17, domyślnie in)
raspi-gipo set 17 op - ustawia tryb output dla gpio17
i na koniec :
echo 1 > /sys/class/gpio/gpio17/value - ustawi stan wysoki dla gpio17 ( analogicznie wartosć 0 zmieni na stan niski )
Zapewne całość załatwia sktypt supla ale musiałem sprawdzić każdą możliwość.
Na tym etapie przy ręcznej zmianie stanu moje przekaźniki działają poprawnie.
Teraz już chyba pozostaje mi supla cloud i dev do przeszukania.
Czy ktoś może podpowiedzieć co dalej ?
supla-dev wewnętrznie inicjuje porty wykonując operacje, które są analogiczne do tych co podałes wyżej. Wyjątkiem są DS-y. Tutaj wykrywane są przez skrypt w init.d
https://github.com/SUPLA/raspberry/blob ... la-dev#L34
Sprawdź czy po uruchomieniu supla-dev pojawiły Ci się odpowiednie porty w
/sys/class/gpio/
https://github.com/SUPLA/raspberry/blob ... la-dev#L34
Sprawdź czy po uruchomieniu supla-dev pojawiły Ci się odpowiednie porty w
/sys/class/gpio/
Ewentualnego błędu szukałbym raczej w sofcie na rpi. Czyli supla-dev.
Po stronie clouda/serwera to raczej nie możliwe, aby coś takiego miałoby nie działać, bo dużo ludzi korzysta z innych urządzeń i nie ma takich problemów.
Samo raspberry ma raczej wąskie grono użytkowników w Supli. Ludzie częściej na tym serwer stawiają niż robią elementy wykonawcze
Po stronie clouda/serwera to raczej nie możliwe, aby coś takiego miałoby nie działać, bo dużo ludzi korzysta z innych urządzeń i nie ma takich problemów.
Samo raspberry ma raczej wąskie grono użytkowników w Supli. Ludzie częściej na tym serwer stawiają niż robią elementy wykonawcze
Widzimy się na Supla Offline Party vol. 2
Usunąłem wszystkie porty i restart supla-dev.pzygmunt pisze: ↑wt lut 02, 2021 11:20 am supla-dev wewnętrznie inicjuje porty wykonując operacje, które są analogiczne do tych co podałes wyżej. Wyjątkiem są DS-y. Tutaj wykrywane są przez skrypt w init.d
https://github.com/SUPLA/raspberry/blob ... la-dev#L34
Sprawdź czy po uruchomieniu supla-dev pojawiły Ci się odpowiednie porty w
/sys/class/gpio/
Wszystkie zadeklarowanie porty w supla.cfg zostały zainicjowane.
Ponowne usunięcie i restart maliny - efekt ten sam - powinno działać.
Coś musi się "dziać" po przekroczeniu 12 kanałów ( przekaźników),
Mogę dowolnie manipulować gpio na granicy CHANNEL_11 / CHANNEL_12.
Efekt jest taki że CHANNEL_11 działa bez zastrzerzeń a 12 już nie mogę zmienić stanu.