Question

I realized my question was of a more general nature than as a specific sub-question

we referenced this document:
MQTT User Guide Addendum - Thingsboard.io (Updated 7-Nov-2022)

which specifically refers to Control Solutions Babel Buster IoT gateways now support Thingsboard.io MQTT services.
We followed the bouncing ball in that document as far as configuring the thingsboard  device, but no joy...
Some generic questions I am unclear about...
Is there any way to identify whether the Teltonika RUT has received and attempted to act upon the RPC get/set request ?

Variable names are implicitly created when labelling read-requests and write-requests.  Is there any way to inspect the value of a variable in the RUT ?  Of course there is the Test function, which explicitly forces a read or write, and in the case of a read will show the
data returned by the read request, but I have found no way to inspect the current value of a variable.  

Maybe variables don't even exist ? When a read-request is executed, the associated tag is prepended to the data and that's it ?
Does the modbus address need to be fully bi-directional for RPC to succeed?
For example  the DeepSea mode-setting registers are Write-only.
I can envision the situation that both set and get need to be actionable, and hence RPC to a unidirectional modbus register may fail
In which case the deeper question is how to implement/hack RPC to a situation where the control register is separate from the status register ?

We are looking for some R/W registers (such as possibly RPM)  to which we will first configure read access
and then configure it as an RPC device.

We notice that the RUT955 can act as a "MQTT Gateway".
What exactly is required for that ?  On the face of it, I assume that means that the RUT does not process the MQTT requests
itself but passes them on to a device which can do the MQTT itself.  
What would be a typical communication method for that ?
We currently usually use Modbus RTU or TCP for the RUT to communicate to the end-device.
When the RUT is acting as an "MQTT gateway", how are the requests communicated from RUT to end-device ?

Can JSON also be used for RPC ?  Our impression is that it is much more complex/convoluted
and that MQTT is the preferred means.

Comments

I am continuing to dig around looking for how RPC is supposed to work 
Confusing as heck..
today I found this stuff:
 

MQTT is a PUB/SUB system and doesn't lend itself well to RPC. While you could possibly shoehorn something on top of MQTT to simulate the synchronicity required, you are probably better off looking for a system which provides real RPC semantics.

That said, depending on your application, you can subscribe to multiple MQTT topics and simulate round-trip communication by PUBlishing on one topic and listening for a response on a second topic. Note though, that this is by nature not synchronous.

For example, you could PUBlish a "question" to topic/query and expect a response on topic/response.

and

@Gargamel The best way to think of MQTT is as a network level IPC for your applications that need a last will messaging, QoS for message queues, and/or one to many messages. While RPC calls are the other way around being many to one messaging and should be handled over a json based RESTful API. Distributed computing is more about Boinc/OpenMPI/Beowulf/Hadoop clustering systems. Namely large data crunching.

– Dwight Spencer

 Jun 15, 2015 at 3:05

Add a comment

0

There are some packages built on top of mqtt that may do what you want. One such example for node.js is mqtt-json-rpc, which mimics RPC over some other WAMP-style stacks like Crossbar.io.

https://www.npmjs.com/package/mqtt-json-rpc

The more I dig, the deeper and wider the hole gets, but no actual functional answers/solutions

Answer 1

Be advised, that the RUT955 is supported by "official" openwrt. Which allows complete custom setup, which I did for a large, commercial IoT project in the USA, having more than hundred devices installed, currently:

MQTT from RUT955 to AWS IoT, auto-failover between wan, wwan, wifiwan. Data queing in case of no internet. Remote config of both the RUT and low level sensors. VPN via wireguard. Low level sensors/switches connected via ModBus/RTU. Of course, writing/reading blocks of registers. Remote firmware updates. Pre-processing of sensor info, i.e. Modbus-polling and only mqttt msg in case of signal change; custom GUI (PHP) for some local config changes ...

Reasons to do own stuff: Higher availability and privacy, because indepence of RMS; newer kernels and packages; vendor-independence regarding hw; complete  freedom of software customization; wide community support, because completely open source.

Comments

It is not clear to me how this answer is relevant to our specific problem.
I comprehend that complex applications which embed advanced technologies
which are not available using the out-of-the-box environment provided by Teltonika UI may best be achieved with DIY solutions built on bare-metal Open-WRT - particularly when unlimited R&D funding is available.
Our application is on the trivially-simple end of the spectrum...
Most of what we require is already in-hand.  All of the IoT -> portal dashboard stuff works fine
We simply seek to de-kink the RPC stuff to enable the portal dashboard -> IoT comms & control.