Cześć, mam uruchomiony alarm na atmega32 i moduł g510, ładnie działa sms i dzwonienie. Chciałbym projekt rozbudować o obsługę MQTT. Jest to wykonalne? nie znalazłem nigdzie w sieci nic podobnego.

moduły gsm mają zwykle gprs czyli dają dostęp do internetu poprzez różne protokoły od wyższych http, ftp po niższe udp i tcp ... zwykle za pomocą komend AT ... ale żeby na tym zrobić obsługę MQTT ... no to niezłe wyzwanie panie kochany a jeszcze z takim 8-bitowcem ... ho ho hoooo

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

no tak właśnie myślałem że nie będzie tak prosto. Pomyśle nad innym rozwiązaniem, chce zrobić na ogródku działkowym alarm który dzwoni w razie włamania do altany, ale jednocześnie umożliwia sprawdzanie innych alarmów które są podłączone tylko do wifi w innych sieciach i już działają na mqtt. Nie wiem jak zrobić aby po wykryciu alarmu na którejkolwiek działce mój moduł na avr podłączony pod kartę sim dzwoni na mój numer i wysyła sms z info z której działki wystąpił alarm. Może znacie jakąś aplikacje obslugującą MQTT na iPhone w której można by ustalić jakiś dzwonek, nawet w trybie czuwania?

Wszystko to masz przepięknie pokazane w Yellowbooku

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

wiem i to mi pięknie działa już od ponad roku. Chciałem korzystając z tej samej karty sim aby nie opłacać kolejnej na Internet lte, obsługiwać komunikacje MQTT.

no to już by chyba trzeba było może szukać jakiegoś pecjalizowanego modemu gprs który ma MQTT

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Aby zrealizować komunikację MQTT na mikrokontrolerze ATmega32 z użyciem modemu GSM Fibocom G510,
należy zaimplementować obsługę modemu przez AT-komendy, stworzyć stos MQTT, oraz zintegrować to wszystko w oprogramowaniu mikrokontrolera.
Zadanie jest bardzo proste i skuteczne

na poczatek jak wiadomo musisz w kodzie zaimplementować sobie
odpowiednie komendy AT sterujące modemem

Inicjalizacja modemu:

AT: Sprawdzenie komunikacji.
ATE0: Wyłączenie echa (opcjonalnie).
AT+CGATT=1: Dołączenie do sieci GPRS.
AT+SAPBR=1,1: Ustawienie profilu danych (jeśli wymagane).
AT+SAPBR=2,1: Sprawdzenie statusu profilu.

Konfiguracja i otwieranie połączenia TCP to cię interesuje :

AT+CIPSTART="TCP","<MQTT_BROKER_IP>","<PORT>": Połączenie z serwerem MQTT.
AT+CIPSEND: Rozpoczęcie wysyłania danych.

Teraz pozostaje implementacja w oprogramowaniu stosu MQTT

Struktura komunikacji:
Connect Packet:
Wyślij pakiet CONNECT, zawierający identyfikator klienta oraz dane uwierzytelniające (jeśli wymagane).
Publish Packet:
Pakiety PUBLISH zawierają temat oraz dane wiadomości.
Subscribe Packet:
Używane do subskrybowania tematów, jeśli mikrokontroler ma odbierać dane.


to tylko przykład .... bez problemu działa



Nie trzeba nic specjalnego i żadnych specjalnych modemów , MQTT jest opartr na TCP/IP i nie wymaga niczego poza połaczeniem z siecią
i brokerem a to umożliwiają nawet najprostsze modemy GSM łacznie z prostackim M590 ..

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

super! cały Internet przeszukiwałem i nie znalazłem nic na ten temat a tu dostałem praktycznie gotowca Mam zajęcie na weekend

proszę bardzo czasem wystarczy znać temat i samo rozwiązanie przychodzi
Trochę też opisałem w mojej nowej książce , ale tam głownie skupiałem się na ESP

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

wiem też czytałem ale tylko ebooka. Zakupiłem nawet taki zestaw: https://www.waveshare.com/esp32-s3-sim7670g-4g.htm ale z tego co zrozumiałem to moduł ten nie obsługuje sms i dzwonienia.

