EyezOn Forum

Anyone know how to poll the arm status using tpi on a DSC? I'd like to display to the user if the system is armed or disarmed.

Hi @queenorych

You can check here as I have done that in my software that integrates Fibaro HC2 home automation with DSC PC1616 using envisalink and its API.

http://www.incedo.eu/~sjoholmp/Fibaro_H ... DSCengine/


/Peo

Hi,

I am trying to extend AlarmServer functionality with sending custom keystrokes with the 071 function.

It works, but how I can send longer commands? Like *10602#, or *10602#1234 -> it is not supported at the moment?
Sending a single command works, example: *106#,*4#.

One more question: why is there no audio feedback when I enable/disable chime trough Envisalink?

It's probably too late for the previous poster, but the answer is that the send keys command is limited to 6 characters; if you need to send a longer string you must break it up into multiple commands.

It might be important to mention in the section that warns: "IMPORTANT: Envisalink Application Firewall", that the TCP sequence, including the login id, password, and PIN is NOT encrypted. This means that using an application to access the TPI or envisalink web page directly from outside of your home network is ill advised, changing the default password and using a PIN is insufficient - maybe even dangerous. The password and PIN is exchanged in the clear and visible to anyone sniffing the stream, and a bot can keep trying passwords & pins till it gets through.

I say this as many assume that sensitive data like passwords are safe to send. They're safe only if a lock symbol should be seen on the browser or encryption is used in the API. This is not the case on the envisalink's web page nor TPI. So it's best to use the eyezon service for remote access.

My visit was to ask about the 616 event, but I see that's been clarified to apply to the EVL3 and EVL4 only (I use a 2DS and it's not being delivered).

I wasn't able to find information about what is returned when the TPI is blocked by the envisalink firewall. I've seen my app report an invalid checksum - is this a sign that the request has been blocked? (I'm using a 2DS so I'm not able to check this myself).

mikep wrote:I wasn't able to find information about what is returned when the TPI is blocked by the envisalink firewall. I've seen my app report an invalid checksum - is this a sign that the request has been blocked? (I'm using a 2DS so I'm not able to check this myself).

No, it just resets the TCP socket upon connection. So you will actually get an RST packet as opposed to no response to your SYN.

The 2DS firmware has the safety firewall in as well.

Ok, that's easy, thanks! The bad checksum must a network problem.

K-Man wrote:

mikep wrote:I wasn't able to find information about what is returned when the TPI is blocked by the envisalink firewall. I've seen my app report an invalid checksum - is this a sign that the request has been blocked? (I'm using a 2DS so I'm not able to check this myself).

No, it just resets the TCP socket upon connection. So you will actually get an RST packet as opposed to no response to your SYN.

The 2DS firmware has the safety firewall in as well.

First: A data point from my own observation of the firewalling on the HTTP port (not the TPI port, which might be different) - The TCP connection is established, the 3-way handshake complete, THEN the connection is closed, so a RST (reset) is sent. No bytes are actually received by the client. (Again this is the HTTP port not the TPI port.)

mikep wrote:Ok, that's easy, thanks! The bad checksum must a network problem.

I would guess that there is no network problem. If there were a checksum problem at the network level, the app wouldn't really be aware of it, as TCP arranging for a retransmit would all happen in the OS (kernel) level and wouldn't be passed up to the stack to the user (application) level on most operating systems.

What's probably happening is that the app has a minor bug, the socket read() completes with a length of 0 or -1 to let the app know the connection has been closed, and collect the error. So I would guess the app doesn't check that it has an empty buffer before attempting to verify the checksum. The checksum therefore fails and you get your misleading error message.

Hope this helps,

Thanks. I am using the TPI port and typically I'm catching connect-reset ok (e.g. when the envisalink TPI is already in use by another client). I do test for EOS as in the TPI (and unlike in HTTP) this signals the TPI connection has been terminated and is an error. Up till now I haven't had a need (or knew that I could!) test the firewall response.

But if the envisalink is responding with an EOL character (marking a TPI command end) with no other data before sending the connect-reset I would indeed mark it as a checksum error (arguably properly) - hence my original question asking what it does .

IIRC valid messages will always end in CRLF, and be a minimum of 5 data bytes -- 3 digit command/response code + 2 digit checksum.

So if you've got less than 5 data bytes and/or the message doesn't end in CRLF, you've got a short read and couldn't have something valid to checksum.