Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[Bug] TBMQ Sessions Tab does not show #129

Closed
gaizkasi opened this issue Jun 20, 2024 · 14 comments
Closed

[Bug] TBMQ Sessions Tab does not show #129

gaizkasi opened this issue Jun 20, 2024 · 14 comments
Assignees
@dmytro-landiak

Comments

@gaizkasi
Copy link

In the latest weeks I have been testing TBMQ as a possible integration for my Thingsboard Professional instance.

I used Basic Auth configuration enabled and mosquitto_sub and mosquitto_pub locally in order to see how the UI interface shows connections or messages. While I was testing I found that the UI does not work as I expect and they might be bugs:

  • I created DEVICE TYPE credentials for testing and subscribed it to TBMQ by command to check connection. Subscription works. I connected and it checks if it is still alive by PING. Unfortunately, I could not find this connection in sessions tab.

  • In addition, just in case, I executed another mosquitto command to publish Hello World message through Broker for subscribed topic. Subscription command delivers properly the message. Both session nor message are not available in UI.

I attach screenshots of what is happening below.

What is happening? Is it a bug? Could you help me?

  • Deployment: Docker Cluster in Linux Server
  • TBMQ version: 1.3.0
  • OS name and version: 4.19.0-26-amd64 Added hld.md #1 SMP Debian 4.19.304-1 (2024-01-09) x86_64 GNU/Linux

This is what I used to open TBMQ UI in the browser:

  • OS: Windows 10
  • Browser: Firefox
  • Version 127.0

I simulate a device using Mosquitto command in the same server in what TBMQ is running.

  • Connectivity: MQTT

Steps to reproduce the behavior:

  1. Create DEVICE credentials.
  2. Subscribe with Check Connection example command.
  3. Check if a sessions is open in Sessions Tab.
  4. Try to publish a message by mosquitto command to the same topic which is subscribed.
  5. Check if a sessions still does not appear.

The sessions should appear in TBMQ UI as well as the incoming messages.

Screenshots
Credentials
Subscription
PUB
PublishInSUB
Sessions
MessageMonitoring
@dmytro-landiak
Copy link
Contributor

hi @gaizkasi !

Thank you for raising this issue.

Please verify whether the Mosquitto broker is running, as it appears the messages might be directed there instead of TBMQ. To check this, modify the credentials (username/password) for your mosquitto_pub and mosquitto_sub commands to invalid ones for TBMQ. If the clients are connecting to TBMQ, you should see an "unauthorized" error. However, if the connections are successful and messages are being transferred, it likely means they are being sent to the Mosquitto broker.

The Mosquitto broker might be running from the setup process of the Mosquitto client.

If this is the case, please ensure the Mosquitto broker is stopped and then reproduce your steps.

If you have any more questions, please let me know.

Regards!

@gaizkasi
Copy link
Author

gaizkasi commented Jun 20, 2024 via email

@dmytro-landiak
Copy link
Contributor

@gaizkasi could you point me to the instruction guide you used for tbmq deployment?

is it this one - https://thingsboard.io/docs/mqtt-broker/install/docker/?

@gaizkasi
Copy link
Author

gaizkasi commented Jun 20, 2024 via email

@dmytro-landiak
Copy link
Contributor

dmytro-landiak commented Jun 20, 2024 •
edited
Loading

@gaizkasi,

There are no known issues related to this matter, so the problem likely stems from a misconfiguration on your host machine.

Could you meanwhile try to use the WebSocket client and connect the default connection to TBMQ:
image

Note, that you do not need to update the details of the connection in case the default installation steps were used.

Then check if the client session appears in the Session tab.

@gaizkasi
Copy link
Author

@dmytro-landiak

Firstly, this interface reports me always this message:
irudia

But, if I close it and I try to create new connection then, despite it does not appear in WebSocket client tab, credentials are created:
irudia

But, I do not know how to do there...

@dmytro-landiak
Copy link
Contributor

@gaizkasi,

It seems there might be issues with the DB schema and tables. Did you upgrade from a previous version of TBMQ to 1.3.0? That could explain the issue. Did the upgrade process complete successfully?

Please provide the TBMQ logs with the error message for the confirmation.

If this is a development server, I recommend redeploying TBMQ from scratch. Ensure you remove the data storage volumes first, as a new installation won't occur otherwise.

image

@gaizkasi
Copy link
Author

Hi @dmytro-landiak !

I solved the error reinstalling again everything. Now I could work in WebSocket screen but, I try to connect and it reports always reconnecting.

irudia

Now, after upgrade to 1.3.0 I have got TBMQ WebSockets MQTT Credentials created by default. I've followed the basic guide of TBMQ and I've created new credentials for Getting Started Credentials, step by step. This is the link: https://thingsboard.io/docs/mqtt-broker/getting-started/

irudia

But when I used this commands in the server the sessions tab does not change, there is nothing there:

irudia

It is unbelievable how such a simple tasks does not work. It is impossible for me to identify what I'm doing wrongly...

@dmytro-landiak
Copy link
Contributor

@gaizkasi,

Could you please try to use the following command and show me the screenshot of the console as you showed above?

mosquitto_pub -d -h localhost -p 1883 -t sensors/temperature -m 32 -q 1 -u wrongusername -P password

@gaizkasi
Copy link
Author

This is the result...

irudia

@dmytro-landiak
Copy link
Contributor

as I can see the message is delivered successfully even though the wrong username is used because you do not have the credentials created in the TBMQ with the specified username.

Could you please execute the following command and show the result?

sudo lsof -i :1883

@gaizkasi
Copy link
Author

Hi @dmytro-landiak !

I have solved it... I do not why but, as you guessed, MOSQUITTO was running and the MQTT traffic was going to this broker instead of TBMQ.
I do not understand why UI reports that it was running MQTT Broker at 1883 when the port was using by external mosquitto.
Now I can see the sessions and if I execute the command:
irudia

I stop system service stop I changed in docker compose the port to from 1884:1884 to 1883:1883 and I restart the dockers. I think UI should be changed in order to report the regarding MQTT port, the one that it is configured in docker compose.

Besides, I have got an extra question. It is compulsory to have a credential created by UI before subscribing or publishing or not?

Thank you so much for your help and fast responses!

@dmytro-landiak
Copy link
Contributor

Hi @gaizkasi,

The user interface displays the port configured for the application running inside the container. Currently, it does not detect if the port is forwarded from the host to the Docker container (that's why it shows 1883 instead of 1884 or anything else). We understand this can be confusing and will revisit this issue for future improvements.

In the meantime, you can set the environment variable SECURITY_MQTT_BASIC_ENABLED to false. This will disable authentication for clients and remove the need to create credentials via the UI.

If you have any more questions, please let me know.

Best regards,

@gaizkasi
Copy link
Author

Thank you so much @dmytro-landiak! Every doubt solved, we can close the issue :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@dmytro-landiak dmytro-landiak

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@dmytro-landiak @gaizkasi