Abstract:
This document explains how to troubleshoot an AWS connection, as an extension of the Crimson Cloud Connectors: AWS Tech Note.
Products:
CR3000 HMIs / Data Acquisition (DA10 & DA30) / Graphite® HMI / Graphite Controllers
Use Case: AWS Connector
Troubleshooting and verifying tag data transfer to Amazon Web Services.
Required Software:
Crimson 3.1
Required Firmware:
Build 3106.000 or higher
Tools to Use
- Debug Console as described at the beginning of the Crimson 3.1: Debugging Output Tech Note. The web option will be used throughout this document.
- Packet Capture as described in the Crimson 3.1: Packet Capture Tech Note. Using the SSL Data option, the unit will save an unencrypted version of the traffic.
Debug Console
- If there is an issue with the Certificate File or Private Key File, there is NO debug output.
- Figure 1 shows a good connection to the cloud.
Figure 1.
- Figure 2 shows a good certificate, but a failure to connect to a Thing, due to an incorrect Host Name.
Figure 2.
- Figure 3 shows data transfer to the Thing.
Figure 3.
The first transmission, RED in Figure 3, shows the status and time stamp.
The second transmission, BLUE in Figure 3, shows the data transfer and timestamp:
2...!$aws/things/Thing01/shadow/update.. The topic we’re publishing to.
{"state":{"desired":{}, The desired portion of the twin contains the values that the server wants the client to adopt. The server is typically responsible for setting this. We include at least a null desired section (which has no impact) and sometimes you’ll see empty values where we’re clearing a write request in the server after we’ve received and processed it. If we didn’t do that, the write would continuously overwrite anything at our end.
"reported":{"adhoc":"false", The reported section is the counterpart of desired, in that it contains what the device is reporting. Adhoc is set if this is a reading that is sent “off schedule”. For example, if you’re asking for an update every minute, we’ll actually send an update on connection and then we’ll send one on every clock minute i.e., 9:00:00, 9:01:00, etc. The ad hoc value will not align to the minute, so you might not want your historian to save it as it will make your graphs and tables look less tidy!
"connected":"true", There is an active connection. The key is that we define what’s known as a last will and testament message (LWT) that will set this to false. This means if we go offline, the twin will contain the false value.
"historic":"false", This is not historical data. Set to true on replay from buffered data. Don’t both updating SCADA displays etc. when a reply is underway or it will look very strange as it rapidly runs through hundreds of values.
"tags":{"Tag1":12,"Tag2":"12"}, tag values, string values are surrounded by double quotes
"timestamp":"2019-09-10T16:49:31.600Z"}}} timestamp of the data change being reported
- Figure 4 (taken from He shows that there is no active connection to the Thing and data will be buffered to be sent later (because the Reconnection mode (on the Service Tab) is set to Send All Data.
Figure 4.
- Figure 5 shows historical data (3 value changes: 14, 15, and 16) being transferred after the connection is restored.
Figure 5.
- Figure 6 shows a 5-second periodic update.
Figure 6.
Below shows the highlighted change in the transmission, this time adhoc is FLASE.
2...!$aws/things/Thing01/shadow/update..
{"state":{"desired":{},
"reported":{"adhoc":"false",
"connected":"true",
"historic":"false",
"tags":{"Tag1":31,"Tag2":"31"},
"timestamp":"2019-09-10T19:20:32.600Z"}}}
Packet Capture
You can use the SSL packet capture to see the contents of the packets and check them in WireShark. The TLS capture records that unencrypted data, so it’s useful for debugging encrypted links.
Select TLS as the interface and the port configured on the Network tab of the connector, port 8883 as shown in Figure 7, then start the capture.
Figure 7.
After stopping the capture and downloading the file, open it in Wireshark. You will see the unencrypted data transfer, as shown in Figure 8.
Figure 8.
Validating Data Transfer to AWS
There are two easy ways to verify data transfer: Viewing the Shadow or monitoring the Activity.
First, log in to AWS and then click My Account - AWS Management Console as shown in Figure 9.
Figure 9.
In the Find Services search box, type IoT Core as shown in Figure 10.
Figure 10.
Click Manage on the left side, then click the Thing that the unit is publishing to, Thing01 as shown in Figure 11.
Figure 11.
Viewing the Shadow
Click Shadow on the left, as shown in Figure 12.
Figure 12.
Observe the Tag1 and Tag2 current values. Tag1_1-Tag1_3 are from a previous version of the Crimson database, so their values have not changed.
Monitoring Activity
Click Activity on the left side, as shown in Figure 13.
Figure 13.
This list will grow as more activity takes place. Each line shows a timestamp and has a triangle on the left. Clicking this triangle will expand the update, allowing the user to see what was updated. This shows all updates, including the connection status ones. Figure 14 shows an update where the tag data was included.
Figure 14.
Disclaimer
It is the customer's responsibility to review the advice provided herein and its applicability to the system. Red Lion makes no representation about specific knowledge of the customer's system or the specific performance of the system. Red Lion is not responsible for any damage to equipment or connected systems. The use of this document is at your own risk. Red Lion standard product warranty applies.
Red Lion Technical Support
If you have any questions or trouble contact Red Lion Technical Support by clicking here or calling 1-877-432-9908.
For more information: http://www.redlion.net/support/policies-statements/warranty-statement