PIC32 i MQTT: Problemy z biblioteką przy błędnym logowaniu

Wed Aug 10, 2022 9:59 am   

J.F <jfox_xnospamx@poczta.onet.pl> napisał(a):

Ale właśnie...


....printf z tego nie korzysta. On ma taką deklarację:
int printf ( const char * format, ... );
Czyli przyjmuje jeden lub więcej parametrów i jest to po ludzku określone.
Do niczego nie jest mu potrzebny ten dziwny mechanizm z pustą listą
argumentów.

--
Grzegorz Niemirowski
https://www.grzegorz.net/

Wed Aug 10, 2022 7:25 pm   

Ok, posiedziałem nad tym jeszcze przez kilka godzin i udało mi się
znaleźć przyczynę. W wielkim skrócie maszyna stanów w funkcji
MQTTReadPacket była źle napisana. Jeden if nie wykonywał się wcale, a
część kodu w dalszej części była pomijana zupełnie z uwagi "break"
umieszczony w złym miejscu. Efekt był taki, że kod przechodził dalej już
po odebraniu nagłówka pakietu i nie pobierał pozostałych dwóch bajtów.

Biblioteka w takiej formie działała tylko dlatego, że w wyniku innego
błędu kod zawsze zakładał, że autoryzacja przeszła poprawnie.
Z uwagi na wadliwość tej funkcji rzecz jasna nie miały szans działać
jakiekolwiek inne funkcje związane z odbieraniem danych od brokera.
Niewykluczone zresztą, że będę musiał przeprowadzić dodatkowe testy i
poprawić jeszcze kilka błędów, zanim uda mi się uruchomić sprawdzanie
wiadomości PUBLISHACK albo subskrybowanie tematu i odbieranie wiadomości
przychodzących od brokera.

Wireskark pokazuje także, że mam trochę retransmisji TCP na porcie MQTT,
więc temu też jeszcze będę musiał się przyjrzeć.

Na chwilę obecną działa jednak najważniejsze - wrzucanie danych na
serwer. Jeśli ktoś byłby zainteresowany, to po posprzątaniu mogę się tym
podzielić. O ile ktoś jeszcze używa PIC32 z bibliotekami MLA i będzie
potrzebował obsługi MQTT.

Wed Aug 10, 2022 8:41 pm   

On 10/08/2022 19:25, Atlantis wrote:

Teraz, to się używa ESP8266/ESP32 do tego a nie jakieś PICe od migania
ledami

Wed Aug 10, 2022 10:06 pm   

On Wed, 10 Aug 2022 20:41:36 +0200, heby <heby@poczta.onet.pl> wrote:

Uu pic32 od migania ledami, mocne.

--
Marek

Wed Aug 10, 2022 10:43 pm   

Atlantis <marekw1986NOSPAM@wp.pl> napisał(a):

Ja nie potrzebuję, ale może po prostu wrzuć na githuba, to ktoś spoza pme
też skorzysta i nie będzie się musiał męczyć z tamtym kodem.

--
Grzegorz Niemirowski
https://www.grzegorz.net/

Wed Aug 10, 2022 11:26 pm   

On 10/08/2022 22:06, Marek wrote:

Cieszymy się, że również zauwazyłeś emotkę na końcu zdania.

Fri Aug 12, 2022 11:25 am   

W dniu 2022-08-10 o 19:25, Atlantis pisze:


Ktoś się pomylił.


A potem znalazł i poprawił błąd
P.G.

Tue Aug 16, 2022 1:20 pm   

Ok, udało mi się trochę pchnąć do przodu prace nad biblioteką.
Na chwilę obecną działa już nie tylko wysyłanie wiadomości, ale także
jestem w stanie subskrybować temat i odbierać wiadomości od brokera.
Usunąłem większość najbardziej rzucających się w oczy błędów oraz
konstrukcji, które w pewnych sytuacjach powodowały zawieszanie się kodu.
Pozostało jeszcze kilka rzeczy do posprzatania i poprawienia, a na
chwilę obecną mierzę się z dziwnym błędem, którego nie potrafię
zdiagnozować.

Sytuacja wygląda następująco:
1. Broker (mosquitto) jest odpalony na Raspberry Pi.
2. Do brokera podłączone jest jedno z moich urządzeń na ESP8266, które
cyklicznie wrzuca dane na jeden temat.
3. Temat na brokerze podglądam za pomocą mosquitto_sub - faktycznie się
tam pojawiają.
3. Jednocześnie jestem w stanie wrzucać swoje własne dane zapomocą
mosquitto_pub - tetrafiają tam, gdzie powinny.

Dziwne zachowanie pojawia się w momencie, gdy do tego samego
brokera/tematu podpinam PIC32 z testowaną biblioteką. Normalnie loguje
się na brokerze i subskrybuje do tego tematu. Przez jakiś czas odbiera
rozsyłane dane pochodzące z ESP8266, ale potem przestaje (na brokerze
pojawiają się nadal). Dane, które wrzucam ręcznie (mosquitto_pub) nadal
docierają na PIC32.

Co może być przyczyną? Zakładam, że może za to odpowiadać jakaś
specyfika protokołu MQTT, której nie jestem świadom.

Wed Aug 17, 2022 6:58 pm   

On 16.08.2022 13:20, Atlantis wrote:


Czyli ręcznie wrzucasz pod ten sam temat i dochodzą, a od ESP nie dochodzą?
Zakładam, że qos i retained masz w obydwu przypadkach takie same?
Client-id unikalne? (!)
No to już czary musiały by być żeby jedno dochodziło drugie nie.

--
Mirek.

Thu Aug 18, 2022 11:03 am   

On 17.08.2022 18:58, Mirek wrote:


Ok, już znalazłem przyczynę. Tak jak piszesz - przepisując kod
zapomniałem o wywołaniu funkcji, która w przypadku wykrycia ustawionej
flagi QoS inicjowała odsyłanie potwierdzenia odebrania wiadomości
PUBLISH. Broker nie otrzymując potwierdzeń po jakimś czasie zaprzestawał
rozsyłania wiadomości do tego konkretnego subskrybenta. Natomiast
wiadomości wysyłane ręcznie nie miały ustawionej flagi, więc dochodziły
nadal.

Po uzupełnieniu kodu wszystko działa prawidłowo. Urządzenie pracuje już
prawie dobę i cały czas odbiera wiadomości z brokera. W oczy rzuciła mi
się natomiast inna kwestia - gdy sprawdzałem za pierwszym razem za
pomocą tcpdumpa (odpalonego na Raspberry Pi, gdzie pracuje broker) i
wiresharka, widziałem wszystkie pakiety.

Teraz natomiast wygląda to tak, jakby tcpdump nie rejestrował wiadomości
wychodzących od klienta (PUBACK, PINGREQ), chociaż wiadomości są
wysyłane i najwyraźniej docierają, bo powodują reakcję (np. w postaci
odesłania PINGRESP). Jakiś pomysł co może być przyczyną takiego stanu
rzeczy?