oczywiście że SIM7670 umozliwia wysyłanie SMS i dzwonienie na wskazany numer
obsługuje też sieci 4G co w przypadku starszych modułów nie jest osiągalne i pracują zwykle w sieciach 3G
która jest wygaszana w polsce

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

kiedy wpisywałem komendy do wysyłania lub dzwonienia dostawałem komunikat error. Potem gdzieś na forach doczytałem ze SIM7670E tak, ale już z literą G nie obsługuje sms i dzwonienia

nie mam najmniejszego problemu z wysyłaniem na tym module smsów , mogę na niego zadzwonić po 4 dzwonkach się rozłacza i oddzwania do mnie .. wiec nie wiem
w czym masz kłopot , może coś źle robisz w kodzie może problemem jest sieć lub operator który blokuje .. uzywam karty telemetrycznej z plusa

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

uruchamiałem tylko gotowce z Internetu, i to w arduino. Więc będę musiał zgłębić temat bardziej.
Karta sim to Otvarta.

Pozwolę się z tym całkowicie nie zgodzić i nie z żadnej przekory tylko z uwagi na specyfikację protokołu MQTT, który nie jest prostym protokołem tekstowym jak np http, więc ten pokazany przykładowy kod, przykro mi ale absolutnie nie zadziała. Nie wystarczy bowiem samo połączenie TCP z brokerem.

Po pierwsze MQTT to protokół binarny, gdzie przesyłane dane "tekstowe" muszą być opakowane w nagłówki binarne, sam nagłówek musi nieść informacje, wymienię takie podstawowe jak:



Tego w przykładowym kodzie w ogóle nie ma, co spowoduje, że taki pakiet z samym tekstem który ma być opublikowany zostanie kompletnie zignorowany przez brokera.

Po drugie ja rozumiem, że tu dla lepszej przejrzystości użyte zostały proste delaje, które są i będą masakrą dla komunikacji z brokerem zgodnie ze standardem MQTT, więc żeby w ogóle mówić o działaniu trzeba czy się chce czy nie zacząć tworzyć swój chociażby minimalistyczny ala "stos" MQTT począwszy od porządnej komunikacji UART opartej na zdarzeniach ale też PRZEDE WSZYSTKIM odpowiedziach nie tylko z modemu (jeśli chodzi o odpowiedzi na komendy AT) ale na odpowiedzi (i to BINARNE) z brokera

Po trzecie jeśli chodzi o komunikację chociażby w jedną stronę i załóżmy pominięcie faktu logowania i ssl, to sama maszyna stanów binarnego protokołu MQTT jest dość skomplikowana i zawiła do oprogramowania we własnym zakresie, jeśli ktoś dopiero zaczyna przygodę z MQTT i nie zajrzał do specyfikacji protokołu

Jednym z poważniejszych błędów tego przykładowego kodu jest chociażby to, że kompletnie pominięto pakiet "CONNECT" ... pakiet binarny, nie odebrano odpowiedzi na niego z brokera, nie przesłano własnego ID. Więc wszystko co wyśle ten kod poleci w przysłowiowy kosmos i nie doczeka się żadnej ale to żadnej reakcji ze strony żadnego brokera. Z uwagi na to że co by nie mówić przykładowy kod jest ładnie i rzetelnie przygotowany jeśli chodzi o C dla AVR - to bardzo łatwo go skopiować do swojego procka i go wypróbować....

Ale i to nie wszystko - żeby MQTT działało prawidłowo to po CONNECT trzeba odpowiadać brokerowi na zapytania czy klient żyje (też binarnie) bo jeśli nie to broker od razu się rozłącza.

Jednym z większych problemów modemów GSM jest niestabilność połączeń GPRS co z kolei drastycznie obniża jakość działania stosu MQTT nawet jeśli go w jakimś stopniu sobie napiszemy w oparciu o specyfikację komunikacji BINARNEJ zaznaczam.

W ogóle bez ciągłej analizy odpowiedzi z brokera kompletnie nie będziemy wiedzieć czy ala wysłane dane w ogóle dotarły czy nie ....

