Prosba o dokumentacje + inne sprawy

[Biedronek]

Wracajac do tematu zuzycia CPU to moze nie byc kwestia gpio_wait. Jesli rzeczywiscie tak jest to moze jakies inne sugestie?

[pzygmunt]

eh_wait nie radzi sobie z selectem na porcie z którym coś jest nie tak. Jutro się tym zajmę bo na 100% jest to drobny problem.
Generalnie jeżeli jest wszystko OK to obciążenie procka powinno być marginalne.

[Biedronek]

Jasne, dziekuje. Edytowalem swoj poprzedni post po sprawdzeniu backtrace'a w gdb a nie wprowadzac zamieszania.

[pzygmunt]

Podeślij jeszcze supla.cfg na którym obserwujesz obciążonego procka.
Swoją drogą to trzeba będzie pomyśleć o jakimś systemie do zarządzania projektami agile ponieważ coraz więcej osób się angażuje w projekt i
musimy jakoś przydzielać zadania aby nie dublować się wzajemnie.

[Biedronek]

[GLOBAL]
device_name=RASBPBERRYPIv2
device_guid_file=/etc/supla-dev/dev_guid
alt_cfg=/boot/location.txt
state_file=/boot/last_state.txt

[SERVER]
host=127.0.0.1
tcp_port=2015
ssl_port=2016
ssl_enabled=Y

