I'm using an ESP32 in the aws cloud (Iot-Core) and afer a few hours connected, the device simply cannot publish in the MQTT topic anymore. I'm using Arduino IDE. I would like to know how can I map the Publish / Subscribe errors on ESP32 to understand the real reasons and how to handle them. Currently I'm restarting the device and the connection keep working until a period of time.
I am using Google IOT core with mongoose os. I wanted to update device connection status to firestore. But i am unable to find event which reports mqtt connection status to pub/sub like when device disconnects or reconnect i.e if device is offline or not.
I am stuck on this problem for days.Any help will be appreciated
Update
As #devunwired mentioned in this response it is now possible to monitor Stackdriver logs for disconnect events. You must have at a minimum enabled INFO level logging on your project in IoT Core > Registries > [your registry] > Edit Registry > Select "Info" log level > Click save.
Original Response
There are a few values you can look at that are tracked in device configuration metadata that you could use to know when a device last was online:
Last Configuration Send time - sent anytime your device connects /
configuration is posted
Last Event Time - Last time an event was sent from the device
Last State Time - Last time state was sent from the device
Last Heartbeat time - Last time MQTT heartbeat was sent
To get you started, here is an example using API explorer that you can fill-in with your project ID, region, registry, and device to query for a specific device's metadata.
For 1...3 you have control over these through device manager and by publishing data. MQTT heartbeat is updated if your device sends an MQTT_PINGREQ message during the "ping period" without other messages getting sent.
At any rate, you could use any of these update time values to see the last time a device was online / functioning. You could query the states of your devices after listing the devices in a registry and could update a Firebase RTDB periodically if that's how you want to report (e.g. using AppEngine TaskQueue). Note that you also just can get these "last connected" values from the Google Cloud Console.
It was said before but we don't have an event for disconnect, just configuration ack, which generally is the connection event. If you want to share state between a device and the device manager, use state messages.
Unfortunately, there's no built in way to do this right now as there aren't events on this state.
However, you could implement a hack by sending a message on connect/disconnect from the device that you have a Cloud Function subscribed to the Pub/Sub topic listening for. It's not perfect as it would fail in the case where the device disconnected unexpectedly.
There currently is no way to do this, that i've been able to find (a year later after this original post). I posted a question here on SO regarding this as well, with more details and link to example code I had to use for handling this:
Google Core IoT Device Offline Event or Connection Status
The AWS IoT platform publishes messages on a special MQTT topic (prefixed with $aws) when your device connects/disconnects. You can easily use these to monitor these events - however, you should be aware that the MQTT protocol is designed to be robust to a poor networking conditions and the broker on the AWS side probably doesn't think it's a bit deal to disconnect a client. The broker expects that the client will just reconnect and queue messages for a moment during that process (which can be a big deal on a microcontroller).
All that being said, the AWS topics you would watch are:
$aws/events/presence/connected/{clientId}
and
$aws/events/presence/disconnected/{clientId}
and the documentation for these (and other) lifecycle events are located: https://docs.aws.amazon.com/iot/latest/developerguide/life-cycle-events.html
I'm working on sending and receiving messages via MQTT, I'm using mqttClient framework:
https://github.com/ckrey/MQTT-Client-Framework
Specifically this class: https://github.com/ckrey/MQTT-Client-Framework/blob/master/MQTTSwift/MQTTSwift/MQTTSwift.swift
So this is all working just fine using Xcode simulator, publish and subscribe and so receiving the data (messages) just as it should BUT once I connect my iPhone I could not see my data on the debug screen as it used to be and all I can get is this
nw_connection_get_connected_socket_block_invoke 1 Connection has no connected handler.
I was trying to solve this all day but no use,
You have to give proper IPAddress instead of "localhost" if used.
It solved my issue.
Am using open fire server and iOS xmpp client with Robbie Hanson's framework. My clients runs fine in background, as i have set the voip flag and everything. But after few hours around 15-20, it automatically gets disconnected. Am not sure why it's happening and why it is taking such long duration. I am not sending any messages or receiving any. The ping interval is 360 secs to which my client responds with an error, which is acceptable form of response to remain connected to the server. Anyone got the same issue ?
Openfire server: 3.8.1
iOS version: 6.1.2
Did you try using the setting "Do Not disconnect clients that are idle" available in Server Settings> Client Connections in Openfire server?
I am currently developing a Blackberry 5.0 application which needs to be able to intercept a SMS message. I am trying to send a SMS to the emulator. I've come accross the suggestion to run two separate instances of the emulator and to send a SMS from the one emulator instance to the other using the SMSDemo sample application on both emulators.
I run the two instances of the emulator from two separate working directories as follows:
"C:\java\blackberry\eclipse\plugins\net.rim.ejde.componentpack5.0.0_5.0.0.36\components\simulator\fledge.exe" /app="C:\java\blackberry\eclipse\plugins\net.rim.ejde.componentpack5.0.0_5.0.0.36\components\simulator\Jvm.dll" /sms-source-port=6000 /sms-destination-port=6001
"C:\java\blackberry\eclipse\plugins\net.rim.ejde.componentpack5.0.0_5.0.0.36\components\simulator\fledge.exe" /app="C:\java\blackberry\eclipse\plugins\net.rim.ejde.componentpack5.0.0_5.0.0.36\components\simulator\Jvm.dll" /sms-source-port=6001 /sms-destination-port=6000
Both instances start up but when I attempt to send a SMS it never arrives at the second emulator.
I've disabled the Windows firewall - no change.
When I netstat for UDP I can see both ports 6000 and 6001 listening.
Any advice would be appreciated.
I have finally found a solution for the problem. Here it is:
Using Wireshark to sniff the UDP broadcast from the emulator I noticed that the destination address is incorrect - its "1.0.0.127". This address is not routable so the datagram sent from the one emulator will never reach the other emulator.
I might have missed it but I cannot see any command line argument to set when launching the emulator to specify the destination address.
I changed my development laptop to use a hard-coded IP address instead of DHCP. I then added 1.0.0.127 as another IP address to my TCP/IP settings. The address is now routable.
Restarted both emulators with no changes to the port settings (/sms-source-port and /sms-destination-port) and it worked fine. I did not need to use the SMSDemo application. I used the normal Blackberry messaging application.
I hope this helps others experiencing this same problem.