EyezOn Forum

io_guy wrote:Just started working with the Honeywell TPI.
I've connected to a system and get data but it seems like I'm missing some items.
%00, %02 and %FF come through, no issue.
%01 events do not appear to be coming through. When a zone breaks I see the %00 keypad update and the %02 partition change, but never see a %01.

Makes it a little difficult to get zone status info unless a force a zone timer dump every time I see a change. Am I missing something?

That command relies on a keypad update indicating which zones are "faulted". You will see the Alpha "FAULT ZONE X" on the keypad update. If this does not happen then the Envisalink doesn't know of the zone opening and can't issue the %01 command.

I do see the FAULT ZONE X coming through the system, but no %01.
If the EVL creates the %01 based on the %00 FAULT, I can just do that myself. Not sure why it's not working automatically.

How does the EVL compute zone closings?

@io_guy: I noted the same exact issue. You basically have to maintain your own state information for zone openings and closings which is what eyez-on must do.

Anyway, after some frustration and some lost coding time, I just went out and bought & installed a DSC panel. I believe my total cost with sensors and 7" color touchpad was ~$300. 4 hours to install. Well worth it if you're doing custom programming using TPI...there's so much more information coming out of that system.

HTH
-ShaneB

io_guy wrote:Just started working with the Honeywell TPI.
I've connected to a system and get data but it seems like I'm missing some items.
%00, %02 and %FF come through, no issue.
%01 events do not appear to be coming through. When a zone breaks I see the %00 keypad update and the %02 partition change, but never see a %01.

Makes it a little difficult to get zone status info unless a force a zone timer dump every time I see a change. Am I missing something?

I'm running into the same problem.
Is there more information available on this issue?
Is this going to be fixed in a future update?

I tried to use the zone timers dumps to workaround the zone status problem, but the timer dumps seem buggy as well. According to the TPI doc, an open zone is supposed to be reported as FFFF in the hex string dump, but according to my tests an open zone can also be reported as FEFF or FDFF.

Can someone from eyez-on comment on these Ademco TPI bugs, or give me a contact where I could report and discuss those bugs?

The TPI is supported by the manufacturer, Envisacor. Their main contact is K-Man on this forum, you can try and contact him directly.

We just post the docs here as a reference.

Good Morning.

Just bought the Envisalink 3 for my Ademco system. Slightly disappointed with the lack of commands available, but I'm making due.

I'm working in JAVA and I have a successful TCP Socket connection to my device, the immediate output from the device on connection is "Login:"

Using the DataOutputStream I writeBytes() including my 6 character password. I get no response unless I include "\n" at the end of the string, and that results in "FAILED"

Is there a specific format I need to send the password in?

Should it be encapsulated in %$ with a comma somewhere?

Should I include "\n" for a new line

You just need to terminate the string with a CR or a LF.

Are you sure your password is correct? Can you log in locally using that password?

I have verified that password within the web gui several times, it's good to go.

I will try and terminate with a CF or LF per your instructions. I didn't see that in the Ademco TPI documentation.

Should I terminate all my commands that way or just the password?

i tried both CR and LF and still got FAILED

Just to be clear Im passing "paswrdCR" just like that, no encapsulation or anything, again! On my ademco panel

I successfully telneted to it.