EnvisaLink Ademco Plug-in - Beta Testing

[PCK]

Spud,

Of course it won't fail now when you want it to but when it does I should get a txt msg from Envisalink that the TPI connection closed. When that happens I will test the two items you mentioned.....


--Pete

[spud]

version 3.0.0.11

in version 3.0.0.11 available from first post, if envisalink fails to respond in less than 30seconds, the plugin will drop the connection and try to reconnect.

please test and let me know how it goes

[PCK]

in version 3.0.0.11 available from first post, if envisalink fails to respond in less than 30seconds, the plugin will drop the connection and try to reconnect.

please test and let me know how it goes

I will load 3.0.0.11 and let you know, currently on 3.0.0.10.....

--Pete

[PCK]

I caught an error and it's reconnection......

--Pete

[PCK]

Here you go.... I caught a disconnect and reconnect under debug running with the 3.0.0.11 plug-in.....


--Pete

[spud]

Here you go.... I caught a disconnect and reconnect under debug running with the 3.0.0.11 plug-in.....


--Pete

thanks
so, in both those logs it seems that the plugin eventually reconnect successfully, right? Is everything ok once it has reconnected successfully?

The problem is on the envisalink side, at some point it seems to get stuck or drop the connection and then it takes some time before it is ready for another connection. I'm going to email envisacor about this problem but I can't do much more.

One thing you can try is to add this line in EnvisaLinlkAdemco.ini in the panel section:

poll_zone_state_interval=30

restart the plugin after it's done.
It will tell the plugin to poll for zone states every 30s instead of every 5s which is the default value. Maybe polling less frequently will help envisalink to stay connected but this is a long shot.
This polling mechanism is only used to tell if a zone has been closed, so when a zone is closed it will take about 30s for the corresponding device to be updated, but if a zone is opened the update should still be almost instant.

[PCK]

After a reconnection everything seems to be ok. I'm going to leave my polling set to the default for now since the issue does not occur very frequently.

Let us know what you hear from envisacor.


--Pete

[virtualadam]

Looks like the fix works. thanks.

I've attached my log from the day. Seems to take a few minutes until it reconnects, and surprising how frequently it occurs. Interested to see if the vendor can resolve this in the future with a firmware update...

[PCK]

After running this version for a few weeks with the default polling setting of 5 seconds, I was seeing the following:

1. Open zones flipping between opened and closed on the device list and the associated status change messages in the logs.
2. Frequent, many times in a 24 hr day, TPI logoff and log on's, and disconnects and reconnects.

I adjusted the polling to 10 seconds, poll_zone_state_interval=10, in the ini file and it really settled things down for me. The initial testing is good, longevity testing will be the determining factor. I'm using the state of the zones to shut down HVAC in rooms with open windows or the entire system if the system is set in AWAY mode. That's why I needed solid accurate stability....

--Pete

[PCK]

After running this version for a few weeks with the default polling setting of 5 seconds, I was seeing the following:

1. Open zones flipping between opened and closed on the device list and the associated status change messages in the logs.
2. Frequent, many times in a 24 hr day, TPI logoff and log on's, and disconnects and reconnects.

I adjusted the polling to 10 seconds, poll_zone_state_interval=10, in the ini file and it really settled things down for me. The initial testing is good, longevity testing will be the determining factor. I'm using the state of the zones to shut down HVAC in rooms with open windows or the entire system if the system is set in AWAY mode. That's why I needed solid accurate stability....

--Pete

If course no sooner had I posted this than it started acting up as before and no change in the polling setting made a difference, it just extended the pain if you will. I thought I was on to something but I guess not.

Spud, have to heard anything from Envisacor?

--Pete

[spud]

If course no sooner had I posted this than it started acting up as before and no change in the polling setting made a difference, it just extended the pain if you will. I thought I was on to something but I guess not.

Spud, have to heard anything from Envisacor?

--Pete

Not yet, I emailed them again today

Note: when you change the polling setting you need to restart the plugin before it takes effect.

[PCK]

Not yet, I emailed them again today

Note: when you change the polling setting you need to restart the plugin before it takes effect.

Ok.

Yes I was restarting the plug-in when I made any changes.


Thanks
--Pete

[spud]

quick update: I got an answer from Envisacor:

The Ademco BETA period ended with absolutely zero BETA testers so I’m not surprised there are issues. The Ademco TPI is a bit of side-project as there is very little demand for Ademco panels. Hence, I have not upgraded the TPI documentation beyond 0.1 pre-release.

I explained them the problems we have and they are going to look at them, so there is hope!

[spud]

1. Open zones flipping between opened and closed on the device list and the associated status change messages in the logs.

Pete,
Could you get me the debug logs when this happens?
One thing that may make this happen more frequently is having several open zones at the same time. Could you try to open several zones (at least 3 or 4), see if the problem occurs, and send me the logs.

If I'm right this is something I can try to fix.

[virtualadam]

After running this version for a few weeks with the default polling setting of 5 seconds, I was seeing the following:

1. Open zones flipping between opened and closed on the device list and the associated status change messages in the logs.
2. Frequent, many times in a 24 hr day, TPI logoff and log on's, and disconnects and reconnects.

I adjusted the polling to 10 seconds, poll_zone_state_interval=10, in the ini file and it really settled things down for me. The initial testing is good, longevity testing will be the determining factor. I'm using the state of the zones to shut down HVAC in rooms with open windows or the entire system if the system is set in AWAY mode. That's why I needed solid accurate stability....

--Pete

Hi, Where can I find this setting? I tried looking in the EnvisaLinkAdemco.ini file, but it's empty? If this help with the issue I wonder if this could be added as a configuration item in a future version...until the vendor resolves the root cause....