Envisalink - TPI Documentation

[K-Man]

Yep, its a standard TCP socket, so it will stay open as long as there is traffic. The Envisalink does not support the optional SO_KEEPALIVE so you need traffic either from the TPI or to the TPI to keep it open. I think the window is 5 minutes.

I use the TPI with the Micasaverde HA system and it keeps the socket open for days.

[Ken98045]

I've been sending a poll every minute. That should be keeping it alive. I've also periodically been requesting timer dumps. However, I get into a state where I can successfully send data to the card but the receive side blocks indefinitely after some time averaging about 15 minutes. The longest I've gone is about 24 minutes.

I know that there is alarm side activity, but nothing is being received on my side.

I've been doing TCP programming for 20 years or so, so hopefully I know what I'm doing. It's a very remote possibility that it is a router or PC issue, but that doesn't seem likely. The only think I can think of is that the paid monitoring is somehow interfering, but...

Any ideas would be appreciated.

[mitalum]

I have written (in TCL) a simple TPI client which decodes, timestamps and logs all TPI commands from the envisalink 3. The client can detect socket errors, like the connection closed or reset by the server. In order to make this more reliable, the client sends a poll application command every 2.5 second. If the client is about to send the third poll command without having received any intervening TPI commands, then it closes the connection and attempt to reconnect.

I have seen cases where the client closes the connection and reconnects immediately without error. I have also seen cases where the client continuously keeps closing and reconnecting for 2 minutes. After connecting, the client immediately detects an error and closes and tries to reconnect. I believe the error is due to the server sending a RST flag. After the 2 minutes, a connection is established and the server sends the login request TPI command. I have tried inserting small delays, etc, but it does not help. It seems to take the full 2 minutes to get back to a good state.

I have seen a case where I killed the client without closing the connection and when I restarted it, the client stayed in the connect, close, reconnect loop indefinitely. I had to web into the device to reboot it to get it back to a good state.

So, my question is about the embedded TCP stack on the device. It seems that it gets into a waiting state. Is there any way from the client for me to get a connection without losing 2 minutes. Perhaps the server could have a mode where it automatically closes the socket connection if it does not receive a poll command within 2 seconds of receiving the previous poll command.

I appreciate any thoughts on this.

John

BTW - here is a sample of the output from my client:

Code: Select all

Tue Jul 30 20:02:32 EDT 2013: Connecting
Tue Jul 30 20:02:32 EDT 2013: Connected
Tue Jul 30 20:02:34 EDT 2013: Login Interaction (505), Status = Password Request (3)
Tue Jul 30 20:02:34 EDT 2013: Login Interaction (505), Status = Successful (1)
Tue Jul 30 20:03:02 EDT 2013: Zone Open (609), Zone = Living Room Motion (013)
Tue Jul 30 20:03:02 EDT 2013: Partition Ready - Force Arming Enabled (653), Partition = Main (1)
Tue Jul 30 20:03:04 EDT 2013: Zone Restored (610), Zone = Living Room Motion (013)
Tue Jul 30 20:03:04 EDT 2013: Partition Ready (650), Partition = Main (1)
Tue Jul 30 20:05:32 EDT 2013: Zone Open (609), Zone = Family Room Motion (014)
Tue Jul 30 20:05:32 EDT 2013: Partition Ready - Force Arming Enabled (653), Partition = Main (1)
Tue Jul 30 20:05:34 EDT 2013: Zone Restored (610), Zone = Family Room Motion (014)
Tue Jul 30 20:05:34 EDT 2013: Partition Ready (650), Partition = Main (1)
Tue Jul 30 20:05:41 EDT 2013: Zone Open (609), Zone = Family Room Motion (014)
Tue Jul 30 20:05:41 EDT 2013: Partition Ready - Force Arming Enabled (653), Partition = Main (1)
Tue Jul 30 20:05:43 EDT 2013: Zone Restored (610), Zone = Family Room Motion (014)
Tue Jul 30 20:05:43 EDT 2013: Partition Ready (650), Partition = Main (1)
Tue Jul 30 20:27:01 EDT 2013: Zone Open (609), Zone = Study Windows (009)
Tue Jul 30 20:27:01 EDT 2013: Keypad LED State (510): +Backlight -Fire -Program -Trouble -Bypass -Memory -Armed -Ready (80)
Tue Jul 30 20:27:01 EDT 2013: Partition Not Ready (651), Partition = Main (1)
Tue Jul 30 20:27:05 EDT 2013: Zone Restored (610), Zone = Study Windows (009)
Tue Jul 30 20:27:05 EDT 2013: Keypad LED State (510): +Backlight -Fire -Program -Trouble -Bypass -Memory -Armed +Ready (81)
Tue Jul 30 20:27:05 EDT 2013: Partition Ready (650), Partition = Main (1)

[brientim]

Attached is the latest TPI documentation for the Envisalink 2DS and the Envisalink 3 (DSC only).

Hello,

I have searched the forum and I cannot locate the Honeywell TPI. Do you have the link to the post which contains it or the file location so I can download it.

[GrandWizard]

It doesn't exist. It's been on the way for months but there's been non-technical issues holding back its release.

[brientim]

Thanks Grand Wizard.

[billyrusa]

Can Honeywell TPI be released in the near future? Or, it will not be release forever due to non-technical issues?

[GrandWizard]

It will be in BETA within 2 weeks. There will be a BETA annoucement from Envisacor at that time on this forum.

[billyrusa]

That is a great news! Thanks a lot, GrandWizaed.

[Jason]

Is there an equivalent API for the website? Since the Envisalink already knows how to talk to the website, it would be nice to be able to use the website as a proxy so that you can interact with the Envisalink without having to poke holes in the firewall or have dedicated hosts.

Is this possible?