Question 38794 in Ubuntu Question posted in
The official Ubuntu documentation can be found here.

Telemetry does not show up in Thingsboard device dialog ("Hello world" tutorial) – Ubuntu

I installed ThingsBoard CE on premises. I followed

https://thingsboard.io/docs/user-guide/install/ubuntu/

step by step. Installation base is a fresh Ubuntu 22.04 Server install on a virtual host with no other duties. It’s an IPv6-only installation with 127.0.0.1 being the only IPv4 address reachable direcly, other IPv4 targets by NAT64/DNS64. From what I see (e.g. by systemctl), all services (Postgresql, Zookeeper, Kafka, Thingsboard) boot up correctly. I installed Thingsboard with the --loadDemo option in step 6 of the instructions. I can log in using the preinstalled accounts. I’ve changed the passwords. After having checked that things work connecting to localhost:8080, I’ve installed Apache-based reverse proxies for IPv6 and IPv4 connectivity. This all works.

Next, I continued with the "Hello world" tutorial in

https://thingsboard.io/docs/getting-started-guides/helloworld/

I fire the mocked telemetry transmission using curl:

root@thingsboard:~# curl -v -X POST -d '{"temperature": "24"}' http://localhost:8080/api/v1/xxx/telemetry --header "Content-Type:application/json"

On HTTP level, this seems to work:

*   Trying 127.0.0.1:8080...
* Connected to localhost (127.0.0.1) port 8080 (#0)
> POST /api/v1/xxx/telemetry HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.81.0
> Accept: */*
> Content-Type:application/json
> Content-Length: 21
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 
< Vary: Origin
< Vary: Access-Control-Request-Method
< Vary: Access-Control-Request-Headers
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Pragma: no-cache
< Expires: 0
< Content-Length: 0
< Date: Wed, 26 Oct 2022 04:33:32 GMT
< 
* Connection #0 to host localhost left intact

I do not see, however, the telemetry data in the "Latest telemetry" tab of "My new device" in the tenant’s "Devices" dialog. I tried

  • Sending the data remotely via the reverse proxy or directly to localhost:8080
  • Sending via IPv6 or IPv4
  • Replacing the Kafka queuing with in-memory queuing by disabling the Kafka-config lines in thingsboard.conf.

Nothing changed the behaviour a bit. However, making it syntactically incorrect JSON or using a wrong crendential lead to different error result codes so Thingsboard is actually processing the message.

I cannot see anything in the tenant’s "Api usage" dialog either as there are only spinning wheels in subframes.

And that’s where I am stuck at the moment. I don’t have an idea where to look for the problem as I don’t even know where I possibly could look.

Can anyone help me?

Best regards,
Dirk

Tags:

2

Answers


  1. Chosen as BEST ANSWER
    0

    As often, the problem was at a completely unexpected location: It turned out that ThingsBoard actually processed the events perfectly but my reverse proxy was misconfigured. This was also the reason for

    I cannot see anything in the tenant's "Api usage" dialog either as there are only spinning wheels in subframes.

    I use Apache as reverse proxy. It needs the proxy, proxy_html and proxy_wstunnel modules enabled and the following configuration (assuming it runs on the same machine as ThingsBoard):

    # close off proxying while allowing reverseproxy
ProxyRequests Off
# pass header information through to the proxied host
ProxyPreserveHost On

# mod_proxy_wstunnel for the data websockets
ProxyPass /api/ws/ ws://localhost:8080/api/ws/

# "normal" http reverse proxy
ProxyPass /        http://localhost:8080/
ProxyPassReverse / http://localhost:8080/

    Now I see the telemetry, I have the dashboards and I can finally continue following the tutorials.

    May I suggest the the on-premises installation instructions at least mention this configuration need? It's a trivial pitfall but it can be really frustrating if you forget it and get no hint that there is a problem.


  2. 0

    To confirm that the telemetry has correctly reached the device that you have indicated in the post url (/api/v1/xxx/telemetry), you have to set up debug mode in rule chain nodes: https://thingsboard.io/docs/user-guide/rule-engine-2-0/overview/#debugging

    All devices messages by default is going to root rule chain, set up debug mode in "Message Type Switch" node and send the same request again, then check events of that node.

    If everything goes fine, the output of "Message Type Switch" must be "Post telemetry"
    rule chain

    "Save Timeseries" is the node that is responsible for saving telemetries.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search