Pressing "Cancel" or "I'm done paying" interrupts coin credit counting - resulting to lost credits

[verniegithub]

Affected software is version 5.1.2 and previous versions with "Cancel" or "I'm done paying" button during inserting of coins. Pressing "Cancel" or "I'm done paying" interrupts coin credit counting - resulting to lost credits. When the ado software is not yet done counting the pulses/recording the corresponding credit for every coin inserted and the user presses "Cancel" or "I'm done paying.", it can cause lost in credits. This is that moment a P5 coin (with designated 5 pulses) and specially a P10 coin (with designated 10 pulses) will be credited to a lower value and we blame the electronics failing but it is a software feature (if it is not a bug, it is a feature) to stop the counting of pulses and recording of credits will be affected. Every week I see this problem specially from users who are in a hurry to get online. These users are the high paying who insert coins usually from P15 to P50 and are usually in a hurry to get online. I monitor two vendo and check everyday and able to narrow this issue to only happen to users in a hurry not waiting for the credits to appear on their device. I simulated the behavior and repeatedly able to trigger it.

A work around or a band aid solution (but not totally perfect and a hassle or extra work to do by every vendo builder or owner) that I see to minimize this problem and can be done by the vendo builder or vendo owner is by changing the assigned pulses setting for every coin on ado for each coin (P1, P5, P10) to a lowest possible number of pulse that also requires re-calibration of the coin slot to correspond to such assigned pulses. This will outrun the user from interrupting coin pulses counting and recording of the correct credit. This will speed up coin pulses counting or lower the time it takes for the credits to appear on the user device. Lowest possible pulse setting are the following:

