8298 questions

9759 answers

15542 comments

13863 members

–7 votes
2,178 views 4 comments
by
This product is most mizerable product that i ever used.

I see a lot of instructions with SUDO command but this function is not available. Mosquitto subscriber it does not work. Modbus gives request time out. JSON RPC gives  gives sometimes request time out.

This product should be retired from market and R&D in charge people should be fired.

It is waste of time using and hopping that this product will work properly ever.

1 Answer

+6 votes
by

Hi,

There's no sudo in RUTs, because when you login via SSH you are already root and have full privileges. So just omit sudo from your commands.

If you want help with the device you should provide more information on what you're testing, how, which firmware version you're using and under what circumstances you encounter these errors/bugs. I know that Modbus works because I used it recently, but you haven't exactly described what didn't work for you. Same goes for MQTT and JSON.

by

1. You are right, sudo function is not need but you  do instructions all elated with this command.

You made detailled instruction but are not corelated with real products.

For instance you ask here to install mosquitto publisher https://wiki.teltonika.lt/view/Monitoring_via_MQTT 

apt-get function is also not working on RUT.

Why we need to install a publisher if RUT955 already had MQTT Publisher described in here https://wiki.teltonika.lt/view/MQTT  ?

Once again, how the instruction from here https://wiki.teltonika.lt/view/Monitoring_via_MQTT  it should work in real life on RUT 955 and and is the fw it should work. You always ask what is the fw . Let me know wht is the fw version and how MQTT publisher works. MQTT broker is validate, it works (FW ver.: RUT9XX_R_00.06.02)

2. MODBUS -  you made here instruction for MOdbus register read from RUT955 with linux terminal https://wiki.teltonika.lt/view/Monitoring_via_Modbus  if modbus TCP is enabled on port 502 for remote also   it gives request time out to any try of modbus register read with any MODBUS tool.

3. Your company made verry good instruction on JSON RPC in here https://wiki.teltonika.lt/view/Monitoring_via_JSON-RPC . This is working but because JSON-RPC works toghether with HTTP or HTTPS service then it performance is verry low. We cannot go below 120 second s of reading cycle trought JSON-RPC. Ihave monitored on few equipments it`s response to ping and HTTP service. IF ping response is 200ms then HTTP service response varry from 900 to 2500 ms.

Considering JSON-RPC fails because of bad HTTP service we looked for alternative solutions on MODBUS and MQTT publisher, service that tuned to be fake or nonexistent service, except the user manual.

