Hi!
In short: I'll need a custom transport to carry MQTT, which is not TCP-based. Is that doable? If yes, how could I do that, in broad strokes?
I have a work project that uses MQTT in an ESP32. That works well over Ethernet. They now need the MQTT to be carried over CAN Bus. The "other side" has not been decided yet but will likely be some application on a regular computer that translates from CAN frames to a direct localhost connection to an MQTT broker (or perhaps generic IP network). There will be layers on top of CAN, probably ISO-TP, likely UDS. I don't know yet what they'll come up with.
In any case, I'll probably need to establish an MQTT connection over a custom transport.
I've browsed the source in `esp-idf` and `esp-mqtt`. I see mention of `esp_transport_*` but at least one of those resides in `esp_transport_internal.h`. Sounds to me like I can't use that.
custom transport to carry MQTT over CAN/TWAI
custom transport to carry MQTT over CAN/TWAI
Last edited by crackwitz on Fri Sep 15, 2023 5:36 pm, edited 1 time in total.
-
- Posts: 1699
- Joined: Mon Oct 17, 2022 7:38 pm
- Location: Europe, Germany
Re: custom transport to carry MQTT over CAN/TWAI
This may be possible with some changes to the MQTT client:
esp_mqtt_client_create_transport(...) sets up an esp_transport according to the requested 'scheme', i.e. "mqtt", "mqtts", "ws", or "wss". This would need to be modified to support another, custom scheme.
For the new scheme, an esp_transport_handle_t needs to be created (esp_transport_init()) which you then set up, primarily, with custom transport functions via esp_transport_set_func(...).
That'd be the broad overview of how it could work. There possibly is some code in the MQTT client which breaks encapsulation by assuming an esp_transport_handle_t is always TCP based (e.g. always has a host and a port number) that would need to be dealt with too.
All in all, it may be possible; but it doesn't seem to be worth the hassle.
You may want to consider creating an abstraction API on top of MQTT with two or three functions to send and receive "messages". The MQTT-over-TCP client then is one 'transport' the API can be implemented with, and CAN messaging would be another implementation of the same API.
The translation between CAN and MQTT (or any other target protocol) would then (only) happen at the far side (PC,...), which for the most part needs to be done anyway.
esp_mqtt_client_create_transport(...) sets up an esp_transport according to the requested 'scheme', i.e. "mqtt", "mqtts", "ws", or "wss". This would need to be modified to support another, custom scheme.
For the new scheme, an esp_transport_handle_t needs to be created (esp_transport_init()) which you then set up, primarily, with custom transport functions via esp_transport_set_func(...).
That'd be the broad overview of how it could work. There possibly is some code in the MQTT client which breaks encapsulation by assuming an esp_transport_handle_t is always TCP based (e.g. always has a host and a port number) that would need to be dealt with too.
All in all, it may be possible; but it doesn't seem to be worth the hassle.
You may want to consider creating an abstraction API on top of MQTT with two or three functions to send and receive "messages". The MQTT-over-TCP client then is one 'transport' the API can be implemented with, and CAN messaging would be another implementation of the same API.
The translation between CAN and MQTT (or any other target protocol) would then (only) happen at the far side (PC,...), which for the most part needs to be done anyway.
Re: custom transport to carry MQTT over CAN/TWAI
Thanks for the brainstorming.
Anything that would require me to change esp-idf would be near impossible to keep straight. I have upstreamed minor changes to esp-idf before but that was for exploratory/proof-of-concept work where I was the only one who had to carry the patch.
That sounds reasonable and would happen entirely in user code. I think I'll follow your suggestion.
Anything that would require me to change esp-idf would be near impossible to keep straight. I have upstreamed minor changes to esp-idf before but that was for exploratory/proof-of-concept work where I was the only one who had to carry the patch.
Who is online
Users browsing this forum: ESP_Sprite and 277 guests