Marc, the app is reporting what it is seeing (which is a good thing, you don’t want to suppress these messages). It is seeing that there isn’t a response to its requests (delete code) so it’s informing you (the messages) and retrying until either it gets a response or the retries expire.
If the codes aren’t being deleted on the lock then the lock has a problem processing the command. If the codes are being deleted, then the lock responses aren’t reaching the app and it’s a problem with the mesh communication and is the most common issue as explained in the FAQ document/here. It’s common for commands/responses to be lost due to the nature of mesh, which is why the app engine verifies/retries commands for which it doesn’t receive a response. If you would like to improve the efficiency of the mesh, you’ll have get into why the mesh is losing the messages. It could be a bad repeater, a lack of a buffering device, signal interference from other devices etc.
@chrispt from prior experience, folks sometimes enter an invalid/typo in the date format. So by design, the app requests ST to refresh the page to verify that you’ve entered the date in the correct format and shows an warning if the date is invalid.
@neoshi the invalid pin is being sent by the keypad device. It could be a conflict between SHM delay and LUM causing the users not to be programmed properly. However, since you’re saying that it works when you type it in the second time, it sounds like codes are programmed but the first time the keypad device is either missing a number or sending the wrong number. Also keep in mind that different keypads work differently. Some require the arming / disarming button to be pressed before entering the code and some after entering the code.