;[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=SENSORNO
;driver=mcp23008
;mcp_reset=4
;mcp_addr=0x20
;mcp_gpio_dir_8=1

[magx2]

Próbuję rozgryźć protokół komunikacji żeby może napisać dokumentację do tego. Póki co doszedłem do takich wniosków:

• Dane wysyłane są socketami na portach 2016 (HTTPS) i/lub 2015
• Struktura która jest wysyłana to TSuplaDataPacket https://github.com/SUPLA/supla-core/blo ... oto.h#L228
• W polu data tej struktury są wysyłane inne struktury
• Serializacja następuje poprzez prostą zamianę typów na bity (np int to 32 bity)

Czy moje wnioski są poprawne?

Co do pytań, na które jeszcze nie znalazłem odpowiedzi:

• TSuplaDataPacket->data co tutaj może być przesyłane?
• Do czego służy pole TSuplaDataPacket->call_type? Czy to jest typ przesyłanych danych w polu data?
• Do czego służy pole TSuplaDataPacket->tag?
• Jak działa aktualizacja oprogramowania na urządzeniach wykonawczych?

Mam nadzieję, że po otrzymaniu odpowiedzi na zadane pytania będę wstanie sklecić kilka zdań o protokole komunikacji dla Supli .

BTW.
Nie zastanawiałeś się nad użyciem protobufa (https://developers.google.com/protocol- ... ocs/proto3, https://github.com/protobuf-c/protobuf-c) do komunikacji w Supli? Wydaje się, że korzystanie z gotowych rozwiązań serializacji może być lepszym wyborem.

[pzygmunt]

Tak. Wnioski poprawne.

call_type okresla typ wywołania, a w data są tak jakby jego parametry przesyłane w strukturze.
data nie zawsze musi być uzupełnione.
wielkość tablicy data określa zmienna data_size i nie może być większa od SUPLA_MAX_DATA_SIZE. Serwer wspiera 10kb

rodzaje wywołań określają definicje

SUPLA_DCS_CALL_*
SUPLA_SDC_CALL_*
SUPLA_DS_CALL_*
SUPLA_SD_CALL_*
SUPLA_CS_CALL_*
SUPLA_SC_CALL_*

Gdzie aby łatwiej określić kierunek wywołania przyjąłem następującą nomenklaturę.

DCS = Device/Client -> Server
SDC = Server -> Device/Client
DS = Device -> Server
SD = Server -> Device
CS = Client -> Server
SC = Server -> Client

tag to stała od której zaczyna się każdy przesyłany pakiet. W tym przypadku to są znaki { 'S', 'U', 'P', 'L', 'A' }

Komunikacja sprowadzona jest do RPC (remote procedure call, a raczej zdalnych wywołań funkcji).
https://github.com/SUPLA/supla-core/blo ... rpc.h#L108

Wszystkie funkcje nazywają się tak samo jak definicje o których mowa wyżej z tym, że w nazwie mają dodatkowo "async".
Po tym można określić do którego wywołania idzie która struktura.

Nawiązanie połączenia device->server

1. Urządzenie wysyła
SUPLA_DS_CALL_REGISTER_DEVICE_C
https://github.com/SUPLA/supla-core/blo ... rpc.h#L119

2. Serwer sprawdza wersję protokołu oraz uprawnienia w odpowiedzi wysyłając
SUPLA_SD_CALL_REGISTER_DEVICE_RESULT
https://github.com/SUPLA/supla-core/blo ... rpc.h#L120

Jeżeli wersja protokołu jest niższa niż wersja serwera to serwer zniża swoją wersję do wersji urządzenia.
Jeżeli jest wyższa to zrywa połączenie ponieważ uznaje, że nie zna nowszej od siebie wersji.

3. Jeżeli wszystko OK to połączenie jest utrzymywane. Jeżeli nie to jest zrywane.
W przypadku gdy połączenie jest nawiązane urządzenie melduje się co jakiś czas, że nadal "żyje".
SUPLA_DCS_CALL_PING_SERVER
https://github.com/SUPLA/supla-core/blo ... rpc.h#L111

następnie uzyskuje odpowiedź od serwera
SUPLA_DCS_CALL_PING_SERVER_RESULT
https://github.com/SUPLA/supla-core/blo ... rpc.h#L112

co pozwala mu również określić, że serwer też "żyje"

Ping nie musi być wysyłany jeżeli w miedzy czasie była jakakolwiek komunikacja.
Czas co jaki urządzenie musi się meldować określa serwer przesyłając tą informację w
TSD_SuplaRegisterDeviceResult.activity_timeout

urządzenie może wysłać prośbę o zmianę tego czasu za pomocą
SUPLA_DCS_CALL_SET_ACTIVITY_TIMEOUT
https://github.com/SUPLA/supla-core/blo ... rpc.h#L113

zwrotnie otrzymując informację od serwera czy serwer zaakceptował to czy nie
SUPLA_SDC_CALL_SET_ACTIVITY_TIMEOUT_RESULT
https://github.com/SUPLA/supla-core/blo ... rpc.h#L114

Co do protobufa.... nie znałem tego. Może gdybym wtedy znał to bym użył

Obecny protokół i własna implementacja bufora pozwala na podzielenie TSuplaDataPacket nawet na pojedyncze bajty.

[magx2]

Odpaliłem wczoraj swojego Zamel ROW-01 żeby łączył się z moim komputerem żeby podpatrzeć protokół. Niestety bajty, które otrzymałem nijak mają się do tego co jest w TSuplaDataPacket. Z tego co wyliczyłem powinienem dostać minimum 18 bajtów danych w takiej kolejności:

1 bajt litera "S", 1 bajt litera "U", 1 bajt litera "P", 1 bajt litera "L", 1 bajt litera "A", 1 bajt pole "version", 4 bajty pole "rr_id", 4 bajty pole "call_type", 4 bajty pole "data_size"

Niestety to ma się nijak do tego co dostałem, poniżej zamieszczam kilka payloadów, które dostałem od ROW-01 (więcej załączam w pliku CSV)

1) 00010110 00000011 00000010 00000000 00110011 00000001 00000000 00000000 00101111 00000011 00000010 00000000 00000000 00000000 00000000 00011100 11111101 11100011 00100000 01111010 11001001 01001010 10001100 11010000 10001010 01110110 10110011 00101110 00000100 11100010 00001100 00001110 10010110 00100101 01010000 10110100 10001001 00111011 11101110 10011010 00000000 01110001 00000101 00000000 00000000 00001000 00000000 00101111 00000000 00110101 00000000 00000101 00000000 00000100 00000001 00000000

2) 00010110 00000011 00000010 00000000 00110011 00000001 00000000 00000000 00101111 00000011 00000010 00000000 00000000 00000000 00000000 00110110 01101100 11100001 01110111 01110110 10101110 11111000 00111010 00001010 01110111 01010101 10101010 00011100 10110111 11010010 11111101 01100111 10110001 00110001 11101000 01111000 10001001 00101010 11111001 01111000 11101101 00010011 10111011 00000000 00000000 00001000 00000000 00101111 00000000 00110101 00000000 00000101 00000000 00000100 00000001 00000000

3) 00010110 00000011 00000010 00000000 00110011 00000001 00000000 00000000 00101111 00000011 00000010 00000000 00000000 00000000 00000000 01100010 01111001 11101111 11110000 00011000 11111111 10100110 10111101 11001111 00111000 10111000 10010101 00010011 10001101 00000011 10010011 11000110 00001111 10101001 01010011 10011001 11011000 11011110 11001100 01000001 00010001 00010001 10100110 00000000 00000000 00001000 00000000 00101111 00000000 00110101 00000000 00000101 00000000 00000100 00000001 00000000

Czy możesz mi wytłumaczyć o co tu chodzi?

PS.
Włącz, proszę, obsługę [table] [tr] [td] w BBCode i możliwość uploadowania plików txt/csv

[pzygmunt]

Testuj na Arduino. Cała reszta używa domyślnie SSL-a

[magx2]

Testuj na Arduino. Cała reszta używa domyślnie SSL-a

Heh, kompletnie o tym zapomniałem. Jak odpaliłem socketa HTTPs to wszystko śmiga