Internal SekureID Communication - Revision history

David: /* Review Logs */

2020-07-10T12:32:27Z

‎Review Logs

Stage: /* Resend Time Logs */

2020-07-04T15:43:03Z

‎Resend Time Logs

Stage: /* Resend Time Logs */

2020-07-04T15:42:07Z

‎Resend Time Logs

Stage: /* Resend Time Logs */

2020-07-04T15:28:29Z

‎Resend Time Logs

Stage: /* Resend Time Logs */

2020-07-04T15:25:59Z

‎Resend Time Logs

Stage: /* Case Studies */

2020-07-04T15:15:07Z

‎Case Studies

Stage: /* Case Studies */

2020-07-04T14:20:30Z

‎Case Studies

Stage: /* Case Studies */

2020-07-04T13:58:46Z

‎Case Studies

David: /* Case Studies */

2020-07-03T15:52:29Z

‎Case Studies

David at 14:41, 3 July 2020

2020-07-03T14:41:22Z

@@ Line 13: / Line 13: @@
 ==Review Logs==
-From the Communication / Time Logs tab, click on Get Latest Punch Received button (#3). This is equivalent to this SQL:
+From the Connection / Time Logs tab, click on Get Latest Punch Received button (#3). This is equivalent to this SQL:
   <nowiki>

@@ Line 66: / Line 66: @@
 [[File:LogIDCreatedDateTime1.png]]
-And scrolling up to row number 28 we see that the LogID is 27019. This confirms that there is no gap from the first timelog received after the reboot to the more recent punches made at the time clock.
+And scrolling up to row number 28 we see that the LogID is 27019. This confirms that there is no gap from the first TimeLog received after the reboot to the more recent punches made at the time clock.
 [[File:LogIDCreatedDateTime2.png]]

@@ Line 51: / Line 51: @@
 A clock can be instructed to resend punches. This uses the GMT Time and a maximum time span of 24 hours. Punches that are already sent will not be duplicated, but there is nothing to be gained from resending punches that have already been received.
-After the client reboots you can look at the TimeLog and determine if new punches are being received. By looking at the LogID you can determine if there is a gap.
+After the client reboots you can look at the TimeLog and determine if new punches are being received. By looking at the LogID and CreatedDateTime columns you can determine if there is a gap in the LogIDs at the point that punches started coming into the software. Using this SQL, scroll down to the records where the new punches were receieved.
   <nowiki>
 SELECT TOP 1000 * from TimeLog WHERE SerialNumber = 'serial number' ORDER BY LocalPunchDateTime DESC</nowiki>
 [[File:PunchesAfterReboot.png]]
 ==Removing Session from the Hive (Advanced)==

@@ Line 53: / Line 53: @@
 After the client reboots you can look at the TimeLog and determine if new punches are being received. By looking at the LogID you can determine if there is a gap.
-[[File:PunchesAfterReboot.jpg]]
+ <nowiki>
 ==Removing Session from the Hive (Advanced)==

@@ Line 49: / Line 49: @@
 ==Resend Time Logs==
-A clock can be instructed to resend punches. This uses the GMT Time and a maximum time span of 24 hours. Punches that are already sent will not be duplicated.
+A clock can be instructed to resend punches. This uses the GMT Time and a maximum time span of 24 hours. Punches that are already sent will not be duplicated, but there is nothing to be gained from resending punches that have already been received.
 ==Removing Session from the Hive (Advanced)==

@@ Line 101: / Line 101: @@
 * HiveMQ session - Y means that the session shows as connected
-/2/2020 - New Grove Manor - initial status YNNN - removing disconnected session changed nothing - client rebooted clock - now status is YYYY. All punches came in with needing to resend.
+/2/2020 - New Grove Manor - initial status YNNN - removing disconnected session changed nothing - client rebooted clock - now status is YYYY. All punches came in without needing to resend. Conclusion reached - database shows not connected = HiveMQ disconnected.
-/4/2020 - CareCore at Lima - initial status YYNY - Last punch received 6/28 2:04 PM (LogID 26619) - HiveMQ shows Connected Since 7/1 08:19 - removed session and disconnected client, no changes - despite sending requests the Offline Message Queue Size was still zero so it looks like they are being sent and not being received - also changed company. Will have them reboot.
+/4/2020 - CareCore at Lima - initial status YYNY - Last punch received 6/28 2:04 PM (LogID 26619) - HiveMQ shows Connected Since 7/1 08:19 - removed session and disconnected client, in both cases the HiveMQ session went back to connected but still no response from the clock - despite sending requests the Offline Message Queue Size was still zero so it looks like messages are being sent and not being received - also tried a company change. Will have them reboot. After reboot all punches came in without any resend required. Conclusion reached - database icon shows connected = HiveMQ connected but Request = false still requires a reboot.

← Older revision		Revision as of 14:20, 4 July 2020
Line 102:		Line 102:

	7/2/2020 - New Grove Manor - initial status YNNN - removing disconnected session changed nothing - client rebooted clock - now status is YYYY. All punches came in with needing to resend.		7/2/2020 - New Grove Manor - initial status YNNN - removing disconnected session changed nothing - client rebooted clock - now status is YYYY. All punches came in with needing to resend.
−	7/4/2020 - CareCore at Lima - initial status YYNY - Last punch received 6/28 2:04 PM - HiveMQ shows Connected Since 7/1 08:19	+
		+	7/4/2020 - CareCore at Lima - initial status YYNY - Last punch received 6/28 2:04 PM (LogID 26619) - HiveMQ shows Connected Since 7/1 08:19 - removed session and disconnected client, no changes - despite sending requests the Offline Message Queue Size was still zero so it looks like they are being sent and not being received - also changed company. Will have them reboot.

← Older revision		Revision as of 13:58, 4 July 2020
Line 102:		Line 102:

	7/2/2020 - New Grove Manor - initial status YNNN - removing disconnected session changed nothing - client rebooted clock - now status is YYYY. All punches came in with needing to resend.		7/2/2020 - New Grove Manor - initial status YNNN - removing disconnected session changed nothing - client rebooted clock - now status is YYYY. All punches came in with needing to resend.
		+	7/4/2020 - CareCore at Lima - initial status YYNY - Last punch received 6/28 2:04 PM - HiveMQ shows Connected Since 7/1 08:19

@@ Line 95: / Line 95: @@
 ==Case Studies==
-These is a record of actual communication issues and how they were resolved. These case studies will use 4 markers:
+This is a record of actual communication issues and how they were resolved. These case studies will use 4 markers:
 * Local Network / Wifi status on clock - Y = clock shows as connected to the network
 * Database icon status on clock - Y means there is NOT an X on the database icon

← Older revision		Revision as of 14:41, 3 July 2020
Line 101:		Line 101:
	* HiveMQ session - Y means that the session shows as connected		* HiveMQ session - Y means that the session shows as connected

−	7/2/2020 - ~~NGM~~ - initial status YNNN - removing disconnected session changed nothing - client rebooted clock - now status is YYYY. All punches came in with needing to resend.	+	7/2/2020 - New Grove Manor - initial status YNNN - removing disconnected session changed nothing - client rebooted clock - now status is YYYY. All punches came in with needing to resend.