search

mathiasfrey / ecrterm

Python ZVT 700 interface (electronic cash registers)
GNU Lesser General Public License v3.0
34 stars 31 forks source link

TCP Support #4

Closed t-oster closed 8 years ago

t-oster commented 10 years ago

Hi,

Your library is the only Open Source ZVT Library I could find. I'm about to use it for operating our Terminal via TCP. Maybe you already have an unfinished tcp_transport.py file around, where I can start from?

g4borg commented 10 years ago

unfortunately no; the protocol was tested both on com ports and usb emulated serial ports, but never in tcp ip. i figure that would need some refactoring of Transmission itself maybe, because the flow in serial mode has certain rules the tcp solution might not have - and including some networking library to handle the heavy lifting, like twisted. However, the packet system itself should be agnostic to this, so once the base communication rules are set, overriding the ECR to use the new transport (which is heavily inspired by twisted anyway) should be possible.

mcules commented 8 years ago

Do you would do here anything else? Could use TCP also quite good;)

t-oster commented 8 years ago

Well... my solution was to use OPI (https://de.wikipedia.org/wiki/Open_Payment_Initiative) instead of ZVT, so for me this issue is not important anymore. @mcules feel free to reopen it if you are hoping for a solution.

mcules commented 8 years ago

Could it used with the Ingenico Terminals directly?

g4borg commented 8 years ago

I still think TCP support is a valid ticket anyway. The basic design of the library was with a later TCP expansion in mind. It is more a question of time and fundings, to add it properly and tested, I would say; I think for some applications of ecrterm this is even an upside, as adding your custom transmission class, and deciding how to use network (library choices) can be quite application dependant, while the serial usage is straightforward, and always "blocking".

karolyi commented 6 years ago

@t-oster do you have any documentation for OPI? it seems the links on wincor-nixdorf's site are all dead.

t-oster commented 6 years ago

Well, I do have a PDF but I had to sign for it. However I think my little helper class may give you a hint https://gist.github.com/t-oster/a1bed2bb82d566bbdb90706d521a8f83.

karolyi commented 6 years ago

@t-oster thx. one would think 'open' in the OPI means it's easy to find documentation for it.

also, I see you are only connecting to the POS terminal, and not accepting connections from it. I still don't have documentation for the original OPI but I have one for the CCV extended protocol, which defines a channel where the POS terminal connects back to the device/computer connecting to it, on port 20007 per default. isn't it necessary for proper communication? how do you get the success or failure response for the transaction?

t-oster commented 6 years ago

As you see in https://gist.github.com/t-oster/a1bed2bb82d566bbdb90706d521a8f83#file-opihelper-php-L105 the method returns a text containing 'OverallResult="Aborted" or 'OverallResult="Success". The connection is bi-directional, why should there be a need of a separate connection backwards? However it is long ago when I implemented this. I also was dissapointed that the documentation is not as Open as the name indicates. I was able to initiate payments with this class, and if I hadn't signed a contract, I would post the specification (if I find it).

karolyi commented 6 years ago

thanks, I'll look into it. it might be that the backwards connecting channel on port 20007 called DeviceRequests is only part of the CCV extended version. the firmware in the terminals is called 'SecPos', and it uses an extended OPI protocol. since I haven't seen the original spec, I can't know if it's there too.

I'm implementing something python based for this protocol, but I know PHP, so your code is helping, thank you. :)