Bc66 #492
Bc66 #492
Conversation
|
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. |
|
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
<#492 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAA3R4GAFZSWTVYKUO5BLD3S6GILJANCNFSM4XKUPBJA>
.
|
|
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? |
|
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. |
|
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... |
Added Quectel BC66 support as UART modem (alpha stage)