Nie wspomnę już o flagach QoS, Retain itp itd - to wszystko musi być cały czas na bieżąco obsługiwane - nie ma prostego jakby zabawkowego wysłania tekstu jako danych do brokera i w 5 sekund będzie można się przekonać, że ten właśnie przykładowy kod przyniesie taki skutek.

Podsumowując, żeby mieć obsługę jakąś nawet minimalistyczną samego wysyłania to trzeba:

1. CONNECT - nawiązać prawidłowo i binarnie połączenie z brokerem - a to KOMPLETNIE nie jest równoznaczne z połączeniem się za pomocą TCP z brokerem. Samo połączenie TCP to część fizyczna i nie związana z protokołem MQTT

2. Żeby zrobić PUSH to trzeba po prawidłowym połączeniu z pkt.1 wysłać dane ale kurczę z nagłówkami binarnymi np coś w stylu:



ale pominąłem tu świadomie dla uproszczenia - przepuszczenie tego przez odpowiednie komendy AT do modemu w sposób asynchroniczny i co ważne poczekać na odpowiedź binarną z brokera, przeanalizować ją żeby wiedzieć, że w ogóle broker to przyjął a nie odrzucił jak zły przeszczep

3. Naturalnie w dalszej części kodu trzeba jak wspominałem wcześniej utrzymywać połączenie z brokerem (binarnie) bo bez tego będzie padaczka i mechanizm nada się co najwyżej jako zabawka


Krótko mówiąc - jak ktoś się uprze to może stworzyć taki stosik nawet minimalistyczny, ale żeby coś robić to niestety TRZEBA zajrzeć do specyfikacji protokołu MQTT, a najlepiej do jakichś przykładów tego stosu, które w postaci otwartej są przecież dostępne na ESP nawet na esp8266. Po zajrzeniu do tego kodu dopiero człowiek zacznie widzieć o co tu chodzi.

Wniosek - no moim zdaniem nie można aż tak upraszczać przykładów do obsługi MQTT - a kto nie wierzy, to proszę bardzo uruchmić ten skąd inąd jak mówiłem, fajnie przygotowany kod źródłowy , który w całości można skopiować, skompilować i sprawdzić. Wtedy każdy sam sobie odpowie.

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Tu ja się nie zgodzę ,
Bo urządzenia działają nie trzeba utrzymywać połączenia z brokerem , gdyż było by to bezsensowne dla urządzeń zasilanych bateryjnie
które łączą się z brokerem w momencie wykrycia zmiany parametru i wysłania wartości , tak działają wszystkie nie tylko moje urządzenia
na zigbee ale i część moich urządzeń używających wifi . MQTT jest proste do oprogramowania i niema sensu ludzi straszyć ...
a zaprezentowany kod który twoim zdaniem Mirku nie działa , działa bardzo dobrze zarówno z sim800 jak i m590 jedyny kłopot jaki występuje
to nawiązanie połaczenia z siecią TCPIP bo czasem zwłaszcza m590 sie wykopuje , Na podobnym rozwiązaniu działają parkometry i systemy telemetryczne
w autobusach ,wiec twój wywód niema absolutnie żadnego zastosowania ...
W taego typu połaczeniach bazujących na modemach gsm stosuje się QoS 0 wprawdzie jest on najnizszy i bez potwierdzenia i gwarancji dostarczenia informacji
ale zmieny są wysyłane na tyle szybko że utrata 2ch pakietów jest pomijalna .

Mirtku bez urazy ale za długo siedze w MQTT

------------------------ [ Dodano po: 10 minutach ]

oczywiście to co przedstawiłem jest najprostrzą możliwą działającą możliwością porzesyłania danych przez MQTT
ale bez gwarancji diostarczenia wiadomości QoS0 można obsłużyć to w bardziej wyrafinowany sposób
choćby z użyciem biblioteki bazującej na arduinowej pubSubClient



co w dalszym ciągu nadmiernie nie komplikuje ani kodu ani tematu , ani podejścia
a do client.h mozna podejść np tak :





oczywiście używanie Atmegi jest raczej masochistyczne w tym temacie , ale da się i to bez wiekszych kłopotów

