We have a client who recently updated to v5.15.0, and are having problems where all of their PIN pads are back to the "triPOS logo" (instead of the "welcome text" configured for the lane). Obviously, when they go to process the first transaction of the day, it fails because the device isn't connected:
2019-06-13 06:25:20,160 [22] triPOS ERROR - SmartTcpClientTransport.cs.ReadAsync: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
Further scouring of the Verbose.log from the time of the last transaction on the previous day to that error seems to indicate nothing out of the ordinary taking place (IOW, all regularly-timed lane configuration checks report no problems).
Sooo, some questions:
- With the new "automatic PIN pad reboot" functionality in triPOS Direct, does the reboot process ever show in any of the triPOS logs? And/or, could they be running through the automatic reboot process and never getting reclaimed by triPOS once back up?
- Does the regularly-timed lane checking on verify the configuration, and not the connection itself?
Devices in question are Ingenico iSC250's, FWIW.
Frank,
Before we dig into your direct questions, I'd like to check one detail. Are these iSC250's using USB or Ethernet connection? The error you cited implies Ethernet but I'd like to be sure.
Also, you say the first transaction of the day fails. After that failure, does the device begin to work normally? Is any action needed to restore operation?
I ask these questions because your report is very similar to a known issue with Ingenico USB devices.