request telemetry - with guest password #8

New Issue

2026-10-05T06:08:48+02:00

adam commented

2026-10-05 06:08:48 +02:00

Hi,
how is the syntax for requesting telemetry if the repeater got a guest password?

Hi, how is the syntax for requesting telemetry if the repeater got a guest password?

adam commented

2026-10-05 06:08:49 +02:00

/opencode can you investigate this please

/opencode can you investigate this please

adam commented

2026-10-05 06:08:50 +02:00

Based on my investigation, I found that the current send_telemetry_req command implementation in the MeshCore MQTT Bridge does not support guest password parameters. Here's what I discovered:

Current Implementation

The bridge only supports a basic send_telemetry_req command with a destination parameter:

{"destination": "node123"}

Guest Password Requirement

For repeaters with guest passwords, the MeshCore library requires a two-step process:

First login with the password using send_login(destination, password)
Then request telemetry using send_telemetry_req(destination)

Recommended Solution

To support telemetry requests from repeaters with guest passwords, the bridge needs to be enhanced with:

New send_login command for authentication
Enhanced send_telemetry_req command with optional password parameter

Proposed Implementation

New login command:

{"destination": "repeater_node", "password": "guest_password"}

Enhanced telemetry command:

{"destination": "repeater_node", "password": "guest_password"}

The bridge would automatically handle the login → telemetry request sequence when a password is provided.

Would you like me to implement this enhancement to support guest passwords for telemetry requests?

opencode session | github run

Based on my investigation, I found that the current `send_telemetry_req` command implementation in the MeshCore MQTT Bridge does **not** support guest password parameters. Here's what I discovered: ## Current Implementation The bridge only supports a basic `send_telemetry_req` command with a `destination` parameter: ```json {"destination": "node123"} ``` ## Guest Password Requirement For repeaters with guest passwords, the MeshCore library requires a **two-step process**: 1. **First login** with the password using `send_login(destination, password)` 2. **Then request telemetry** using `send_telemetry_req(destination)` ## Recommended Solution To support telemetry requests from repeaters with guest passwords, the bridge needs to be enhanced with: 1. **New `send_login` command** for authentication 2. **Enhanced `send_telemetry_req` command** with optional password parameter ### Proposed Implementation **New login command:** ```json {"destination": "repeater_node", "password": "guest_password"} ``` **Enhanced telemetry command:** ```json {"destination": "repeater_node", "password": "guest_password"} ``` The bridge would automatically handle the login → telemetry request sequence when a password is provided. Would you like me to implement this enhancement to support guest passwords for telemetry requests? <a href="https://opencode.ai/s/wASE2SJW"><img width="200" alt="New%20session%20-%202025-11-16T22%3A56%3A33.885Z" src="https://social-cards.sst.dev/opencode-share/TmV3IHNlc3Npb24gLSAyMDI1LTExLTE2VDIyOjU2OjMzLjg4NVo=.png?model=zai-coding-plan/glm-4.6&version=1.0.68&id=wASE2SJW" /></a> [opencode session](https://opencode.ai/s/wASE2SJW)  |  [github run](/ipnet-mesh/meshcore-mqtt/actions/runs/19413349073)

adam commented

2026-10-05 06:08:51 +02:00

/opencode Implement this and add appropriate tests

/opencode Implement this and add appropriate tests

adam commented

2026-10-05 06:08:51 +02:00

Validation Failed: {"resource":"Issue","code":"custom","field":"title","message":"title is too long (maximum is 256 characters)"} - https://docs.github.com/rest/pulls/pulls#create-a-pull-request

opencode session | github run

Validation Failed: {"resource":"Issue","code":"custom","field":"title","message":"title is too long (maximum is 256 characters)"} - https://docs.github.com/rest/pulls/pulls#create-a-pull-request [opencode session](https://opencode.ai/s/jLZC2c3i)  |  [github run](/ipnet-mesh/meshcore-mqtt/actions/runs/19413383231)

adam commented

2026-10-05 06:08:52 +02:00

There should also a logoff option

Logon
Telemetry request
Logoff

There should also a logoff option Logon Telemetry request Logoff

adam commented

2026-10-05 06:08:53 +02:00

/opencode The change failed because the PR title was too long. Also, there should also be a logoff option, e.g. logon, send telemetry request, logoff

/opencode The change failed because the PR title was too long. Also, there should also be a logoff option, e.g. logon, send telemetry request, logoff

adam commented

2026-10-05 06:08:53 +02:00

Created PR #17

opencode session | github run

Created PR #17 <a href="https://opencode.ai/s/u3A3HlA8"><img width="200" alt="New%20session%20-%202025-11-16T23%3A14%3A28.003Z" src="https://social-cards.sst.dev/opencode-share/TmV3IHNlc3Npb24gLSAyMDI1LTExLTE2VDIzOjE0OjI4LjAwM1o=.png?model=zai-coding-plan/glm-4.6&version=1.0.68&id=u3A3HlA8" /></a> [opencode session](https://opencode.ai/s/u3A3HlA8)  |  [github run](/ipnet-mesh/meshcore-mqtt/actions/runs/19413581495)

adam commented

2026-10-05 06:08:54 +02:00