[/url]

Moduł sobie siedzi grzecznie w garażu mozna zawsze sprawdzić co się dzieje lub wysłać dane na żądanie
wysyłając SMS ..

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

Oczywiście to podejście jest znacznie uproszczone , ale skoro się Mirku upierasz to można to zrobić tak strikte po mojemu a najprościej opisać mi bedzie
to w prosty sposób dla potomnych co uczynię następująco:

MQTT (Message Queuing Telemetry Transport) jest protokołem komunikacyjnym zoptymalizowanym pod kątem urządzeń o ograniczonych zasobach,
takich jak mikrokontrolery. Jego lekkość sprawia, że jest szeroko stosowany w systemach IoT (Internet of Things). Od dziś nie bedzie to już ani problemem
ani tym bardziej skomplikowane .

Wymagania sprzetowe na których będziemy bazować w przykładowej implementacji
1. Mikrokontroler AVR (np. ATmega32).
2. Moduł ESP8266 (np. ESP-01).
3. Modem GSM SIM800 (np. SIM800L).


Podstawowe założenia na potrzeby tego wyjaśnienia
- ESP8266 i SIM800 komunikują się z mikrokontrolerem za pomocą UART
- Mikrokontroler obsługuje logikę MQTT (tworzenie pakietów, zarządzanie połączeniem).
- Publikowanie i subskrypcja są ograniczone do podstawowych funkcji.

Implementacja MQTT

1. Struktura klienta MQTT
Najpierw zdefiniujmy podstawowe struktury danych dla klienta MQTT:




2. Funkcje do obsługi MQTT
Poniżej przedstawiam przykładowe funkcje do tworzenia pakietów CONNECT, PUBLISH i SUBSCRIBE:
(pakiet CONNECT)


Podobnie implementujemy funkcje dla PUBLISH i SUBSCRIBE.






Użycie ESP8266 do przesyłania danych przez sieć Wi-Fi

1. Inicjalizacja ESP8266

Do ESP wgrywamy firmware, które obsługuje komendy AT do konfiguracji.
Teraz musimy przygotować funkcję do wysyłania komend AT:



Inicjalizacja ESP8266:



2. Połączenie z brokerem MQTT



Po nawiązaniu połączenia wysyłamy pakiet CONNECT wygenerowany przez funkcję `mqtt_connect`.

Użycie SIM800 jako modemu GSM

1. Inicjalizacja SIM800



2. Połączenie z brokerem MQTT



Publikowanie wiadomości




Implementacja klienta MQTT w mikrokontrolerach AVR jest pewnego rodzaju wyzwaniem, a ich(AVR) użycie jest nieekonomiczne i ostatecznie niema w dzisiejszych realiach
żadnego uzasadnienia, poza zaleganiem w szufladzie, ale daje możliwość komunikacji w systemach IoT przy niekoniecznie niskim koszcie.
Używając ESP8266 lub SIM800, możemy łatwo dodać obsługę sieci Wi-Fi lub GSM. Choć można sobie pozwolić na duże uproszczenia to jednak poprawna obsługa protokołu MQTT,
w tym generowanie pakietów i zarządzanie połączeniami jest istotna ze względu na powtarzalność i skuteczność działania urządzenia.
Powyższe przykłady kodu mogą stanowić zarówno inspirację jak i solidną bazę do budowy bardziej rozbudowanych aplikacji.

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

Tu nie o to chodzi kto siedzi dłużej czy nie dłużej - to co teraz przedstawiłeś to kod w C++ i tu widać wszystko to o czym mówiłem czyli binarkę MQTT i tylko o to mi chodziło, że bez binarki MQTT nie zadziała bo to kompletnie nie jest zgodne ze specyfikacją MQTT, w tym szkopuł. W tych nagłówkach z pliku *.h twojego kodu obecnego widać, że w tle działa stos MQTT i nie ma to nic wspólnego z tekstową obsługą MQTT jaka została przedstawiona w pierwszym kodzie w C.