I see a lot of topics related to this issues but it turns that after you are finished with solutions for dummies that you copy and paste from a sword of book, the topic end`s with no solutions.

With all respect  but i fallow the fw changes starting with RUT9XX_R_00.04.153 | 2018.03.16 but no improvements to consider this product an products you can rely. For home use it is ok if you have that patience that when it is not working to power off and on 

by

1. The article is intended to provide instructions of using MQTT between RUT and a Linux PC. No need to install anything else on the router, the commands are meant to be used on the PC side. From the article:

"Once the Broker is up, you'll need install Mosquitto and Mosquitto Clients. To do so, open the Linux Terminal app and enter this command:

$ sudo apt-get install mosquitto mosquitto-clients
" 

So the program is meant to act as the MQTT publisher on the PC. This is an example for testing and to understand the capabilities of MQTT on RUTs. I imagine that in reality everyone would use their own MQTT software, so the PC related steps aren't even mandatory.

But I see your point. I'll see what can done to make the guide more intuitive and understandable.

2. I tested remote Modbus TCP access on port 502 with RUT9XX_R_00.06.2 FW and it works as expected. It should be noted that usually a SIM card with a public IP address is required for such remote actions. But not always. For example, if you use an Ethernet (wired) connection as your WAN, you can still test remote access from the same wired network even with a private IP, since the router considers everything coming from a WAN interface as a remote connection.

My test was pretty simple, tell me if I missed something:

3. Would have to do extensive testing on the performance of JSON-RPC to provide any meaningful comment. I have, however, heard of a very similar case where Teltonika's testing department were not able to reproduce the issue. Perhaps some information is missing? Can you describe your testing method in detail so that I can try it myself of give it to Teltonika's testers for thorough analysis?

Yes, most configuration example articles are pretty basic and intended for simple solutions or to be used as overviews of certain functions and their capabilities. In reality, pretty much every solution is different depending on the user, their equipment and other circumstances, so it is near impossible to encompass every possible situation within the documentation. If you have a suggestion for a solution that you would like to see on the Wiki, you can send the information and I'll see what I can do to make it happen.

I'm sorry your experience has been negative thus far. Have you gotten direct support from Teltonika? Where did you purchase the device? You may want to contact your vendor to see if they get direct support from Teltonika. If you have observations like this or encounter bugs, usually the fastest, most effective may to deal with this is contacting the support team (via your vendor; if they provide such a service).

by

1. i understand that instructions are to prove MQTT Broker functionalities  and i can confirm also that broker is working, at least for unsecured connections. MQTT Publisher is not working in accordance to this instruction https://wiki.teltonika.lt/view/Monitoring_via_MQTT 

Your examples show and validate only the broker functionality but not the publisher from RUT955.

I may consider the MQTT Publisher when i can see real time values on a MQTT subscriber client, except the so called TERMINAL . Lets see it working NODE-RED.

2. I have give another try to your instructions with TERMINAL but i have got stucked on ruby instalation that gives error on ubuntu.

Any Automation engineers has its own testing tool for different protocol that they used in theyir project.

As it was claimed by other person in here https://community.teltonika-networks.com/4940/modbus-write?show=4940#q4940  i have also tested with MOdbus Tester all register types and adresses. Since i do not see in your example command i have assumed it is MODbus TCP and ID is 1.

In my opinion you do not use MODBUS protocol. I wish to be wrong so i invite you get the MOdbus registers from RUT955 to NODE RED platform.

3. Your collegues from R&D and testing department have all the details . As i mention before my experience with direct support from teltonika rely in questions in red and italic format. The most valueble information i have got so far till know is to make FW upgrate by bootloader .

by

1. RUTs do not support Node-RED.

2. Did over 1000 successful reads without errors or timeouts:

I think the problem is that you're trying to read 10 registers. This feature is not yet available, but it will be in the next firmware.

3. I've looked into this further and found your cases. You have two tickets on Teltonika's Helpdesk. One of them was closed automatically (where you ask about the JSON issue), because there was no response for a long time. Your other ticket is still open, but it will also be closed soon, because the last response was a long time ago now. But it's an entirely different case than what you describe here.

So you have access to direct support, but you are not using it. Again, the forum is not the correct media for solving these types of issues, especially when you have a real-life case and guaranteed direct support from the manufacturer (Teltonika). So why not use it? How can you expect a solution from Teltonika when you haven't even registered a ticket and haven't provided all the relevant information?

My suggestion to you is to make a list of every RUT related issue that you have encountered along with all the relevant information and send it to your sales manager. This way the manager will be able to open a ticket on Teltonika's HelpDesk tied directly to the client (you) and it will not be closed until the issue is solved (or it will be closed automatically if no response is received from the client in two week (as it has happened before already with one of your cases)).

Some information about the HelpDesk:

The HelpDesk is an internal Teltonika system used for communication between sales managers and technical support  engineers when solving client issues. Teltonika customers may contact their respective sales managers with  inquiries related to Teltonika products. The sales manager then either provides an answer or registers a query on the HelpDesk, which is later assigned to a technical support engineer who analyzes the question and provides an answer or asks the client for additional information if required.

HelpDesk conditions:

  1. Reaction time to an inquiry is 1-24 working hours from when it was received.
  2. The exact response time will vary depending on the complexity of the question and the client's  status.
    1. If the issue is short term and easy to solve, the answer is usually provided the same day and  some questions may even be answered within the span of an hour.
    2. Higher status clients will receive responses faster than lower status clients.
  3. For simpler inquiries you can always count on the help of your dedicated sales Manager.

HelpDesk issue solving flowchart:

The flowchart doesn't contain one important part: the involvement of the RnD department. If the issue is related to a firmware bug, the engineer relays the information to the RnD department (programmers), who fix the issue and release a new firmware. So the response times may vary greatly depending on the nature of the problem.