Hello, when an AWS IoT Current Sensor is configured to send to a custom topic, does that make it so that it does not send to the Thing Shadow? Or should it be sending to both the custom topic and the Thing Shadow?
Hi,
If a User Topic Format is entered then telemetry will be published to that topic and not to the Thing Shadow Topic so it only publishes to one topic, not both.
Thanks for the response. How do I change that user topic format setting to blank? I have tried by using the shadow update topic ($aws/things/thing_name/shadow/update). I can change other settings, like the the interval but I can’t get user_topic_format to work either to set it to blank or to another topic name.
If you want the sensor to revert to publishing sensor data to the Shadow document then enter the actual text blank into the user topic format field. If you submit with no text entered into that field then it will be ignored.
I tried putting this as the body of the MQTT message to the topic $aws/things//shadow/update
{“user_topic_format”:“blank”}
It does not work.
I have also tried just setting it to another value like:
{“user_topic_format”:“Office/::Sensor_ID::”}
This also does not work. The device seems to restart then continues to send to the current topic.
If I instead send {“interval”:10000} it does change the interval to 10 secs. So I know the MQTT update topic is working, just not the user_topic_format.
Any thoughts why or how I can get it to accept an update to the topic it’s sending to?
Put the Sensor into configuration mode by pressing and holding the C button near the USB connector until the LED turns Blue. Once it is flashing Blue connect to it’s WiFi interface, then open the web interface to configure he sensor. Now enter blank as the user topic format.
If this still does not work you can factory reset the device. To do that put the sensor into configuration mode again(flashing Blue LED). Once it is in configuration mode press and hold the C button until the LED turns off, goes solid Blue, or begins flashing random colors. At this point the sensor will be factory reset and should publish to the shadow topic if you enter no parameters in the user topic format field.
Hello, I was able to put it into configuration mode and change the topic to blank which does now update the thing shadow.
The issue I’m having now is after sending an update the thing shows a Disconnected message for the reason DUPLICATE_CLIENTID.
{
“clientId”: “”,
“timestamp”: 1644432547488,
“eventType”: “disconnected”,
“clientInitiatedDisconnect”: false,
“sessionIdentifier”: “”,
“principalIdentifier”: “<removed”,
“disconnectReason”: “DUPLICATE_CLIENTID”,
“versionNumber”: 50
}
Hi Jason,
Since it was factory reset it is trying to provision itself to obtain credentials again. You will need to go to AWS IoT Core and manually delete the thing there, then power up the Gateway. It should connect then.
Thanks for the suggestion. I did already try removing the thing. It recreates the thing and works fine, but then still gives the disconnect with the DUPLICATE_CLIENTID reason. It does seem to reconnect a short time after that, but it’s problematic because it doesn’t send readings during the time it is disconnected
Also, a bigger problem is that it periodically completely disconnects sometimes. It isn’t a clean disconnect it just stops working and the only way to get it to work again that I have found is to power cycle it.
This sounds like something going on with AWS IoT Core. I will submit a ticket with them to see if there are any recent breaking changes. These AWS Gateways have been working flawlessly for 2 years now.
One other thing. Can you remove the AWS Gateway from the housing so you have access to the USB port?
Install this driver and it should mount to your computer as a virtual Serial/COM port:
Then use a serial monitoring software such as Comm Operator here to monitor the serial output at a baud rate of 115200:
https://www.serialporttool.com/GK/comm-operator-pal/
The Gateway will output some debug messages which might give us a better idea as to what is going on.
Hello, I did as you asked. I have attached the output. I believe what is happening is that when the device is configured to send updates to the thing shadow it sends updates to $aws/things/thingid/shadow/update but it’s also configured to subscribe to this channel and look for updates there. When it receives it’s own update on the $aws/things/thingid/shadow/update it treats it the same as an update to a setting like interval, which triggers the device to reconnect. This would also explain why it wasn’t doing this before when I was sending updates to a custom topic.
Rec:(18:25:29)Free Heap: 171676
Received Serial Data7F 00 01 03 FF 02 00 0D 00 00 0A 13 00
MQTT published {"state":{"reported":{"sensor_type":13,"Current":2.579,"mac_address":"<mac>","ip_address":"<ip>","wifi_rssi":-49,"wifi_ssid":"<ssid>"}}} to topic $aws/things/<thingid>/shadow/update
Sending to settingsUpdate: {"state":{"reported":{"sensor_type":13,"Current":2.579,"mac_address":"<mac>","ip_address":"<ip>","wifi_rssi":-49,"wifi_ssid":"<ssid>"}}}}}
Rec:(18:25:36)Seconds since last loop: 3.99
Returing true from AWS load settings
AWS Initialzing
Running CredentialInit
Rec:(18:25:43)Storing: {"region":"us-west-2","end_point":"amazonaws.com","domain_prefix":"<iothost>","thing_name":"ESP32_Gateway","mqtt_port":443,"i_am_key_id":"<iamkey>","i_am_secret_key":"<iamsecret>","user_topic_format":"blank"}
Storing: {"region":"us-west-2","end_point":"amazonaws.com","domain_prefix":"<iothost>","thing_name":"ESP32_Gateway","mqtt_port":443,"i_am_key_id":"<iamkey>","i_am_secret_key":"<iamsecret>","user_topic_format":"blank"}
client cert length: 1225
private key length:1676
hasCerts = true
Connecting to AWS MQTT
Host: <iothost>.iot.us-west-2.amazonaws.com
AWS MQTT connected.
Subscribed to: $aws/things/<thingid>/shadow/update
Free Heap: 170468
Rec:(18:25:52)Free Heap: 172468
That seems reasonable, although I’m not sure how this has not been caught yet. The functionality of the AWS Gateway was even evaluated by the AWS IoT Core team and was accepted. I wonder if it’s possible that all users have been using a custom topic.
You could try entering your own custom topic to publish changes to the Shadow document and see how that works. AWS has documentation for interacting with the shadow document here:
Could you give that a try and let me know what you find? I can make updates to firmware as needed and then you can re-flash your device.
Thank you for all your feedback here Jason.
Travis
Good morning, The sensor is already correctly updating the shadow document in the current configuration. I don’t think there is anything to fix there. The shadow document looks like:
{
"state": {
"reported": {
"sensor_type": 13,
"Current": 0,
"mac_address": "macaddress",
"ip_address": "ipaddress",
"wifi_rssi": -48,
"wifi_ssid": "ssid"
}
}
}
I believe the issue to fix may be that the device is attempting to load it’s settings when it receives any message on the $aws/things/thingid/shadow/update topic. Instead perhaps it should only attempt to update it’s settings when receiving a desired state message. I believe that would be closest to the AWS documentation. For example this message body would be used to update the interval that the sensor publishes telemetry.
{
"state": {
"desired": {
"interval": 10000
}
}
}
The sensor would then have to listen on the /update/delta topic as outlined here:
When the device receives the /desired state on the /update/delta topic, it makes the desired changes in the device. It then sends a message to the /update topic to report its current state to the shadow.
This would require several changes to the sensor’s code.
If you still wanted to maintain the ability for the body to be sent like this to the /shadow/update topic as outlined in your documentation:
{ "interval": 10000 }
Then the other option, that would require less changes, would be for the the device to not load settings when it receives a message on the update topic where the state contains a reported section and/or the mac_address is it’s own mac_address. Basically the load settings function would need to exclude it’s own update messages. This will not be following the AWS documentation but could still work.
Those are the two ways I would attempt to address this.
I see exactly what you are saying. Let me dig into this in the firmware. I am not currently checking if the type is desired or reported, I’ll see if I can correct this.
I just updated the firmware on our Repo.
A settings update will only be attempted if a message in the format of:
{“state”:{“reported”:{“interval”:1000}}}
is published to the update topic. This should prevent the device from inadvertently updating itself when it publishes updates.
Can you update the firmware on your device using the instructions provided here and let me know if this corrects the issue you are seeing?
Thank you and have a great weekend,
Travis
That appears to have resolved the first issue! The device no longer attempts to load settings each time it sends a sensor update to the /shadow/update topic.
The other issue where it becomes completely non-responsive takes a day or two to reoccur. I’m hopeful that now that it is no longer repeatedly reconnecting throughout the day that this will no longer occur, but will let you know.
Great. Keep me updated if the sensor stays online for an extended period or if you still have issues. If it was rebooting after every report I can see that causing memory issues after looping like that for a few days.
Unfortunately the sensor continues to become nonresponsive at random intervals. I have plugged into the USB port while it is in this state and there is no output coming from the device. The only solution I have found is to power cycle the device.
The other oddity I have observed is that when in the mode where it is sending telemetry to the /shadow/update topic it seems to ignore the update interval that is set. When I have it set to 10sec with a custom topic it sends an update message approx. every 10 secs. When set to blank and using the /shadow/update topic it sends a message most of the time when the current goes from 0 to >0 or >0 to 0 and also once every 9-10 minutes.
It sounds like our production staff may have inadvertently uploaded the wrong settings to the sensor processor in the board which is not allowing you to modify the report interval. This will require sending the sensor back here for re-configuration. You can complete an RMA form here to return the device:
https://ncd.io/contact-us/product-returns/
We apologize for this inconvenience. I will dig further into the AWS sensor issue dropping connection and see if I can replicate what you are seeing here on my end. If I can replicate it here then I can fix it.