zaruto/phanviz

There is no license information available for the latest version (1.0) of this package.

PHP Client for Anviz T&A devices

Maintainers

Details

github.com/zaruto/phanviz

Source

Installs: 64

Dependents: 0

Suggesters: 0

Security: 0

Stars: 0

Watchers: 0

Forks: 2

1.0 2023-05-21 15:19 UTC

Requires

Requires (Dev)

Unknown License c79dcb5be04f8bacf2210bb2032d8fd05843f779

  • Murat Erkenov <murat.woop@11bits.net>

This package is auto-updated.

Last update: 2024-05-21 17:26:18 UTC

README

This is "limited" implementation of CommsProtocol for Anviz EP300 devices. Limited because it does not contain functions for each possible command, but just provides a general way to send commands and process responses in proper way.

Why I created another one client for Anviz devices

Initially I tried to use Jerko Tisler's jtisler/PHPAnviz library. That is great piece of work, but I found it a bit complicated due to dependency on gearman and it should have anviz-server app running. Finally it requires Anviz device to operate in client mode and I think the way Jerko offered is good for handling connections from Anviz when it operates in client mode. I just was need simple "syncronous" client application running by cron, which will send commands and save T&A records to database.

Another reason is that I detected some unexpected stuff in responses from Anviz. It still was valid responses, but with additional pieces. After parsing I found that those pieces are coming with 0xDF acknowlendge code, which is described in Comms protocol as "Sent T&A record in real time", but no idea why these pieces are appearing in response for many different commands.

Example: I'm sending Get record information command (code 0x3C) and expecting response with ACK code equal to 0xBC. Like below:

STX	CH		ACK	RET	LEN	DATA					CRC16
---------------------------------------------------------------------------------------------
a5	00000001	bc	00	0012	00002700002b000002000000004e98000001	d37b

But sometimes response may contain additional pieces with 0xDF ACK code. Like this:

STX	CH		ACK	RET	LEN	DATA					CRC16
----------------------------------------------------------------------------------------------
a5	00000001	bc	00	0012	00002700002b000002000000004e98000001	d37b
a5	00000001	df	00	000e	0000000023259f8c9c0103000000		9760
a5	00000001	df	00	000e	0000000020259f8ca60103000000		20fa
a5	00000001	df	00	000e	0000000025259f8cc30103000000		adf5
a5	00000001	df	00	000e	000000001a259f8ccb0103000000		ce07
a5	00000001	df	00	000e	0000000026259f8cd50103000000		8edb
a5	00000001	df	00	000e	0000000018259f8cda0103000000		1b19
a5	00000001	df	00	000e	000000001f259f8cdd0103000000		3fc1
a5	00000001	df	00	000e	0000000019259f8ce40203000000		82d6

If anyone have idea why it's happening I have created stackoverflow question for it

I can conclude that Anviz sends "real-time" TA records (pieces with 0xDF) when socket created for sending other commands.

The worst thing is that it does not return that TA records when we trying to fetch "new" TA records. It causes that some TA records may be lost by client. In order to overcome it I implemented "callback driven" processing of commands' responses and it allows to collect TA records from 0xDF pieces in responses for any command.