1 pulse for P1 (same as default) 2 pulses for P5 3 pulses for P10 4 pulses for P20 (only for older model coin slot, those with anti-hook will require hardware modification to accept this coin.

This band aid solution will make ado faster in recording credits at the expense of every builder or vendo owner to make the change on every vendo they have. I am aware of other vendo software out there and ado is not the fastest in recording of credits or giving feedback to the user device. However, with its available features and milestones, it is still ahead in development among other vendo software in the market and for that it is still better. Caution when applying this band aid solution. Please be aware that we will lost the clue what coin was inserted if ever there is incorrect recording (maybe due to failing hardware or an increase in wire resistance) when we do this band aid solution as there are no in between possible pulses. The only way to verify is to physically check the vendo and the coins inserted. Below is the new pulse setting with coin slot recalibrated and tested to provide the correct pulse for each type of coin and indeed from testing we noticed a much faster feedback to the user's device of the credited amount. We'll observe in the coming days with this setup.

A correct and best solution is a change on the software side to never interrupt the counting of pulses and the recording of credits even when the "Cancel" or "I'm done button" is pressed specially when coins are already inserted. Recording of correct credits must be a priority by the ado software regardless if the user is in a hurry and not verifying the credited amount. I consider this as a serious issue on the software side that causes lost credits and we usually blame the electronics not working correctly. The work around solution suggested by ado by adding additional pulses like 2 to 4 pulses and recording it as 5, 6 to 9 pulses and recording it as 10 does not work in this issue as a solution. A software update is a must to handle this correctly and it must be done on the software side and not by every vendo user or wifi client. This issue can be repeatedly triggered by any user. You can try it for yourself.

Below are screenshots when users interrupted the counting resulting to missing credits.

One additional feature I enabled to slow down insertion of coins that each coin be recorded in a separate second interval is the "Block fast insert" and it works well that coins be recorded in a separate time interval but it does not help with this issue.

[squaredward]

It would be nice as is it would not only fix the problem but also speedsup the crediting time to morethan 50% because it requires 3 pulse for P10 instead of 10 pulse which is 70% more time to do pulses, good idea

[squaredward]

I don't think if it is already on the software the "no interupt" toggle button i don't really know how exactly that works because im just a normal person ado user

[verniegithub]

I cleaned and done calibration of different coin slots, test each on a vendo and we're able to see some unintentional exploits that can increase the credit using coin slots without the anti-hook feature. We also see that credits can be recorded lower than the actual amount. This must be another cause of lowered credits other than interrupting the counting process. However, the Block fast insert feature is a must to discourage possible exploits and possible credit errors and from testing we see most of the time its physical design is helping.

Anyway, the reduction of the number of pulses for P5 and P10 improved credit recording and feedback to the user device and that is what I will continue to implement as my standard from now on. So far no issues with that setting on a coin slots with anti-hook feature.

I was thinking of ordering more coin slots without the anti-hook feature (they are also cheaper) as I see its advantage to accept P20 but I changed my mind after seeing first hand how easy to exploit (no extra device needed) the coin slot without the anti-hook. My intention was not to do any exploit but to simulate some user's method of inserting coins and how it affect credit recording. What we discovered from testing every possible way to insert coins done by our users made my mind changed from using coin slots without the anti-hook feature as there are more issues later than the advantage to accept the P20 coin.

[verniegithub]

Fast insertion of coins, both old coin slot and new with anti hook and with Block fast insert enabled sometimes lead to lost credits and this can be reproduce easily. Example, old P5 first coin followed right away by a new P5.0 or even with an old P5 coin will result to first old P5.0 credited correctly while the second P5 coin is credited as P1 only and the resulting total is only P6 credits. This happened both with default coin slot calibration and the modified coin slot configuration with lower pulse number. To hopefully stop or minimize this issue for now, I printed on a short bond paper some instruction to insert coin one at a time and any fast or irregular insertion of coins will lead to lost credits that users will be aware. Any problem they observe, they are free to contact through the chat icon on the portal.

It is only this time were we see first hand how this lost credits happened without pressing the Cancel or the I'm done paying button while waiting for the credits to appear. It only occur to a few users in the community with fast hands. hehehe but it is a hassle to add credits every time we see irregularities. I guess for now we reached the limit to our setup that users must slow down in inserting their coins or they will lost credits. Looking at the coin slot when testing fast insertion of coins, it did not fail to display what coin was inserted, it perfectly show it is reading it correctly but ado can't handle it resulting to lost credits. It is a hit and miss situation, in some cases ado can handle it well and sometimes it cannot. I checked the database of history when this happened, I managed to add back the lost credits to affected users up to the month of June 2022. Yes, we noticed every week there were excess income in a few pesos per week like 4 to 9 pesos. We replaced wires, re-calibrated coin slots, replaced coin slots, replaced power supply, monitored everyday and still we see excess in income but no one complained of lost credits except from one vendo where one person keep tracking of his credits. This time we decided to never stop investigating the cause until we ourselves seen it first hand, replicated it many times that it can happen and it can be done to the point we discover easy exploits to gain credits. I wish on the software side our programmers can make improvement, for now an announcement or instruction to slow down insertion of coins is the only option to stop or minimize the issue from happening.

[wreckseal]

Does this error still exist even if it has a custom board with the power-cut feature?

[verniegithub]

Does this error still exist even if it has a custom board with the power-cut feature?

With or without custom board and with or without power cut feature, it is easy to replicate the issue.

[adonespitogo]

Hello @verniegithub

Thanks for reporting this bug. This is definitely an issue. I'll add this to our priority items. Fix will be included in version 5.1.3.

Really appreciate the detailed reproducible steps. This is the correct way of reporting a bug and not ranting. Very civil and professional unlike the others. We take bug reports seriously, but most of the time they just complain without proper details of the problem they encounter.

We will release a beta version (v5.1.3) to the public soon. That will include the fix for this bug. Hope you can participate and confirm if this issue is fixed.

Again, thanks for the informative report.

Regards, Ado

[verniegithub]

Glad to participate in any productive way to improve the software. Thank you Ado.

[verniegithub]

This can be another issue but related to credit recording by adopisoft software.

The band aid solution I did having fewer pulses assigned for P5 and P10 works perfectly on one setup several months now, simple wiring. However, it's a hit and miss on another setup, simple wiring also. And a huge problem on my new setup with custom board. Coin slot reads the coins perfectly, but the software interpreted it differently. I can't run my new vendo this time if ado reads all P10 as P5 only. I am sure this is not a coin slot calibration issue as it provided the correct pulse for all versions of P10. P1 and P5 have no issue for ado, only the P10 where 3 pulses is assigned. I will try another new coin slot, make sure it is calibrated and test it. If it works fine then this must be hardware related also, meaning pulses could be different in quality even if coin slot indicated a correct reading.

[verniegithub]

Testing with new coin slot wire, new coin slot, coins were read perfectly by the coin slot, recorded by ado incorrectly for all P10. Using Interrupt or Loop reading type did not matter at all.

[verniegithub]

Just to update on the recent issue where P10 is no longer recorded correctly by the software. A fresh install from 5.0 then 5.1.2 solved the issue. I am not sure over time what is going on with the software why it behaves that way, the difference is previous install was done incrementally with the same path as the perfectly running first vendo that I also maintained. Anyway, tested different coins, Buy wifi, voucher and e-loading, all works without an issue that coins were recorded by the software correctly.

[adonespitogo]

Can anyone please confirm if this is still an issue with the lates beta image?

[verniegithub]

I tested today using the the latest image v5.1.3-beta3, it already solved the issue as the user cannot press the button while pulse counting is not yet done.

However, another issue is observed on setup using a relay that only turns on the coin slot when Insert coin is pressed. Pressing Cancel without inserting any coin will not disable the relay, making the coin slot always on or running and can receive coins if enable pin is not used. Normal use like pressing I'm Done paying after inserting coins will turn off the relay.

Testing it again, pressing Cancel without inserting coin, relay is turned off. It will appear the relay issue only happened once the first time I use it. There were instances assuming the user is in a hurry to press the I'm Done paying after inserting the last coin, the last coin is not credited and such moment can be done repeatedly in my testing. The amount of time the Done paying button switches to a none-clickable state is not consistent, there were times it's fast and there were time it's slow. It is during when it is slow switching to non-clickable state where the last coin cannot be credited if the user press the button. I am doing this way of testing as it is common in my area to see users in a hurry and for this reason we noticed an issue that some coins were not credited. We'll advice our users to make sure all coins were seen credited first before pressing the I'm done paying button.

[adonespitogo]

Testing it again, pressing Cancel without inserting coin, relay is turned off. It will appear the relay issue only happened once the first time I use it. There were instances assuming the user is in a hurry to press the I'm Done paying after inserting the last coin, the last coin is not credited and such moment can be done repeatedly in my testing. The amount of time the Done paying button switches to a none-clickable state is not consistent, there were times it's fast and there were time it's slow. It is during when it is slow switching to non-clickable state where the last coin cannot be credited if the user press the button. I am doing this way of testing as it is common in my area to see users in a hurry and for this reason we noticed an issue that some coins were not credited. We'll advice our users to make sure all coins were seen credited first before pressing the I'm done paying button.

Thanks for reporting. We will verify this bug on our end and send fix on the next release.

[verniegithub]

It is good to note that the test done today was with a coin slot with default coin pulse settings, that is P1=1 pulse, P5=5 pulses and P10=10 pulses. Using P10 coins is much easier to replicate the issue than using P1 or P5.

For coin slot calibrated with 2 pulses for P5 and 3 pulses for P10, it is not easy to cause a no credit issue as the system can count much faster. This calibration setting allows a much faster response from the machine.