Hey, I've been trying to get bidirectional communication working with meshcore-mqtt but I'm running into an issue where commands I publish to MQTT topics just don't seem to do anything.
What I'm running
meshcore-mqtt v0.1.1 from main branch
Python 3.13.7
Two MeshCore devices with Companion firmware over serial
Mosquitto broker
Running on NixOS
What works
The bridge is working great for receiving messages from the mesh network. I can see all the messages coming through from other devices, and they're published to MQTT topics perfectly. The connection is solid and events like CONTACT_MSG_RECV, CHANNEL_MSG_RECV, etc. all show up.
What doesn't work
When I try to send commands via MQTT, nothing happens. I've tried:
But that's it. There's no indication that the command gets parsed, queued, or sent to the device. Looking at the startup logs, I see the bridge subscribing to MeshCore events like DEVICE_INFO and CONTACT_MSG_RECV, but I don't see any subscription to the command topics.
Is this implemented yet?
The README makes it sound like sending commands should work, but from what I can see in the logs, the MQTT worker receives the message but never does anything with it. Is the MQTT → MeshCore direction actually implemented in 0.1.1, or is this still a work in progress?
I can confirm the devices themselves work fine - I can send commands directly via serial using meshcore-cli without any issues. It's just the MQTT command processing that seems to be missing.
Let me know if you need any other details or logs. Sorry in advance if the issue is on my side.
Hey, I've been trying to get bidirectional communication working with meshcore-mqtt but I'm running into an issue where commands I publish to MQTT topics just don't seem to do anything.
## What I'm running
- meshcore-mqtt v0.1.1 from main branch
- Python 3.13.7
- Two MeshCore devices with Companion firmware over serial
- Mosquitto broker
- Running on NixOS
## What works
The bridge is working great for receiving messages from the mesh network. I can see all the messages coming through from other devices, and they're published to MQTT topics perfectly. The connection is solid and events like CONTACT_MSG_RECV, CHANNEL_MSG_RECV, etc. all show up.
## What doesn't work
When I try to send commands via MQTT, nothing happens. I've tried:
```bash
mosquitto_pub -h localhost -t 'node1/meshcore/command/device_query' -m '{}'
mosquitto_pub -h localhost -t 'node1/meshcore/command/send_chan_msg' -m '{"channel": 0, "message": "test"}'
```
The logs show the MQTT worker is receiving these messages:
```
MQTT: Received PUBLISH (d0, q0, r0, m0), 'node1/meshcore/command/device_query', ... (2 bytes)
```
But that's it. There's no indication that the command gets parsed, queued, or sent to the device. Looking at the startup logs, I see the bridge subscribing to MeshCore events like DEVICE_INFO and CONTACT_MSG_RECV, but I don't see any subscription to the command topics.
## Is this implemented yet?
The README makes it sound like sending commands should work, but from what I can see in the logs, the MQTT worker receives the message but never does anything with it. Is the MQTT → MeshCore direction actually implemented in 0.1.1, or is this still a work in progress?
I can confirm the devices themselves work fine - I can send commands directly via serial using meshcore-cli without any issues. It's just the MQTT command processing that seems to be missing.
Let me know if you need any other details or logs. Sorry in advance if the issue is on my side.
<!-- github-sync-id:3479037151 -->
Bidirectional communication definitely works, although it is dependent on the Meshcore companion node actually delivering it.
The DEVICE_INFO and CONTACT_MSG_RECV are Meshcore event subscriptions and not MQTT.
Please ensure your Meshcore device is running the USB Companion firmware, not the general one.
Bidirectional communication definitely works, although it is dependent on the Meshcore companion node actually delivering it.
The `DEVICE_INFO` and `CONTACT_MSG_RECV` are Meshcore event subscriptions and not MQTT.
Please ensure your Meshcore device is running the USB Companion firmware, not the general one.
<!-- github-comment-id:3403391575 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Hey, I've been trying to get bidirectional communication working with meshcore-mqtt but I'm running into an issue where commands I publish to MQTT topics just don't seem to do anything.
What I'm running
What works
The bridge is working great for receiving messages from the mesh network. I can see all the messages coming through from other devices, and they're published to MQTT topics perfectly. The connection is solid and events like CONTACT_MSG_RECV, CHANNEL_MSG_RECV, etc. all show up.
What doesn't work
When I try to send commands via MQTT, nothing happens. I've tried:
The logs show the MQTT worker is receiving these messages:
But that's it. There's no indication that the command gets parsed, queued, or sent to the device. Looking at the startup logs, I see the bridge subscribing to MeshCore events like DEVICE_INFO and CONTACT_MSG_RECV, but I don't see any subscription to the command topics.
Is this implemented yet?
The README makes it sound like sending commands should work, but from what I can see in the logs, the MQTT worker receives the message but never does anything with it. Is the MQTT → MeshCore direction actually implemented in 0.1.1, or is this still a work in progress?
I can confirm the devices themselves work fine - I can send commands directly via serial using meshcore-cli without any issues. It's just the MQTT command processing that seems to be missing.
Let me know if you need any other details or logs. Sorry in advance if the issue is on my side.
Bidirectional communication definitely works, although it is dependent on the Meshcore companion node actually delivering it.
The
DEVICE_INFOandCONTACT_MSG_RECVare Meshcore event subscriptions and not MQTT.Please ensure your Meshcore device is running the USB Companion firmware, not the general one.