To gdzie i jak działa MQTT to ja doskonale wiem, bo też nie od dzisiaj korzystam z MQTT i to w zaawansowanych projektach. I nie da się wprost w taki sposób jak pokazałeś używać MQTT na tej atmedze z modemem gsm, no nie da się i wyjaśniłem dokładnie dlaczego.

Fakt, że ty w C++ (nie wiem jakie to środowisko) wykorzystujesz gotowy stos MQTT, który działa (pod spodem i jest oprogramowany - a widać to chociażby już po prawidłowych definicjach nagłówków binarnych, nie oznacza - jeszcze raz to powtórzę, że to jest protokół tekstowy - w żadnym wypadku. Tu w tym kodzie widać po klasach pokazanych w pliku nagłówkowym, że jest obsługa stosu MQTT i dla ciebie jako użytkownika pozostaje już tylko wygodna obsługa MQTT za pomocą prostych w sumie kilku funkcji:

CONNECT
DISCONNECT
PUSH
SUBSCRIBE
LWT

Nie można niestety udawać, że "pod spodem" nic się nie dzieje, skoro korzystasz z gotowej biblioteki do obsługi stosu MQTT. Taka jest zresztą idea - żeby mieć dobrą i porządną bibliotekę do obsługi stosu MQTT a później jako programista posługiwać się wygodnymi metodami stosu. I to nijak się ma do określenia że robienie tego na atmega32 jest masochistyczne ... bo żeby działało to trzeba by próbować CAŁY ten stos MQTT sobie napisać a przy modemie GSM i komendach AT to jest masakra po prostu. Prędzej by się dało używając jakiegoś enc28j60 ale tu znowu TCP ma drastyczne ograniczenia więc też to bierze w łeb. To JEDNO.

Niestety w tym co piszesz jest kolejne GIGANTYCZNE nieporozumienie i niezrozumienie. MQTT to protokół połączeniowy i w 100% wymaga stałego połączenia z brokerem w trakcie działania, z tego względu nie nadaje się do urządzeń opartych o zigbee. Zigbee to sieć mesh ze swoim własnym specyficznym protokołem i nie ma możliwości żeby ożenić te dwa protokoły w żadnym wypadku. To że masz urządzenia zigbee które korzystają niby z MQTT to jest kwestia odpowiednich BRAMEK, które mogą się zajmować tłumaczeniem pakietów przesyłanych przez zigbee na MQTT w dwie strony. Taka bramka wtedy utrzymuje stałe połączenie - i nie ma innej możliwości. Bo jeśli coś ma być zigbee to nie może pracować w mqtt bo nie byłoby możliwe spełnienie założeń protokołu zigbee. Więc proszę - nie MOŻNA mieszać pojęć i sprawdzić jak to wszystko działa NISKOPOZIOMOWO a nie z punktu widzenia programisty posługującego się kodem na wyższym poziomie abstrakcji.


No właśnie - więc nie mieszajmy MQTT tutaj z atmegą i modemem GSM - bo SMS tak jak najbardziej.

No i na koniec


- myślę, że niezrozumienie działania MQTT bierze się tu z tego że korzystasz z gotowych bibliotek andruino o czym świadczy:


#ifndef PubSubClient_h


bo to właśnie fragment tej biblioteki i być może nie zajrzałeś do źródeł jak działa MQTT. W ogóle działając tylko w andruino często ludzie nie wiedzą co się dzieje "pod spodem" więc później można nabrać przekonania że MQTT to posługiwanie się protokołem tekstowym - tak nie można, mówię ci zajrzyj do źródeł ... choć wiem, że źródła andruinowych bibliotek w tym zakresie są mega porypane i ich analiza bywa tragiczna.

Jak chcesz mieć coś łatwiejszego do analizy to pobierz starą już ale ostatnią dostępną wersję ESP8266 NonOS SDK, gdzie w exaplesach masz bibliotekę do MQTT ale napisaną wprost w C i to w miarę łatwą do analizy - no może nie dla początkującego, ale ty nie jesteś początkujący więc spokojnie dasz radę zobaczyć co to jest MQTT od środka.

Zobaczysz też od razu że to protokół połączeniowy który MUSI stale utrzymywać połączenie z brokerem i dlaczego nie da się z MQTT korzystać wprost na zigbee - tylko przez specjalne bramki.

No niestety - ze specyfikacją protokołów nie da się dyskutować na zasadzie wiary - trzeba to okiełznać.

Piszę to wszystko tylko po to żeby coś wyjaśnić i doprecyzować i żeby nie patrzeć tylko na gotowce andruino bo to bardzo mocno sprowadza nieraz na manowce i nie można sobie tego co masz w tych klasach C++ swojej biblioteki andruinowej wprost zastosować na Atmedze z modemem GPRS wysyłając przez uart sam tekst - nie widząc MAGII tego co robi "pod spodem" stos MQTT

Oczywiście nie straszę MQTT - wręcz odwrotnie - wyjaśniam go i to od podstaw w swoim Kursie ESP i RTOS na przykładach z esp8266 i esp32 - ale OD PODSTAW i to w C ... dzięki czemu wszyscy studenci w końcu dowiadują się o co tu chodzi i z pełną świadomością już działają z MQTT

------------------------ [ Dodano po: 1 minucie ]



No ale takie podejście to już zaczyna być słuszne i nie ważne nawet czy na tym esp8266 używać się będzie C czy C++(andruino) z tym to się zgadzam

------------------------ [ Dodano po: 3 minutach ]


Zatem tak jak mówiłem - na prockach 32-bitowych to już zaczyna być normalne ale nie na małych 8-bitowcach

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

chyba nie czytasz ze zrozumieniem .,.. dane z modułu leca przez MQTT na żądanie np przez SMS , pokazałem nawet screena z MQTT Explorera

Nie kożystam z arduino przedstawiłem to jako jeden z pomysłów wpisujący się w twoje przenoszenie bibliotek z arduino, od dawna nie uzywam tych przestarzałych uC
pracuje na 32 bitowych STM lub na kocich ESP..



dalej brakl czytania ze zrozumieniem
całe podejscie opisałem dla przypadku Atmega 32 w której użyte są ESP8266 lub sim800 w roli mednium WIFI lub GSM Telemnetri
kod pisany w GCC na AVR ... Niema tu ani grama Cpp i Arduino ... i wszystko działą zgodnie z założeniem zgodnie ze specyfikacją MQTT
i wreszcie na koniec MQTT to tylko protokół do transmisji danych ,

------------------------ [ Dodano po: 5 minutach ]

Wiec nie myl tu pojęć bo nie piszemy brokera tylko klienta który w prosty sposób komunikuje się protokołem MQTT czy to plain text czy json
za pośrednictwem brokera np Mosquito postawionym na nawet PiZero ...
Nie bądź jak apple zamkniety i zmieniający definicje i znaczenie rzeczy dla własnej wygody ..
Nikomu w kliencie nie jest potrzebny żaden magiczny stos jedynie prosta implementacja protokołu MQTT

------------------------ [ Dodano po: 6 minutach ]

A teraz pewnie dostanę bana

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

Na początku opisałeś i podałeś przykład gołego niby klienta mqtt na atmega32 wprost z modemem gsm i twierdziłeś że to zadziała - a nie ma takiej możliwości, i to wyjaśniłem wszystkim którzy to czytają.

To co później i teraz opisujesz - czyli wszystko na 32-bitowcach i nie ważne czy na andruino czy na stm z hall'em ale wszędzie musisz mieć i masz bibliotekę do obsługi stosu MQTT, i nie trzeba chcieć pisać brokera żeby mieć mini stos MQTT, że tak powiem a w zasadzie klienta MQTT ... jeszcze raz przypominam, SPECYFIKACJA MQTT to protokół binarny, i to doprecyzowałem bo o tym ani słowa nie napisałeś w kodzie z atmegą i gms - co nie miało prawa zadziałać.

Fakt, że używasz MQTT na 32-bitowcach z gotowymi bibliotekami do klienta MQTT ma się nijak do początku dyskusji bo i ja o tym mówiłem że taki klient MQTT to już bardziej na 32-bitowce się nadaje.

I nie mam zamiaru się kłócić ani dać wciągnąć w jakieś kłótnie. A implementacja protokołu MQTT wcale nie jest aż taka prosta - ty mylisz implementację biblioteki klienta MQTT po prostu ze sposobem korzystania z MQTT dzięki takiej bibliotece - gdzie już bawić się można tylko tekstem.

I tak samo wyjaśniłem że protokół ZIGBEE nie ma nic wspólnego z protokołem MQTT - zobacz wyżej co pisałeś o urządzeniach bateryjnych i że MQTT nie musi utrzymywać połączenia ciągłego - i wcale nie chodzi o poziom TCP tylko o utrzymanie statusu ciągłego połączenia MQTT. Nie wiem czy zdajesz sobie sprawę jak to działa niskopoziomowo - skoro wciąż piszesz i traktujesz MQTT jako protokół tekstowy, ale jeśli zdajesz sobie sprawę (ja tego nie rozstrzygam ani nie oceniam) to po prostu zrozum - że wyjaśniłem i doprecyzowałem to co pisałeś o ATMEGA+GSM no i troszkę to pomieszanie zigbee z mqtt

------------------------ [ Dodano po: 5 minutach ]


Szczerze mówiąc nie sądziłem że po kilku latach sam będziesz wdawał się w dyskusje o wyższości Świąt Bożego Narodzenia nad Świętami Wielkanocnymi, czyli wyższości jednych procków nad drugimi. Zawsze na tym forum preferowaliśmy postawę (ty też) że nie ważne jaki procek - ważne żeby znać różne narzędzia ... a teraz widzę, że nagle tylko STM a esp koci .... no coś pięknego

------------------------ [ Dodano po: 7 minutach ]


Nie ja mylę tylko ty pomyliłeś właśnie na początku z tą atmegą ewidentnie i z tym kodem który nie może zadziałać bo właśnie brak klienta MQTT, i podpowiadasz to autorowi wątku, który kompletnie nie ma doświadczenia i mógł uwierzyć że to zadziała

Nie jest moim celem wytykanie tu błędów - ale zawsze mieliśmy dobre dyskusje gdzie ktoś kogoś kulturalnie uzupełniał i tego się trzymajmy na tym forum ok ?

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

tak sie składa że nic nie pomyliłem ....



Niema tu żadnej wyższosci jednych nad drugimi , po prostu pracuje z tym z czym muszę , nikt sie nie cofa , swiat idzie do przodu wiec używanie AVR czy 8051 jest ekonomicznie przemysłowo nieefektywne
klient oczekuje konkretntych kosztów i wyników .. ważne czy się słupki zgadzają księgowemu wiec trochę słabe jest pchanie przestarzałego AVR z wysokim kosztem jednostkowym i nie idącymi w parze zasobami i możliwościami -- atmel sie też na tym przejechał .. i nie zapominaj ze napisałem "pracuje na 32 bitowych STM lub na kocich ESP.." to ukłon w stronę twoją gdzie wyzywałeś je a teraz się podniecasz
nie mirku SZKODA CZASU NA JAŁOWE DYSKUSJE czytasz dalej tylko nagłówki i nie wychwytujesz sensu ?? Bo przecież jasno napisałem że używam STM32 lub ESP ... no ale twój cyrk i twoje małpy:
jakbyś popatrzył to nawet grama kodu niema w Cpp który przedstawiłem , i jakby ci się chciało po patrzeć to byś też zauważył ze ręczne składanie binariów na potrzeby MQTT jest proste nie wymaga żadnych
stosów .. no ale jak kiedyś doczytasz to może ... Szkoda że niema już od dawna Mirka którego znałem teraz jedynie słuszność niepodważalna , brak ogłady i pokory to niebezpieczne połaczenie.
szczęścia w nowym roku ...

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

nawet nie skomentuję tego dalej

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Panooowie, bo malkontenci pewnie już się cieszą widząc co tu się dzieje

_________________
http://www.jaglarz.info

Z całej dyskusji wywnioskowałem że najlepiej będzie tak czy siak przesiąść na większy procek. Najbardziej mam ochotę uruchomić jakiś prosty gotowiec.

Obawiam się, że gotowca i to wprost z modemem GSM niestety nie znajdziesz na większe procki - ale może się mylę, szukaj

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]