Czujnik otwarcia drzwi (RPi)

Biedronek
Posty: 18
Rejestracja: śr lut 24, 2016 1:19 pm

Zabralem sie za testowanie kontaktronow w oknach - czy SUPLA_CHANNELTYPE_SENSORNO jest juz obslugiwany? Mam urzadzenie w aplikacji ale nie jestem w stanie nic z niego wyciagnac - czy tam sa jakies kolory lub ikonka?

Innymi slowy: jak wyglada normalnie konfiguracja tego? (co prawda robie to przez MCP23008 ale "zwykla" sciezka mnie takze interesuje). Czy niezbedne jest dodanie do kodu channelio_raise_valuechanged() czy inny mechanizm obsluguje to - potrzebe bedzie mi dodanie TChannelGpioPortValue to rejestracji zdarzen?

Troche chaotyczne te pytania, ale probuje sie odnalezc...
Awatar użytkownika
pzygmunt
Posty: 18280
Rejestracja: wt sty 19, 2016 9:26 am
Lokalizacja: Paczków
Kontakt:

Czujnik otwarcia jest już zaimplementowany. Może być powiązany z kanałem sterującym lub nie (na cloud.supla.org). Jeżeli pracuje "luzem" to w aplikacji jest ikona którą nie możemy niczym sterować, a która tylko informuje nas o tym czy coś jest otwarte/zamknięte. Możemy też czujnik powiązać z innym kanałem, który odpowiada za sterowanie i wtedy z dwóch ikon w aplikacji robi się jedna, którą możemy otwierać/zamykać, a ikona określa czy coś jest otwarte czy zamknięte.

Zmiana stanu portu powinna być sygnalizowana poprzez wywołanie funkcji
srpc_ds_async_channel_value_changed

to dotyczy czujników jak i "kanałów" wykonawczych ponieważ może być tak, że stan portu sterującego został przełączony manualnie i serwer powinien być o tym też poinformowany.

W przypadku supla-dev można (w większości przypadków - powinno) się posłużyć funkcją channelio_raise_valuechange
Biedronek
Posty: 18
Rejestracja: śr lut 24, 2016 1:19 pm

Jest postep, ikonka otwartych drzwi rzeczywiscie sie zmienia :-) Dziala mi tez listwa przekaznikow jak i kontaktrony podlaczone do ekspandera gpio. W zwiazaku z tym odswiezylem pull-request'a na githubie i ponawiam prosbe o review:
- na razie pozostalbym przy obsludze pojedynczego ekspandera, jak polutuje cos to bede mogl przetestowac kilka na wspolnej szynie i2C
- co do ifdefow, to sprawa wyglada tak, ze nie jest dla mnie problemem zrobic kolejnego commita z nimi, ale spowoduje to, ze kod zostanie poszatkowany w wielu miejscach, a przez to trudny w zarzadzaniu (np. dla rozszerzenie ifdefow dla GPIO, MCP23008, W1, DHT22, ...). Mysle, ze runtime'owa decyzja o wykonaniu kodu na urzadzeniu typu RPi bedzie niezauwazalna. Potencjalnie gorzej z wiringPi, ktora jest zewnetrzna biblioteka, ale to tez problem latwy do rozwiazania (snapshoty wersji). Ewentualnie moge napisac natywna mini biblioteke do i2c...
- nie znalazlem opcji do budowy z __SINGLE_THREAD, wiec przetestowalem z recznie dodana flaga i dziala

Obecnie moja konfiguracja wyglada tak:
[CHANNEL_0]
type=RELAYG5LA1A
driver=mcp23008
mcp_reset=4
mcp_addr=0x20
mcp_gpio_port=7
mcp_gpio_dir=0
mcp_gpio_val=1

[CHANNEL_1]
type=RELAYG5LA1A
driver=mcp23008
mcp_reset=4
mcp_addr=0x20
mcp_gpio_port=5
mcp_gpio_dir=0
mcp_gpio_val=1

[CHANNEL_2]
type=SENSORNO
driver=mcp23008
mcp_reset=4
mcp_addr=0x20
mcp_gpio_port=0
mcp_gpio_dir=1
mcp_gpio_val=1

Przy okazji kilka pytan:
1. czy jest mozliwosc ustawienia SENSORNC na serwerze jako inna funkcja? Zawsze moge zastosowac odwrocowna logike na urzadzeniu (dodatkowa opcja do konfiguracji), ale nie wiem czy to eleganckie rozwiazanie. Mam konkatrony zwierajace obwod przy wbudowanym pull-up'ie na gpio i dla mnie zamkniete okno = stani niski na wejsciu.
2. chcialbym zamontowac pilotazowa wersje urzadzenia do centralki, ale efekt 100% zuzycia rdzenia jest dla mnie nie do przyjecia. Przegladalem liste kanalow, ale nie bardzo jestem w stanie znalezc wrazliwy punkt. Chetnie sie tym zajme, ale poprosze o jakas jeszcze podpowiedz, ja nie widze problemu z kanalami.
3. mam kilkanascie kontaktronow w oknach plus kilkanascie sterowalnych obwodow - od czego powinienem (tak w skrocie) zaczac, zeby zmienic wyglad ikon w aplikacji na andorida (np. zmniejszyc wysokosc) albo zrobic widok w postaci matrycy zielono-bialych kwadracikow? W obecnym stanie to byloby kilka ekranow przewijania.
Awatar użytkownika
pzygmunt
Posty: 18280
Rejestracja: wt sty 19, 2016 9:26 am
Lokalizacja: Paczków
Kontakt:

