Tasmota integration with esxp1302?

[michcfr]

Hello, I would like to integrate the esxp1302 code with Tasmota to take the benefits of sending any data over MQTT with 8-channel LORA. Tasmota has already this capability, named bridge, but for single channel devices with the SX126x or SX127x. See https://tasmota.github.io/docs/LoRa-and-LoRaWan-Bridge/

Do you have an idea of how to handle it? or at least any chance to get it for next versions/evolutions? Please provide any feedbacks. Thank you.

Michel

[dennis4lora]

Thanks for this proposal. I don't object it but I also don't think it's easy to add MQTT support.

I have a quick check the LoRaWAN Bridge support provided by Tasmota. The reason why it only supports single channel is because all the LoRa chips it supports are node chips, while SX1302 and SX1303 are gateway chips. They have different drivers and functions, so Tasmota can't add support to sx1302 by re-using its current code for sx127x/sx126x.

In fact, if external bridge is OK for you, then one is already available: https://github.com/chirpstack/chirpstack-gateway-bridge.

And if you would like esxp1302 itself to support MQTT, then we can have more discuss about how it should be like and how to implement it and if it's reasonable and doable... :smile:

[michcfr]

Thank you for your response.

From the end user point of view, it is useful to have Lora to MQTT directly supported by the ESP32 rather than an external bridge: -no need of external PC, the ESP32 device acts like a MQTT hub -take the benefit of the Tasmota ecosystem: user interface, update, community... -have mechanisms of device/sensor plugin by specifying mapping on a per-device type basis. see Zigbee2MQTT

I'm not a LORA specialist, but my idea is to add into your code some code written for the ESP32 that supports: -LoraBridge: gateway Bridge as done by the ChirpStack Gateway Bridge but embedded into the ESP32 -Lora2MQTT: transform Lora packets into MQTT messages embedded into the ESP32. Tasmota did it for ZigBee by writting Zigbee2Tasmota (Z2T), inspired by Zigbee2MQTT (https://www.zigbee2mqtt.io/)

Of course, your would let the user to use the device as LoRaWAN gateway, or as MQTT bridge.

Please tell me if I am clear...or not :-)

[dennis4lora]

I'm not familiar with Tasmota, so I'm afraid I can't help to make esxp1302 to be a bridge in Tasmota. However, if just to add MQTT support in esxp1302, I think it's doable.

If I'm right, then what you want esxp1302 to become should be like this:

If so, then there are two things to do:

• add a thread for MQTT support
• add a switch to control if ESXP1302 traffic goes to LoRaWAN NS or goes through the MQTT bridge to MQTT server.

[michcfr]

Thank you. Yes, this is what I need for the MQTT bridge :-)

I would go further since I need to get a full autonomous bridge, the same way as Tasmota did for ZigBee. The features I would like to get implemented in the Bridge would be:

1)MQTT bridge as you mention in the figure. I also need to use MQTT for controlling the ESXP1302 bridge, as done in: www.zigbee2mqtt.io/guide/usage/mqtt_topics_and_messages.html. For example, for pairing LORA Devices with the Bridge through MQTT. Tasmota for ZigBee was inspired from Zigbee2mqtt.

2)add Ethernet support to ESXP1302 by interfacing with an ethernet chip like LAN8720 or W5500 so that it can be connected to an ethernet router: SX1302 <=> ESP32 <=> Ethernet chip <=> Ethernet router

3)Various WebUI for ESXP1302 configuration: .ESXP1302 acts as a WiFi AP configuration to be configured like: tasmota.github.io/docs/Getting-Started/#__tabbed_2_2 .MQTT configuration: tasmota.github.io/docs/MQTT/#configure-mqtt .Joint procedure: to allow devices to join the network Permit Join button in the WebUI

Please give me your feedbacks. What can be done or not.

Thank you

[danielkucera]

Adding ethernet should be pretty easy, esp-idf has drivers. https://github.com/espressif/esp-idf/tree/v5.2.2/examples/ethernet/basic

[michcfr]

Thank you Daniel, Good to know that this lib can do 2) but how to integrate it in the esxp1302?

I also found this lib: https://docs.openmqttgateway.com It can do 1) MQTT bridge + 3)WebUI

Controlling the ESXP1302 bridge as mentionned in 1) we can put placeholders in the code to read the Lora payload and interpret it. Some solution propose Yaml to interpret the message.

[dennis4lora]

My opinions:

Currently esxp1302 has a simple web page for settings (I just updated the README to include it). Of course it's useful if it supports other ways such as use web API (though not available so far) or by MQTT. And I guess either YAML or JSON (esxp1302 contains a small library for it) should be OK. But you'll need to define what items for customizing.

For your #3:

• esxp1302 can work as either a Soft AP or station, and be controlled by web settings.
• The join procedure is handled by LoRaWAN protocol and user registers devices on NS (Network Server). I don't think it makes sense to do it on the gateway side. I would use MQTT for simple applications (such as receive uplink packets), and use NS such as Chirpstack for complex functions. But I maybe wrong. :-)

For Ethernet support:

• If you want to replace Wi-Fi with Ethernet interface, I think it would be easy: just check how it's be done in the original sx1302_hal and use it as a guide to replace the Wi-Fi related code.
• If you want to have both Wi-Fi and Ethernet co-exist, it's much complex. For example: how to decide which interface be used for connecting to NS?

So I suggest that you pick the 1st way to start with.

I'm not sure if openmqttgateway could be re-used or not...

Here are some simple MQTT examples provided by esp-idf: https://github.com/espressif/esp-idf/tree/v5.2.2/examples/protocols/mqtt

[michcfr]

Thank you for your response.

