Thingsboard: Get 408 error when send server side RPC call to device

[hguomin]

Hi team,

I follow this document: https://thingsboard.io/docs/user-guide/rpc/#server-side-rpc-api to send server side rpc to device, but always get the 408 error code when sending the http post request, is there any issues in this api call? thanks.

[ashvayka]

Are you sure that device is listening to this RPC call and sends the response back?
Otherwise, you will get 408. Alternatively, you can use oneway RPC call.

[ralienpp]

I have observed the same thing. We send a one-way request from Thingsboard 1.3.0, I have checked that the corresponding HTTP header is present X-Authorization: "Bearer xxxxxxxx.....xxxxx.

The listening device is subscribed to the corresponding MQTT topic v1/devices/me/rpc/request/+. On the client's end, I see no incoming MQTT message at all. Note that the client successfully publishes telemetry and attributes over MQTT and this information arrives to the server and is displayed in the dashboard correctly.

1. Which server-side log can I look into, to get more details about the problem?
2. What other troubleshooting tips do you recommend?

p.s. I also tried it with the standard GPIO control widget, just to be sure that it has nothing to do with my custom widget. The behaviour is the same, I see a two-way POST request in the browser's log, but nothing arrives to my MQTT client.

[aderbas]

Same problem here, I'm using a module Wemos NodeMCU with lua. I send telemetry or atributes like a GPIO status pin, but my module do not receive anything from the broker.

...
m:connect(host, port, function(client) 
   client:subscribe("v1/devices/me/rpc/request/+", 0, function(client) print("Subscribe OK") end)
   client:publish("v1/devices/me/attributes", att, 0, 0, function(client) print("Data sent") end)
end,
function(client, reason)
   print(reason)
end)
...

But the dashboard or RPC API can not reach my device. I tried to see if it was network problem, but in Raspberry Pi works perfectly.

[ssmaurya]

Check that device is not disconnecting after sending the telemetry or attributes. Device has to be in connected state and should have subscribed to apt topics to receive rpc or shared attributes updates

[ralienpp]

According to my client-side log, the connection is established and maintained. With netstat or tcpdump I see that it is indeed the same TCP connection that is being used.

So I am very confident that the transport layer connection is up and stable.

[hguomin]

@ashvayka Yes, in my case what I used is one-way RPC call and the device is connected to the server, not two-way.

[ralienpp]

I just ruled out another possible explanation. I was using QoS 2 (exactly once) for my subscription, but the docs say that Thingsboard supports only QoS 0 and 1.

https://thingsboard.io/docs/reference/mqtt-api/#mqtt-basics

Thingsboard server nodes act as a MQTT Broker that support QoS levels 0 (at most once) and 1 (at least once) and a set of predefined topics.

Well, I can tell you that this behaviour is not related to the QoS settings.

[ralienpp]

Alright - I got it.

In my code (using paho for Python) I used to declare the subscriptions and then connect to the server. This used to work in the past - but now it doesn't.

I adjusted the code such that the subscription is performed after the connection was established. In this case, the RPC call returns status 200.

I am not sure if this is a bug or a feature, but I need to point out that for my entire life I've been declaring the subscriptions beforehand and it worked with other brokers (e.g. Mosquitto and RabbitMQ's MQTT plugin).

[ssmaurya]

Subcriptions generally should be done after connection, otherwise there will be no way to say if subscription is valid one or not. I think its by design in thingsboard.

[ashvayka]

This is actually by MQTT design, not a TB specific. Closing this as invalid.

[mbari]

I have faced the same problem with thingsboard, my device is unable to subscribe and is not receiving rpc messages from thingsboard. I have tested it on mosquito and works fine. I have tested thingsboard with a python script using paho and it works. The sim800l- arduino combo sends a connection request, it is accepted and then it proceedes to subscribe to the rpc topic, this packet is not acknowledged and times out after some time. I thought I had malformed packets but I went ahead and used wireshark and confirmed that the data packets are exactly similar and therefore this could be a bug on the thingsboard implementation. see attached a screenshot of the wireshark vs arduino data packets.

Please share the solution you found.

the issue had also been raised here by me before finding this thread

[ssmaurya]

Try increasing timeout parameter in rpc shell. We had faced similar issue and increasing timeout solved the issue

[mbari]

@ssmaurya increasing timeout did not help

[karlp]

I'm still seeing this, with a one way connection, there shouldn't be any reply from the remote device anyway. Further, the response code 408 is not documented in the swagger-ui. As best I can tell, this was caused by attempting to subscribt to v1/devices/me/rpc/requests/# instead of /+

At the very least, documented the 408 code would be helpful please.