Is there any newer TPI, API, SDK's released???

[mcseprofession]

I mainly use c# and wanted to develop an app for the Envisalink 3 for honeywell but I was wondering if there was any newer documentation for TPI, or API then whats posted

[K-Man]

No, what is on this forum is the latest. I am open to suggestions if anyone has any for improvements.

[mcseprofession]

ok, thanks... I just started so if I come across anything I will..

[MattTW]

Since you asked, K-Man, I have a few thoughts about the Ademco version of the TPI:

• - As I think others have pointed out on this forum, the %01 zone state change event seems buggy. You indicated it is based on keypad "Fault" messages, but even assuming that some zone state changes could be missed this way, my experience is that %01 events do not seem to occur consistently when they should. This reduces the usefulness of the API considerably.
  
  - Very rarely, I see an event come back from the TPI that looks like: %...part of an event...%...another event...$ - in other words it looks like the TPI is sending back one event partially overwritten by another event. This is easy enough to ignore but seems like a bug on the Envisalink side. Could be a bug on my side although it seems doubtful. I am using the Python asynchat stuff.
  
  - Occasionally the login process will fail even though a trace shows all the data being sent back and forth was correct (password is hardcoded). Trying again a few seconds later with the exact same data works.
  
  - It would be nice if the "Dump Zone Timers" portion of the API was a little more human friendly. I have written code to do what I need, but many folks trying to use that part of API will be way over their heads.
  
  - Overall the API works well and is very usable - thank you. The version number is indicated as .01 - which would suggest to most people that it is a very early incomplete alpha. That may discourage some from even trying to use it. Maybe revise the version number to 1.0 beta or something like that.

Thanks!
Matt

[K-Man]

Since you asked, K-Man, I have a few thoughts about the Ademco version of the TPI:

• - As I think others have pointed out on this forum, the %01 zone state change event seems buggy. You indicated it is based on keypad "Fault" messages, but even assuming that some zone state changes could be missed this way, my experience is that %01 events do not seem to occur consistently when they should. This reduces the usefulness of the API considerably.

I am going to update the documentation as this is the most asked question among the registered developers. Zone change faults happen as soon as the Fault message appears. The Ademco panels do not inform its peripherals if a zone closes (restores) so the Envisalink has to infer this.

- Very rarely, I see an event come back from the TPI that looks like: %...part of an event...%...another event...$ - in other words it looks like the TPI is sending back one event partially overwritten by another event. This is easy enough to ignore but seems like a bug on the Envisalink side. Could be a bug on my side although it seems doubtful. I am using the Python asynchat stuff.

If you're a registered developer, log a bug. Otherwise PM me.

- Occasionally the login process will fail even though a trace shows all the data being sent back and forth was correct (password is hardcoded). Trying again a few seconds later with the exact same data works.

See above. Send lots of packet captures.

- It would be nice if the "Dump Zone Timers" portion of the API was a little more human friendly. I have written code to do what I need, but many folks trying to use that part of API will be way over their heads.

Well to be honest, the biggest complaint among developers is that the TPI is too human friendly, especially the DSC version. The TPI is used by machines so it should cater to machines. Many people want to implement light-weight interfaces and cringe at the thought of parsing XML, or handling JSON. Makes me squirm too.

- Overall the API works well and is very usable - thank you. The version number is indicated as .01 - which would suggest to most people that it is a very early incomplete alpha. That may discourage some from even trying to use it. Maybe revise the version number to 1.0 beta or something like that.
[/list]

Yes, I will do this. I have been procrastinating due to the lack of interest on the Honeywell side. For the DSC BETA we had 30 registered developers and nearly 400 BETA testers. For Ademco, one, and that guy may have registered in hopes of a free T-shirt.

[MattTW]

Thanks for the reply K-man.

How does one become a registered developer? If that is in these forums anywhere, then I missed it.

I will see if I can capture a couple of the bugs I mentioned. I do have debug info at the app level which shows the issues, I will set up a packet sniffer and see what is coming across at that level.

re: the zone dump timers being human friendly. That was a poor choice of words. Agreed that the API should cater to machines. My point was that the zone dump timers stuff is very low level: endianness, hex, etc. Great if your client is C, not so great in most other languages. You pretty much need a Com Sci degree to have any hopes of translating it. Don't get me wrong, it is certainly doable in relatively few lines of code - *if* you know what you need to do. It would be possible to provide the same data in a more consumable fashion and still be machine friendly. For hobby level folks that are likely using a scripting language, it can get a bit gnarly. Just my two cents.

What? Free T-Shirt?

Thanks!
Matt

[K-Man]

Just PM me and I'll give you my email address.

uint16_t zone_timers[64]; /* Little Endian CPU of course*/

memcpy((uint8_t *)zone_timers, buffer, 128);

printf("Zone 4 closed %d seconds ago\n", (0xFFFF - zone_timers[3]) * 5);

I love C;