Question

To control a DeepSea controller operating mode, simultaneous writes of two 16bit words into contiguous registers is required.
I've fiddled around but can't quite figure out the syntax for expressing that.
I can do the required operation with ModbusPoll, and verified the functionality

I now need to code that into Teltonika-speak

Thanks

Comments

OK... with sufficient fiddling, I figured it out...

* DeepSea Control Registers are 4105/4106 in Teltonika land

* use  32bit UINT 3,4,1,2 data type to write both 4105/6 16bit registers

* must use modbus function 16 write multiple even though writing only 1 value

* Register 4105 is specified in the Teltonika modbus config

* the register count field becomes value field when writing

(DeepSea supports only modbus function 3 and 16)

i.e. for STOP the command word into 4105 is  35700 and the 2's complement into 4106 is 29835

the 32bit UINT value required is 29835 << 16 + 35700 =  1955302260

 

---

Yes indeed there are further issues - specifically with MQTT / RPC control of said DeepSea controller

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 ?
Does the modbus address need to be fully bi-directional ?
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.

Answer 1

Hello,

  

As I understand the issue is resolved.

Let us know if you experience any further issues.

   

Best regards,
DaumantasG