Wrzuciłem poprawkę na github-a.
Rozwiązuje ona problem "obserwowania" pustej listy co zjada 100% cpu.
W Twojej implementacji MCP - obserwujesz porty co interwał, co nawet ze sleep-em zjada minimalnie procek.
(Nie mam póki co pomysłu jak to zrobić inaczej dlatego tak póki co musi zostać)
Jako, że standardowe GPIO w linuxie widoczne jest jako plik to można czekać na zmiany przy użyciu select-a (eh_wait) dzięki
temu pętla jest zatrzymana, aż do wystąpienia zmiany stanu.
eh_wait też się przydaje przy oczekiwaniu na dane tak aby co chwilę nie sprawdzać socketów.
Inaczej przy dużej liczbie połączeń obciążenie procka radykalnie by rosło.
W przypadku gdy nie używasz standardowych gpio to eh_wait nie ma na co czekać i mamy pętlę
bez żadnego sleep-a co skutkuje 100% CPU. Teraz to jest rozwiązane.

Odnośnie ifdef-a. Bardziej chodzi o możliwość kompilacji na platformach gdzie nie ma MCP.

1. Myślę, że lepiej jak będzie to po stronie urządzenia ponieważ to wiąże się ze sprzętem tak więc zmiana w cloudzie z NC na NO i odwrotnie tylko by mogła popsuć sprawę. Trzeba dodać po prostu

#define SUPLA_CHANNELTYPE_SENSORNC 1010

co właśnie robię przy okazji dodawania:
#define SUPLA_CHANNELTYPE_CALLBUTTON 1500
#define SUPLA_CHANNELTYPE_DHT11 3010
#define SUPLA_CHANNELTYPE_DHT22 3020
#define SUPLA_CHANNELTYPE_AM2302 3030
#define SUPLA_CHANNELTYPE_DIMMER 4000
#define SUPLA_CHANNELTYPE_RGBLED 4010
#define SUPLA_CHANNELTYPE_DIMMERANDRGBLED 4020

2. To jest już poprawione. Pobierz poprawkę. Scal ją ze swoją wersją i wrzuć nowego pull request-a to połącze do z głównym repozytorium.
3. Możesz to podzielić póki co lokalizacjami, ale to trzeba będzie przedyskutować z Mateuszem, ponieważ to on odpowiedzialny jest za wygląd i układ UI.
Biedronek
Posty: 18
Rejestracja: śr lut 24, 2016 1:19 pm

Dziekuje za poprawke!

Ja obecnie rzeczywiscie obserwuje w trybie polling'u. Jednak MCP ma opcje ustawienia swoich gpio w tryb interrupt-on-change, i dzieki temu transmisja po i2c realizowana bedzie jedynie w przypadku zaistnienia zdarzenia. Kiedys to recznie w rejestrach ekspandera konfigurowalem, wiriingPi pewnie tez bedzie miala takie cos. Wbudowane gpio w RPi raczej tez potrafi obsluzyc przerwania, a wtedy juz opcja select().

ifdef - ok, chodzi po prostu zeby sie kompilowalo.

ad 1. rozumiem, ze tworze dodatkowy typ kanalu i w nim uzywam odwroconej logiki.
ad 2. wieczorem sie zrebasuje
ad 3. jasne, sprobuje to przekonfigurowac.
Awatar użytkownika
pzygmunt
Posty: 18280
Rejestracja: wt sty 19, 2016 9:26 am
Lokalizacja: Paczków
Kontakt:

Dokładnie tak. Będzie nowy typ kanału i tam już będzie inna logika.
Biedronek
Posty: 18
Rejestracja: śr lut 24, 2016 1:19 pm

Zminilem logike ale pojawil sie problem. Typ kanalu _SENSORNC nie jest wspierany przez serwer. W zwiazku ze nie moge mu nadac funkcji co z kolei ma swoj efekt w aplikacji na smartfonie - nie prezentuje czujnika. Do testowania moge teoretycznie wstawic cokolwiek innego i w kodzie pozmieniac, ale docelowo to nie bedzie dzialac. Czy jest na to obejsice czy musze grzecznie poczekac az zostanie to zaimplementowane w serwerze?
Awatar użytkownika
pzygmunt
Posty: 18280
Rejestracja: wt sty 19, 2016 9:26 am
Lokalizacja: Paczków
Kontakt:

Zaczekaj na implementację. Pojawi się w ciągu kilku godzin.
PS. Do testów supla-dev używaj valgrind-a aby wyłapać ewentualne wycieki pamięci itp.
Biedronek
Posty: 18
Rejestracja: śr lut 24, 2016 1:19 pm

Poczekam, i tak na razie musze troche podgonic ze sprzetem, ew. zaczne temat MCP'owy interrupt-on-change w supla-dev.

OK, sprobuje go sobie podpiac, choc o ile dobrze pamietam to kiedys mialem problemy (ale to mogla byc inna platforma). A pojawil sie jakis wyciek? Na jakims etapie pisania puscilem cppcheck'a ale przyznam sie, ze przed wrzuceniem nie sprawdzalem juz...
Awatar użytkownika
pzygmunt
Posty: 18280
Rejestracja: wt sty 19, 2016 9:26 am
Lokalizacja: Paczków
Kontakt:

Póki co nie ale zawsze uruchamiam supla-dev przez valgrinda aby mieć temat pod kontrolą.
Sprawa czujnika NC powinna być załatwiona. Konwersja stanu będzie następowała na serwerze tak więc aplikacji klienckich nie będzie trzeba zmieniać.
ODPOWIEDZ

Wróć do „supla-dev”