Why do we have to key in tokens after buying them?
Since this works, then it simply means that the hardware communicates with the server to verify the keyed-in token code to verify its validity. So why not just query the server automatically? 🧵1/9
With this in mind I concluded that it had to be a firmware issue and as such an update on the firmware should solve this.
I was consulting for a company who are buying the smart meters for gas and water from China and they were using similar APIs as KPLC use.
Except that this one uses #LoRa while the KPLC smart meters use PLC(Power Line Communication: it's why you have to plug in that device on a wall socket to top up). While at it, I got to understand more how it works.
Since the devices(Meter and Switch) are theirs(Chinese Metering Company), then the communication server is theirs and all KPLC does is interact through a user interface provided to generate tokens and do very little. It's why broken power meters are replaced and not fixed.
And why a small firmware update like what I think would reduce this redundancy of buying and keying in tokens cannot be done, because they are not allowed to tamper with the meters in any way.
A fix like this would in turn reduce the cost of the meter since there wouldn't be need for a keypad or screen, heck even the small token-input device altogether.
If there is an available server with all the information about my meter, then why not build an #IoT UI where you can login and view all this data? This is what we do at Veno Autobotics(@veno_it ) btw
We build hardware(smart meter) to source data, build platforms to visualize and analyze them and use the hardware to actuate the respective action (switch off a meter when token runs out).
This also gave me a thought on how easy it would then be to mitigate power theft. But that is the premium info I'll disclose to the KPLC team as they let us work on a solution for this ;)
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Automated dispensing systems like Milk ATMs currently rely on someone to verify payment and then dispense the product. But what if you could initiate and verify payment right on the machine itself.
A user can then self-serve while you as the merchant get notified that a sale has been done and for what amount. The amount of product remaining can also be known and you notified to prepare to top up.
This is an example of a use case for QuePay. Built to handle payments for such automated systems. For vending and dispenser systems, we have an embedded device which is built into the machine to process payment and therefore actuate the product dispensing.