-ok for the simple web page for settings, soft AP/station and for controlling. -I want to replace Wifi with Ethernet. It is exclusive: I don't need both at the same time. -I can start with the simple MQTT examples you provide.

Concerning the NS, the theory I want to experiment is that for simple applications, we can avoid it by using few simple MQTT commands. The ESXP1302 would acts as micro-NS based on MQTT.

Would you mind to update the ESXP1302 code to support the Ethernet and the simple MQTT bridge? It will be very helpfull for me as a starting point.

[dennis4lora]

Would you mind to update the ESXP1302 code to support the Ethernet and the simple MQTT bridge?

I have no Ethernet hardware currently, so I would work on the MQTT bridge support first.

BTW: if you make Ethernet exclusive, then you won't need to support soft AP/station switch anymore...

[michcfr]

Great! Thank you Dennis

Can you please put a placeholder (callback for example) before the Esp32 sends the MQTT message to the MQTT broker? To do some processing on the message before it is sent to the MQTT broker.

Yes, if Ethernet is choosen then AP is not needed. I still would need AP at the initialisation phase to set the Ethernet IP address (fixed or DHCP) and eventually MQTT parameters. It can be useful for some situations where I lost contact with the Ethernet: at reset, the esxp1302 will be reachable as wifi AP.

I have other questions not related to this topic but I don't know if I have to create separate topics. It is about: -how to manage the duty cycle? -is the sx1303 supported?

[dennis4lora]

I propose that I just work on sending the original JSON message to MQTT broker as the default behavior, then you can customize this to suit your specific requirements, which should be very easy: you can add callback or do changes in the thread directly.

If your Ethernet connects to a Router which provides DHCP service, then the wireless interface is not necessary and the logic would be simpler. To provide option for both DHCP and fixed IP, then Wi-Fi is needed.

For your two questions:

• Duty cycle is handled by LoRaWAN protocol, so mainly handled by the node (the NS may also be involved). Gateway just forwards packets.
• Yes, SX1303 is also supported by ESXP1302.

[dennis4lora]

I propose that I just work on sending the original JSON message to MQTT broker as the default behavior, then you can customize this to suit your specific requirements, which should be very easy: you can add callback or do changes in the thread directly.

If your Ethernet connects to a Router which provides DHCP service, then the wireless interface is not necessary and the logic would be simpler. To provide option for both DHCP and fixed IP, then Wi-Fi is needed.

For your two questions:

• Duty cycle is handled by LoRaWAN protocol, so mainly handled by the node (the NS may also be involved). Gateway just forwards packets.
• Yes, ESXP1302 supports both SX1302 and SX1303.

[michcfr]

I propose that I just work on sending the original JSON message to MQTT broker as the default behavior, then you can customize this to suit your specific requirements, which should be very easy: you can add callback or do changes in the thread directly.

ok

If your Ethernet connects to a Router which provides DHCP service, then the wireless interface is not necessary and the logic would be simpler. To provide option for both DHCP and fixed IP, then Wi-Fi is needed.

yes, these two use cases are needed. will you use the ethernet esp-idf driver, as suggested by Daniel? https://github.com/espressif/esp-idf/tree/v5.2.2/examples/ethernet/basic

For your two questions:

• Duty cycle is handled by LoRaWAN protocol, so mainly handled by the node (the NS may also be involved). Gateway just forwards packets.

thank you for clarifications.

• Yes, ESXP1302 supports both SX1302 and SX1303.

great!

[dennis4lora]

will you use the ethernet esp-idf driver, as suggested by Daniel? https://github.com/espressif/esp-idf/tree/v5.2.2/examples/ethernet/basic

Yes, I think that's the right option.

[michcfr]

hello, do you have any update about the adaptation?

[dennis4lora]

@michcfr

Sorry for my so late response. 😢

About how to implement MQTT supporting, I have some different opinion now: The data needs not to choose either UDP way or MQTT way, but instead it can/should go both ways. MQTT should be an add-on to the original UDP way. This makes more sense and is more useful for reality cases.

And I also started work on it today and had the first commit. I have to hard code the MQTT server address and Topic, but at least the gateway can receive mqtt messages and display it now.

This commit is in branch esp-idf-v5.x since I plan to upgrade esp-idf soon, but I also want to release v0.9 first before merge that branch.

I hope to improve mqtt function in the coming days (or weeks). Any questions, please don't hesitate to ask. 😄

[michcfr]

@michcfr

Sorry for my so late response. 😢

About how to implement MQTT supporting, I have some different opinion now: The data needs not to choose either UDP way or MQTT way, but instead it can/should go both ways. MQTT should be an add-on to the original UDP way. This makes more sense and is more useful for reality cases.

And I also started work on it today and had the first commit. I have to hard code the MQTT server address and Topic, but at least the gateway can receive mqtt messages and display it now.

This commit is in branch esp-idf-v5.x since I plan to upgrade esp-idf soon, but I also want to release v0.9 first before merge that branch.

I hope to improve mqtt function in the coming days (or weeks). Any questions, please don't hesitate to ask. 😄

Thank you Dennis, that's a great news :-)

I agree, UDP and MQTT are complementary. Do you plan in the future to create a config file to store MQTT related paramters: server address, topic, login/pwd...? How will be "activated" the MQTT add-on for the UDP way (#define? config file?...)?

again thank you for your attention

[dennis4lora]

Yes, I'd like to use #define ENABLE_MQTT to enable/disable the whole MQTT feature on the project. And need to provide a way to change mqtt related parameters on the web UI (which is a relative big work and won't be available soon).

I will work on it step by step. Here is the 2nd commit to send status and rxpk messages to MQTT server...