I have a device connected to IBM IoT foundation. It uses a TI CC3100 Wi-Fi chip driven by an MSP430 MCU. The device used to connect perfectly to IOTF in the past. I didn't use it for a couple of months and now suddenly it does not connect. Did IBM recently change anything in the MQTT protocol for IOTF ?
I get the following messages on the device's console:
Device is configured in default state
Device started as STATION
Connection established with AP
Broker connect failed for conn no. 1
Exiting the Application
In the Watson IoT foundation dashboard I see the following messages (in the connection log):
Closed connection from 217.132.56.201. The topic does not match an allowed rule 2 times in the last 5 minutes May 29, 2016 8:36:46 AM
Closed connection from 217.132.56.201. The topic is not valid. 2 times in the last 5 minutes
Can anyone help resolving this problem ?
Thanks a lot,
Danny
Related
I'm testing Thingsboard since some month and today I started having some problems receiving telemtry.
I'm using ESP8266 with DHT11 and the code that appear on the tutorial:
https://thingsboard.io/docs/samples/esp8266/temperature/
I've been using differents variants of this code to send any kind of data and always worked ok.
Now I can't receive anything from any device.
Port 1883 open.
AP: Correct, the device connect with thingsboard and send telemetry.
TOken: ok.
But in the asset I can't see any telemetry.
Some suggestion?
Many thanks!
I'm writing a chat app using Twilio's Programmable Chat JS SDK. The app works fine, but I noticed after some long time (maybe 30+ minutes) where the browser tab is inactive, when I return to the browser tab the websocket connection is closed. These are the messages that appear in the console after switching to the inactive browser tab:
WebSocket connection to 'wss://tsock.us1.twilio.com/v3/wsconnect' failed: Error
in connection establishment: net::ERR_INTERNET_DISCONNECTED
twilio-chat.min.js:204 WebSocket connection to
'wss://tsock.us1.twilio.com/v3/wsconnect' failed: WebSocket is closed before
the connection is established.
1) Is this normal? Does it have to do with the fact that I'm still on the Twilio Free Plan?
2) How to manage socket connections in these cases? Also if the internet connection is lost then reestablished, how to ensure the web socket reconnects?
I tried to listen to the connectionStateChanged event as per the SDK docs here:
http://media.twiliocdn.com/sdk/js/chat/releases/3.2.0/docs/Client.html#event:connectionStateChanged
but when the user's device is sleeping (e.g. laptop in sleep mode) the event will not fire and therefore the socket will close.
Thanks
Was a known bug from Twilio. Solved by updating to the JS SDK 3.2.
I'm using MQTT paho for android mqtt connection for the last 15 ~ 20 days the client seems to works normally. but from last day the problem occurs.
I can successfully subscribe to messages and able to publish from the client but it won't affect the cloud data.
The subscribe and publish are working normally when I change my clientid to another value.
So my question is that does client id matter in performance issue?
Recently one of our MQTT clients is disconnected by Solace quite often in our Development Solace appliance but there is no issue for the same client in Test Solace appliance. We have no clue why this happens.
Upon checking Solace event log, I noticed there are quite a number of records in the event log for CLIENT_CLIENT_DISCONNECT_MQTT event. There are different reasons given for the event. The unique reasons I filtered out from the event log are listed below. May I know what could be the causes of these reasons?
Following are the reasons for CLIENT_CLIENT_DISCONNECT_MQTT event I filtered from the event log:
Client Disconnect Received
Forced Logout
Peer TCP Closed
Peer TCP Reset
I tried to think of the possible causes. For (1), does that mean client performs a normal MQTT disconnect call? For (2), could it be triggered by our backend application which issues SEMP command to disconnect the client as we do have such a function at the backend application? As for (3) and (4), I am not sure under what circumstances it happens as our MQTT client does not do anything specifically that could cause a disconnection to happen.
Is there any documentation of the reasons and the explanation for the causes of them?
I found the answer in Solace syslog documentation, https://docs.solace.com/System-and-Software-Maintenance/Monitoring-Events-Using-Syslog.htm
In addition, I did a simple experiment and found the following:
Client Disconnect Received: when client does a mqtt disconnect call
Forced Logout: (a) when Solace disconnects a client if duplicate client ID is used; (b) When SEMP command is used to disconnect the client
Peer
Peer TCP Reset: when the client 's connection is interrupted (e.g. the client program is killed by pressing ctrl+c)
I am working on a school project to connect the pn532 with a nfc phone. I am using the seeedstudio nfc controller and the library they have, with some code that I am adding. My questions are related to the connection and discovery stage of the protocol.
Question 1: What to respond when the initiator sends a CONNECT command to the DSAP = 1 "discovery service". Bellow I explain the results of the protocol.
Phones used to test were(gs4, note 2):
Situation 1:
the phone sends me 05 20 06 this is a CONNECT command to SAP =1 in the receiver device, then I respond with the CC command 81 84 2 2 0 78.
then they send me an IPDU with the URI of the application in the foreground, I keep sending command as per the llcp-snep protocol in the nfc forum and everything finish cool.
*The problem is that I don't want the URI of the application in the foreground, I want the NDEF message data of that application instead.*
Situation 2:
the phones send to the pn532 11 20 , this is a CONNECT command to SAP =4 in the receiver device, then I respond with the command CC 81 84 2 2 0 78.
After this the phone send me the NDEF data as is suppose to be.
Now my questions are:
Why some times the phone send me the CONNECT command to the SAP =1 and some times to SAP=4?
What command I have to response for the 05 20 06 ?
When a CONNECT command is send to SAP 1 it means that the sender wants to perform service discovery and connection setup in one step. In this situation, a required information in the CONNECT command is the service name. If that service exists and is connectable the response would be a CC (Connection Complete) PDU to the SAP from which CONNECT was received and from
the SAP that the named service is bound to. If a service with the requested name does not exist the answer would have to be a Disconnected Mode (DM) PDU with the appropriate reason code.
Unfortunately you have not provided full information about the CONNECT command received on SAP 1, at lest the service name length byte and the name itself are missing. As written, the CONNECT PDU is just invalid and should not be acknowledged.
As expected the whole problem was solved. After the request for connection of the undesired service I sent the DM with reason 02 command and everything went normal. It took me some time to get the library to work with all phones together but finally I fixed it. Thanks for all the feedback