Downlink to TagoIO MQTT relay issue?

TagoIO Devices and Connectors
1

Hi,

I have installed TagoIO relay and Mosquitto broker on an AWS EC2 instance, and am using DNS service.
I am able to forward MQTT uplinks from my device to TagoIO using this setup, but am not able to get downlinks through.

I made this test script:

**********************************************

import { Analysis, Network } from “jsr:@tago-io/sdk”;

const network = new Network({
token: “9c0c4050-d679-47aa-a*********”,
});

async function run(context) {
// Publish to Relay: topic and payload for your external broker

await network.publishToRelay({
device: “68c91a3d19a78f*******”,
topic: “device/down/1026”,
message: “test”,
options: { qos: 0 }, // optional

});

console.log(“Published via Relay”);
}

Analysis.use(run);

*******************************************************************************

The log shows this result:

******************************************************************************

[2025-10-28 14:21:47] Starting Analysis…

[2025-10-28 14:21:47] error: Uncaught (in promise) “Error on Relay: Request failed with status code 404 Not Found: https://test1395.xxxxx.xxx/publish”

[2025-10-28 14:21:47] [TagoIO Analysis] Error executing Deno analysis: 1

*******************************************************************************

I see that the network middleware is correct (test1395.xxxxx.xxx), but would have expected the port 3001 to be included, otherwise it will not reach the relay, I think?

In another script and from postman I tested a direct fetch on https://test1395.xxxxx.xxx:3001/publish when setting the relay in unsafe mode, and then the relay receives the downlink.

If I try to set the middleware address in the network to test1394.xxxxx.xxx:3001, it will not save.

Could it be that there is an issue in the publishToRelay() function, such that it fails to include the port 3001?

2

Hello @arturcarvalho
Thank you for flagging the issue with the Middleware Endpoint. We’ve reproduced the behavior on our side: your service requires a port in the network domain, and our API is currently not accepting ports as part of that field.

Our engineering team is already working on this. We’ll update you as soon as support for ports in the network configuration is available.

In the meantime, if a temporary workaround would help, two common options are:

  • Using a reverse proxy or load balancer on a standard port (80/443) that forwards traffic to your service port.
  • Updating DNS to point to a service that terminates on 80/443 and routes to your target port internally.
3

Hi Vitor,

Ok, thank you for your update and proposal for workaround.

Looking forward to a quick resolution of this issue.

Kind regards,

Arthur

4

Good news @akimmels6969!

The issue with the Middleware Endpoint has been fixed.

Our API now fully supports ports in the network configuration field, so everything should be working normally again.

Thanks for reporting it and for your patience!

Best Regards,

Carolina