search

vshymanskyy / TinyGSM

A small Arduino library for GSM modules, that just works
GNU Lesser General Public License v3.0
1.94k stars 719 forks source link

Bc66 #492

Open belveder79 opened 3 years ago

belveder79 commented 3 years ago

Added Quectel BC66 support as UART modem (alpha stage)

SRGDamia1 commented 3 years ago

I would rather not implement MQTT using application level modem commands at this time. I would prefer to keep TinyGSM at the socket level (TCP commands) and refer users to an MQTT library (like PubSubClient) for the MQTT application layer.

belveder79 commented 3 years ago

I agree that it is more general to use TCP layer. However, the problem is that there is no SSL enabled version for communication (at least I did not find one) and it is more efficient to use the on-chip functionality instead of messing with application code. The other issue is that generally the polling for data by waiting for some weird AT messages from the modem is really flaky - I was not able to get it implemented correctly at all yet...

Sara Damiano notifications@github.com schrieb am Di. 9. Feb. 2021 um 21:04:

I would rather not implement MQTT using application level modem commands at this time. I would prefer to keep TinyGSM at the socket level (TCP commands) and refer users to an MQTT library (like PubSubClient) for the MQTT application layer.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/vshymanskyy/TinyGSM/pull/492#issuecomment-776205534, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA3R4GAFZSWTVYKUO5BLD3S6GILJANCNFSM4XKUPBJA .

SRGDamia1 commented 3 years ago

Oh, sorry, so it's an SSL issue, too. I didn't catch that.

I think others have had success by using TinyGSM for the socket layer, another SSL library for the security layer, and then PubSubClient or whatever else on top of that. Have you tried something like that?

SRGDamia1 commented 3 years ago

I'm sure using the on-chip MQTT and SSL functionality would be more efficient, I'm just not sure I want to add that layer to this library right now.

belveder79 commented 3 years ago

Concerning SSL libs, I actually have not tested others. I'm primarily working with ESP8266 and ESP32, and program memory is always an issue, aside of the very little computational power...

You are totally right. Having less hardware-specific support for individual features, but keeping the library functionality more general instead, is a good approach. The main issue I see is that you have to be clear about what is a modem and what is more than a modem and have to reflect that somewhat in what goes in and what does not...

The SIM800 is a stupid modem. The BC66 however is essentially like an ESP8266, but uses NB-IoT instead of WIFI. So in my case, indeed I want to use the BC66 like a stupid modem because it's not a plausible replacement for my ESP32. So I need to control it over AT commands. Still it turned out that handling of modem data over serials - and the polling in particular - causes real trouble if the waitResponse() is not called frequently or there are several modem responses piling up to be handled with string-compare.

Because I need to have SSL for my MQTT server I just went straight for using the built-in functions, which worked fairly well, but only because the MQTT protocol for BC66 is pretty clean (i.e. clear responses or messages). There are still occasional issue, which are - again - related to this waitResponse() thing... so the bottom line is, I cut it short by using the direct modem commands, and I now have less issues because it is cleaner, but the issues still there are related to the fundamental issues with querying data from the modem...