Why cannot I run two testAgents(of raspberry pi) at the same time?
When I run them in two separate raspberry pi boards with different deviceIds, when one is connected to the broker other one gets disconnected. Then the next one is connected and 1st gets disconnected... They don't do anything else.
I cannot guess any reason for this and I tried my best to solve this. I tried with same user, different users, same access token, different access tokens. But same thing happened.
They will be using the same MQTT client ID. The broker will always disconnect the first client that connects with a client ID when a second client connects with the same client ID.
The logs from the broker should show this happening.
Related
Previously I have setup a device to connect to Google Cloud IoT Core and when the device would connect it would get a callback from the server to a topic with the device configuration file.
I am currently moving off of that to a local MQTT broker on a Raspberry Pi with Mosquitto running. What I am trying to do is figure out how to replicate the sending of the configuration file when connected.
Is there a way for other clients to know when a new client connects? If so I could then just have a client running on the Pi that would is responsible for sending messages.
The thought was that the Pi would hold the configuration file of the connected device and once it connects it would be sent back over to it via a topic for that device
Or is there another solution that I dont even know about yet that accomplishes this? I have not set up my own end to end MQTT communication before so I dont exactly have a path forward here
Is there a way for other clients to know when a new client connects?
Not as part of the protocol; but it's simple enough to publish a message upon connection. I can see a few ways of accomplishing your aim:
Publish all of the configurations as retained messages. You would require a 'config' topic per device for this (say config/uniquedevicename). When the client starts up it will subscribe to the relevant topic and receive its configuration (the 'server' would need to publish a message to each of the config channels with the retain flag set).
Upon starting the device publishes a message requesting its configuration; the server is subscribed to the relevant topic and responds with the configuration. You can use preset topics for the response or pass the topic in as part of the request.
For one (or a small number of devices) option 1 would be very simple to implement; however option 2 provides more flexibility.
This post is related to ROS (Robot Operating System) and ESP8266, and has also been cross-posted on ROS Answers and Robotics Stack Exchange.
I've ROS Melodic running on a Raspberry Pi 4 and need to send out information (as strings) over wifi to multiple ESP8266. I'm only just starting so it's just one ESP8266 for now. For communication, I'm using socket_node found in the ROS package rosserial_server (package wiki).
Referring to the picture below, the slave node publishes to the topic /Topic_data_over_wifi which is subscribed by a node running on the ESP8266:
The problem is, the node /rosserial_server_socket_node remains floating!
I've double checked names of topics and IP addresses, and at one point, got the node /rosserial_server_socket_node to actually link to the rest of the ROS network as shown in the "What I want" section. However, that was just one time (a fluke?) and never could I again get /rosserial_server_socket_node to join the ROS network.
rosserial_server's socket_node is used with its default settings (port 11411). I did try other port numbers but there was no difference. After all nodes have been launched, here's the output of rostopic list (other than the usual /rosout and /rosout_agg):
/commands_from_master_node
/topic_data_over_wifi
Goal: I need to find a way to connect the ESP8266 and the Raspberry pi 4 over wifi using ROS. More specifically, I need to get data from the slave node (on Raspberry Pi) to the node running on the ESP8266.
I've already looked at this multiple-TCP-connections post but didn't find anything that could solve my problem.
Any inputs/suggestions will be very appreciated.
Depending on the software running on the ESPs, it might be an option to use the ROS MQTT bridge. The downside is that you will need an additional MQTT broker (I am not sure, but as I recall mqtt_bridge is an MQTT client and requires a broker like Mosquitto). You can add MQTT clients to the ESPs and connect them to the same broker and subscribe to MQTT messages. In other words, you create a MQTT network for the ESPs with their borker and add ROS to that network, via mqtt_bridge. If you are not running ROS specific software on the ESPs it should work fine.
I've recently upgraded a BLE packet capture application running on a Raspberry Pi Zero/w (Raspbian Stretch) to use OpenSSL when forwarding packets to a cloud server. The cloud server just receives the packets and stores them in a db, the app on the Pi just sends the packets to the cloud server. So it's a one-way conversation from the Pi to the cloud server.
The problem is that the cloud server will shutdown a connection after a period of inactivity. So it calls SSL_shutdown(), but on the Pi the SSL_RECEIVED_SHUTDOWN flag never gets set, unless I call SSL_read() (or peek).
Additionally, polling on the socket doesn't show SSL_ERROR_WANT_READ on the Pi, even after the server has made it's call.
So, bottom line, I'm having to constantly call SSL_read() just to catch the shutdown. Is that normal? Is there another approach that makes more sense?
I'm using non-blocking sockets, so it doesn't seem to hurt anything, but it just seems hokey since the cloud server is never going to be sending any data (so there's never going to be anything to actually read).
Anyway, I've spent hours researching and trying various approaches, but this is the only way I've found to get it to work.
i had connected Watson IoT-sensor-Simulator to Watson IoT device by entering device credentials, a few days back and closed the connection.
now the device is continuously connected and receiving messages as"The client id was reused" thereby increasing the data usage rate .
I need help in disconnecting the connection.
message
The log messages showing "The client ID was reused" indicates that you are running multiple clients using the same credentials - so although you have closed the connection from one client, the other clients continue to connect. If you can't find these clients (the log messages will contain the IP addresses to help you find them) then you can revoke access for the other clients by changing the device's password. This will prevent the spurious clients from connecting.
Is it possible to run the Mosquitto Broker on any shared server? The closest solution I got to is this here, it only tells how to configure it, but I can't figure out how to install it on my server without ssh.
Another possible solution for my problem will be to use hosted brokers like CloudMQTT. I don't like it's plans and pricing, are there any other alternatives to this?
If you don't have console (SSH) access to the machine to install and run software it is going to be very difficult to add a broker without help from the administrator.
If you do mean a virtual host on a shared web server, then this is unlikely to happen as there is no concept of virtual hosts for MQTT so each user would have to be given their own port number (may be 2 if you want MQTT over websockets)