README

这是Anviz EP300设备的CommsProtocol的“有限”实现。有限是因为它不包含每个可能命令的功能，而只提供了一种发送命令和正确处理响应的通用方式。

为什么我为Anviz设备创建另一个客户端

最初我尝试使用Jerko Tisler的jtisler/PHPAnviz库。这是一项伟大的工作，但我发现它有点复杂，因为它依赖于gearman，并且应该有一个anviz-server应用运行。最后，它需要Anviz设备以客户端模式运行，我认为Jerko提供的方式适合处理Anviz在客户端模式下的连接。我只是需要一个简单的“同步”客户端应用程序，由cron运行，将命令发送到数据库并保存T&A记录。

另一个原因是，我在Anviz的响应中检测到了一些意外的东西。这些仍然是有效的响应，但包含额外的部分。在解析后，我发现这些部分带有0xDF确认码，这在通信协议中被描述为“实时发送T&A记录”，但不知道为什么这些部分会出现在许多不同命令的响应中。

示例：我发送获取记录信息命令（代码0x3C）并期望带有ACK代码等于0xBC的响应。如下所示

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

但有时响应可能包含带有0xDF ACK代码的额外部分。如下所示

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

如果有人知道为什么会出现这种情况，我已经为它创建了一个Stack Overflow问题

我可以得出结论，Anviz在为发送其他命令而创建套接字时发送“实时”T&A记录（带有0xDF的部分）。

最糟糕的是，当我们尝试获取“新”T&A记录时，它不会返回这些T&A记录。这导致一些T&A记录可能被客户端丢失。为了克服这一点，我实现了“回调驱动”的命令响应处理，它允许从任何命令的响应中的0xDF部分收集T&A记录。