Hmm this is what I think about this:
On the device by the gate:
Continuous loop:
-
Switch to transmit mode
-
Check if the gate is open or closed
-
Transmit the result
-
Switch back to receive mode and wait 15 seconds
When a message is received:
-
Run a security check
-
If the message is the Open or Close command, forward it to MQTT
On the device in the car:
Continuous loop:
- Decrease the timer value
When a message is received:
-
Set connection state to connected
-
Enable the Open/Close display and set it to the received state
-
Reset the timer to 45 seconds
If the timer ends:
-
Set connection state to disconnected
-
Disable the Open/Close display
On button press:
-
Stop receiving
-
Generate a secure message (Open or Close)
-
Transmit the message
-
Resume receiving
Option 1: Use an ESP32 with WiFi and a LoRa module near the gate. This device can handle both the LoRa interface and the MQTT push with relatively simple firmware. For the device in the car, WiFi is not needed, so you can choose any microcontroller and a LoRa module.
For the interface, LEDs are the simplest. Map the GPIOs to four LEDs (Red, Green | Red, Green). For example:
-
Red and Off = Disconnected
-
Green and Red = Connected and Closed
-
Green and Green = Connected and Open
Two more GPIOs in input mode can handle the two physical buttons for Open and Close.
If you want a screen, there are many options. You can use a small OLED, touch screen, or colored E-Ink. The choice depends on whether the car device is battery powered or has constant power, and how much complexity you want in the code.
Option 2: Use Meshtastic. The device by the gate can be connected to something like a Raspberry Pi, and a Python script can process incoming messages and handle the heartbeat transmissions. Meshtastic gives you some built-in security, but you still need to be careful. The difficulty is keeping track of the connected state and the Open/Close state from the heartbeat, and then mapping that to a display or LEDs. That would probably require customizing Meshtastic firmware.
Because of that, I think writing custom firmware is easier than trying to adapt Meshtastic for this use case. BUT - I have not been keeping up to date with the newest Meshtastic versions, and I don't know all of the sensor-related features. So it is possible that there is already some built-in method that replicates this and I just don't know about it.