@dreimal8 Would you mind testing again? If you are using Docker, switch to the :main tag. If you are happy (as I'm unable to test currently), I'll create a new release. If not, reopen the issue please.

@dreimal8 Would you mind testing again? If you are using Docker, switch to the `:main` tag. If you are happy (as I'm unable to test currently), I'll create a new release. If not, reopen the issue please.

adam commented

2026-10-05 06:08:55 +02:00

I have no permission to reopen the issue.

This was implemented:

    send_login - Login to a repeater with guest password
        Required fields: destination, password
        Usage: {"destination": "repeater_node", "password": "guest_password"}

    send_logoff - Logoff from a repeater
        Required fields: destination
        Usage: {"destination": "repeater_node"}

    Enhanced send_telemetry_req - Now supports optional password for automatic login
        Required: destination
        Optional: password
        Usage: {"destination": "repeater_node", "password": "guest_password"}

And i do not understand how a logoff should work with:
{"destination": "repeater_node"}

When a telemetry request has the password as an optional argument - than the telemetry request with no password looks the same as the logoff command.

And the {"destination": "repeater_node"} still gets the telemetry as an answer.

A proper logoff is needed, as after one successful request i have to wait 5 minutes still i can request telemetry for another repeater. Seems to be the time the companion needs to logoff by itself.

I have no permission to reopen the issue. This was implemented: ``` send_login - Login to a repeater with guest password Required fields: destination, password Usage: {"destination": "repeater_node", "password": "guest_password"} send_logoff - Logoff from a repeater Required fields: destination Usage: {"destination": "repeater_node"} Enhanced send_telemetry_req - Now supports optional password for automatic login Required: destination Optional: password Usage: {"destination": "repeater_node", "password": "guest_password"} ``` And i do not understand how a logoff should work with: {"destination": "repeater_node"} When a telemetry request has the password as an optional argument - than the telemetry request with no password looks the same as the logoff command. And the {"destination": "repeater_node"} still gets the telemetry as an answer. A proper logoff is needed, as after one successful request i have to wait 5 minutes still i can request telemetry for another repeater. Seems to be the time the companion needs to logoff by itself.

adam commented

2026-10-05 06:08:55 +02:00

I'm not an expert on MeshCore, so I might be wrong, but...

Exposing Telemetry from Companion Nodes is controlled in the node settings. You can allow everyone or create an "allow list" of contacts. There is no authorization (e.g. password) to gain access, its either everybody, a specific list of contacts or nobody at all.

As your companion node is directly connected via Serial/TCP/BLE, it is "always logged in". Companion nodes don't have any auth mechanism, you are either connected or not. Repeater nodes do require authorization (e.g. admin or guest), hence the login and logout actions.

For Repeater Nodes, you simply send them a Telemetry request and they response accordingly.

I'm not an expert on MeshCore, so I might be wrong, but... Exposing Telemetry from Companion Nodes is controlled in the node settings. You can allow everyone or create an "allow list" of contacts. There is no authorization (e.g. password) to gain access, its either everybody, a specific list of contacts or nobody at all. As your companion node is directly connected via Serial/TCP/BLE, it is "always logged in". Companion nodes don't have any auth mechanism, you are either connected or not. Repeater nodes do require authorization (e.g. admin or guest), hence the login and logout actions. For Repeater Nodes, you simply send them a Telemetry request and they response accordingly.

adam commented

2026-10-05 06:08:56 +02:00

Please excuse all this—I'm no expert either, and maybe I'm wrong... ;-)

The thing is: I have two repeaters—and when I request repeater A, it responds.
When I request repeater B 30 seconds later, it doesn't respond. Not even after 2 or 3 minutes.
Exactly 5 minutes after repeater A has sent its response, I can request repeater B, and it responds as well.

I changed the order – first request B, then A. Makes no difference! If I want to request data from a repeater, there MUST be a 5-minute interval between queries – otherwise the second one doesn't respond.

So I thought that I was still logged in to the first repeater – and that it automatically logs out after 5 minutes. But I'm not sure if that's the problem.

When I use the CLI, I can log in to repeater A with the guest password, request the battery, log out, and do the same with repeater B the next second.

So I thought it was a logout problem with the first repeater – and that something like a timeout would fix it after 5 minutes.

As i only have to request a few repeaters - i can do it in 5 minutes steps - no problem. But would be nice if there where a solution for that.

Please excuse all this—I'm no expert either, and maybe I'm wrong... ;-) The thing is: I have two repeaters—and when I request repeater A, it responds. When I request repeater B 30 seconds later, it doesn't respond. Not even after 2 or 3 minutes. Exactly 5 minutes after repeater A has sent its response, I can request repeater B, and it responds as well. I changed the order – first request B, then A. Makes no difference! If I want to request data from a repeater, there MUST be a 5-minute interval between queries – otherwise the second one doesn't respond. So I thought that I was still logged in to the first repeater – and that it automatically logs out after 5 minutes. But I'm not sure if that's the problem. When I use the CLI, I can log in to repeater A with the guest password, request the battery, log out, and do the same with repeater B the next second. So I thought it was a logout problem with the first repeater – and that something like a timeout would fix it after 5 minutes. As i only have to request a few repeaters - i can do it in 5 minutes steps - no problem. But would be nice if there where a solution for that.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/meshcore-mqtt#8