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.
Related
I am developing a sort of IoT type system, where there is control software, a server, and client devices (which are embedded linux devices).
I have a flask server running a REST web service. Control software sends messages for a specific device to the flask web service running on the server. When these messages are received, they are stored in a database.
Client devices poll the sever to determine if there is a new message waiting for the device. This works well but becomes prohibitive as the number of devices grows.
I'd like to find a way to have the messages sent directly from the server to the device as they are received at the server. Is there a simple way to add this functionality to flask? This seems a bit like push notifications.
Is it possible to have each device open a socket like communication to the server and keep it open? Is this a bad idea if I just use TCP sockets for this?
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.
I have 100K of iot devices connecting on tcp server. I have to select specific services to be executed on each device based on the device id. Right now I am using a rest api, that I call upon when a device connects to the server,which in turn returns the list of services to be executed on the device, these services on each device are selected by users using a web portal, my problem is when all these devices connects at the same time, rest api server goes down or hangs or takes time to serve the request, my need is to get the response back in milliseconds please suggest any better solution that can server my purpose.
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.
I got a bounce message today from a client. In the bounce notice it shows:
The error that the other server returned was:
554-Service unavailable; Client host [mail-io0-f178.google.com] blocked using
554-Barracuda Reputation;
554 http://www.barracudanetworks.com/reputation/?r=1&ip=38.116.199.194
And further down where it shows the original message it says
Received: from Macbook-Pro-Retina.local ([38.116.199.194])
The above is a blocked Russian IP Address. Normally the source of my messages shows:
Received: from Macbook-Pro-Retina.local
(CPE0016cbc430da-CMf0f249004a80.cpe.net.cable.rogers.com. [174.119.**.**])
The 174.119 is my normal external IP address and shows in the source of any message I send. Also I use Google apps for all my mail so its going through their server.
So the question is, is the bounce message a result of an issue on my local machine or does it have to do with the client's server?
38.116.199.194 IP address is part of a 38.0.0.0 - 38.255.255.255 range allocated to Cogent (ARIN WHOIS). A part of this range, 38.116.198.0/23 subnet is operated by MaRS Discovery District.
It appears that your computer was connected to the MaRS Discovery District's network when you sent the email. Maybe you were using their Wifi at the time or maybe some (malicious) software on your machine was routing traffic via that network unbeknownst to you.