ISY handling of Venstar communications

[MuchHat]

Hello

 

I have two Venstar thermostats and while one of them works flawlessly with ISY the other one seems to have consistenly a problem talking to.

 

This is what I found puzzling:

- I have an Access Point just 6 feet in front of the Venstar having the issue.

- In the same outlet with the Access Point I have tried a RelayLinc that works 100% reliable responding to all ISY commands.

- Still ISY cannot talk to the Venstar next to that Access Point. The success rate is more like 30% or less.

 

Looking in the evenlog I see the following pattern:

1) A request from ISY to Venstar goes out.

2) After 5-10 seconds or so that same request goes out again a couple of times

3) Then I see an ERR 1

4) Then after few more seconds a bunch of responses from Venstar come up

5) Then an ERR 0 shows up

 

Unfortunately the data in ISY is not updated correctly after step 5 (e.g. the temp does not match what the thermostat has). The same pattern happens if let's say I want to change the heatpoint from ISY or I click "query".

 

In step 3 the ISY will put a (!) in front of the thermostat in the UI. However in step 5 that (!) is taken away indicating everything is fine, except is not. The "responding" attribute for the thermostat device in ISY mirrors the (!)

 

I see two problems I would appreciate some insight into:

 

(a) Is ISY timing out too soon? And not waiting enough for the response from Venstar?

It appears to me in many cases the communication from Venstar is eventually coming back but ISY already puts the ERR 1 then ignores what comes in from Venstar after that point.

 

( Looks like ISY looks at just the last error in order to determine if it needs to display the (!).

In this case this is misleading since the thermostat info is not actually processed by ISY since it came in step 5 after the initial ERR 1 but before the last ERR 0

 

This is the log (the thermostat is 14.86.4B, towards the end of the log there is some other traffic in there) :

 

Any insights are appreciated.

 

Tue 01/08/2013 08:42:07 : [iNST-TX-I1 ] 02 62 14 86 4B 0F F0 E8

Tue 01/08/2013 08:42:07 : [iNST-ACK ] 02 62 14.86.4B 0F F0 E8 06 (E8)

Tue 01/08/2013 08:42:16 : [iNST-TX-I1 ] 02 62 14 86 4B 0F F0 E8

Tue 01/08/2013 08:42:16 : [iNST-ACK ] 02 62 14.86.4B 0F F0 E8 06 (E8)

Tue 01/08/2013 08:42:25 : [iNST-TX-I1 ] 02 62 14 86 4B 0F F0 E8

Tue 01/08/2013 08:42:25 : [iNST-ACK ] 02 62 14.86.4B 0F F0 E8 06 (E8)

Tue 01/08/2013 08:42:29 : [iNST-TX-I1 ] 02 62 14 86 4B 0F F0 E8

Tue 01/08/2013 08:42:29 : [iNST-ACK ] 02 62 14.86.4B 0F F0 E8 06 (E8)

Tue 01/08/2013 08:42:38 : [iNST-TX-I1 ] 02 62 14 86 4B 0F F0 E8

Tue 01/08/2013 08:42:38 : [iNST-ACK ] 02 62 14.86.4B 0F F0 E8 06 (E8)

Tue 01/08/2013 08:42:46 : [iNST-TX-I1 ] 02 62 14 86 4B 0F F0 E8

Tue 01/08/2013 08:42:46 : [iNST-ACK ] 02 62 14.86.4B 0F F0 E8 06 (E8)

Tue 01/08/2013 08:42:50 : [ 14 86 4B 1] ERR 1

Tue 01/08/2013 08:42:50 : [iNST-TX-I1 ] 02 62 18 9B 14 0F 11 38

Tue 01/08/2013 08:42:50 : [iNST-ACK ] 02 62 18.9B.14 0F 11 38 06 LTONRR (38)

Tue 01/08/2013 08:42:54 : [iNST-SRX ] 02 50 14.86.4B 19.71.C3 07 6F 50 (50)

Tue 01/08/2013 08:42:54 : [std-Direct ] 14.86.4B-->ISY/PLM Group=0, Max Hops=3, Hops Left=1

Tue 01/08/2013 08:42:54 : [ 14 86 4B 1] ERR 0

Tue 01/08/2013 08:42:54 : [ 14 86 4B 1] CLIHUM 80

Tue 01/08/2013 08:42:54 : [iNST-SRX ] 02 50 14.86.4B 19.71.C3 03 6F 50 (50)

Tue 01/08/2013 08:42:54 : [std-Direct ] 14.86.4B-->ISY/PLM Group=0, Max Hops=3, Hops Left=0

Tue 01/08/2013 08:42:55 : [iNST-SRX ] 02 50 14.86.4B 19.71.C3 07 6F 50 (50)

Tue 01/08/2013 08:42:55 : [std-Direct ] 14.86.4B-->ISY/PLM Group=0, Max Hops=3, Hops Left=1

Tue 01/08/2013 08:42:55 : [iNST-SRX ] 02 50 14.86.4B 19.71.C3 07 6F 50 (50)

Tue 01/08/2013 08:42:55 : [std-Direct ] 14.86.4B-->ISY/PLM Group=0, Max Hops=3, Hops Left=1

Tue 01/08/2013 08:42:55 : [iNST-SRX ] 02 50 14.86.4B 19.71.C3 03 6F 50 (50)

Tue 01/08/2013 08:42:55 : [std-Direct ] 14.86.4B-->ISY/PLM Group=0, Max Hops=3, Hops Left=0

Tue 01/08/2013 08:43:07 : [iNST-TX-I1 ] 02 62 18 9B 14 0F 11 1C

Tue 01/08/2013 08:43:07 : [iNST-ACK ] 02 62 18.9B.14 0F 11 1C 06 LTONRR (1C)

Tue 01/08/2013 08:43:24 : [iNST-TX-I1 ] 02 62 18 9B 14 0F 11 0F

Tue 01/08/2013 08:43:24 : [iNST-ACK ] 02 62 18.9B.14 0F 11 0F 06 LTONRR (0F)

Tue 01/08/2013 08:43:40 : [iNST-TX-I1 ] 02 62 18 9B 14 0F 11 07

Tue 01/08/2013 08:43:40 : [iNST-ACK ] 02 62 18.9B.14 0F 11 07 06 LTONRR (07)

Tue 01/08/2013 08:43:57 : [iNST-TX-I1 ] 02 62 18 9B 14 0F 14 00

Tue 01/08/2013 08:43:57 : [VAR 2 14 ] -3

Tue 01/08/2013 08:43:57 : [iNST-ACK ] 02 62 18.9B.14 0F 14 00 06 LTOFF-F(00)

Tue 01/08/2013 08:43:57 : [VAR 2 2 ] 0

Tue 01/08/2013 08:43:58 : [iNST-TX-I1 ] 02 62 18 9B 14 0F 14 00

Tue 01/08/2013 08:43:58 : [iNST-TX-I1 ] 02 62 18 9B 14 0F 19 00

Tue 01/08/2013 08:43:58 : [iNST-ACK ] 02 62 18.9B.14 0F 14 00 06 LTOFF-F(00)

Tue 01/08/2013 08:43:58 : [iNST-ACK ] 02 62 18.9B.14 0F 14 00 06 LTOFF-F(00): Duplicate or ACK for a different device

Tue 01/08/2013 08:43:59 : [iNST-ACK ] 02 62 18.9B.14 0F 19 00 06 LTSREQ (LIGHT)

Tue 01/08/2013 08:43:59 : [iNST-SRX ] 02 50 18.9B.14 19.71.C3 23 14 00 LTOFF-F(00)

Tue 01/08/2013 08:43:59 : [std-Direct Ack] 18.9B.14-->ISY/PLM Group=0, Max Hops=3, Hops Left=0

Tue 01/08/2013 08:43:59 : [iNST-SRX ] 02 50 18.9B.14 19.71.C3 23 14 00 LTOFF-F(00)

Tue 01/08/2013 08:43:59 : [std-Direct Ack] 18.9B.14-->ISY/PLM Group=0, Max Hops=3, Hops Left=0

 

Thank you

 

MuchHat

[Michel Kohanim]

Hi MuchHat,

 

There was indeed a bug with 3.2.x releases not showing ! properly. This is a UI bug only. So, first, I do recommend upgrading to 3.3.8 (viewtopic.php?f=25&t=10339). If you don't wish to upgrade to 3.3.8, please try the UI for 3.3.8:

http://isy.universal-devices.com/99i/3.3.8 ... let me know if this exhibits the same behavior

 

As far as communications with your thermostat, the only thing I suggest is swapping them (shouldn't be that difficult). If the problem moves with the thermostat, then the problem is the thermostat itself. If the problem stays with the location then we have to figure out what's interfering with signals at that location.

 

With kind regards,

Michel

[MuchHat]

Thank you for the suggestion.

 

Swapping the thermostats did not make a difference. Indeed the trouble causing one sits next to a big airduct (in the wall) that goes from the crawl space all the way up. That might cause interference, however I cannot move the thermostat from there.

 

The problem got eventually solved by moving the ISY to a another location in the house. I had to connect the ISY to its own wifi bridge since in that location I do not have an internet cable.

The ISY is now in the family room literally under the couch - wifi bridge and all. Of course it has its own access point plugged in next to the ISY.

For some reasons that location is better then the 2nd floor bonus room or garage or computer room or next to the electrical panel.

 

Literally what I did was build a bundle made out of : ISY + one access point + wifi bridge and I kept plugging that in around the house. I must have tried a dozen locations.

 

Maybe next version of the ISY comes with an access point strength radio and its own wifi bridge to make this simpler.

 

I have now 6 access points spread around, this is a regular 2 story house (3600sqf).

I'm not clear on the "too many" or "too few" access points and if indeed adding more access points strengthens or weakens the Insteon network.

 

For the time being all works well with the new setup.

 

Thank you,

 

MuchHat

[Michel Kohanim]

Hello MuchHat,

 

Thanks so very much for the update. So, the problem is in that location. Can you tell me whether or not you have a baby monitor in that location?

 

What you have gone through, and especially since you have all those access points, is really not normal.

 

With kind regards,

Michel

[MuchHat]

Thank you for the followup. I do not have a baby monitor.

 

I have the following:

- Wireless phones that are supposed to be on the 5.2Ghz.

- 2 Wifi routers dualband on the 2.5Ghz band and the 5Ghz band.

- There are a lot of Wifi networks around (at least 4-5) from neighbor houses.

- I do have an Honeywell Ademco Vista security system that has a couple of RF sensors (like the smoke detector and a few door sensors). Those might be on the 345Mhz (+/- 85Mhz) according to one spec (http://www.geoarm.com/2wb-i3-system-sen ... ector.html). I'm not sure on the frequency for those.

 

Are there any other sources of RF interference I should be looking at?

 

MuchHat

[Michel Kohanim]

Hi MuchHat,

 

Thank you. INSTEON RF frequency is in the 900MHz range. So, I do not think any of the devices you have listed would interfere.

 

This is quite a mystery.

 

With kind regards,

Michel

[MuchHat]

I have the mystery partially solved.

 

In short : two access points in close vicinity of each other might prevent both of them from communicating with an RF device within both their ranges. The access points might talk to each other well but not with the Venstar that sits between them.

Possible the Venstar ends up spinning cycles trying to respond to two separate Insteon addresses, not sure, however moving one of the access points further and unplugging the other helped to the point ISY now talks to the Venstar with 1 or even 2 hops left. Reliability is at about 80%-90% and that is enough with few extra retries in the code.

 

This is what I did:

- I took one of the Venstar thermostats and hooked up to a 24v transformer such I can walk around with it in the house and see where it can communicate from and where not.

- I had a tablet with ISY interface running and keep hitting "query on the venstar" and watch the eventlog. That way one can almost measure the quality of the communication in any spot (even between sockets)

- Interesting enough in this bout 6x6 feet area between two access points the Venstar acted like ISY did not send any request - 0% communication. I can see the request in eventlog but no response at all from Venstar not even a hops left=0 or anything.

- I move the (portable) Venstar just 3 feet outside of that area between access points and a huge difference HopsLeft=2. And I can repeat this with 100% repro moving in and out.

- Then I unplugged one of the access points and moved the other one into another socket few feet away. All of a sudden Venstar worked and the 6x6 feet dead area vanished.

 

The learning seems to be:

- It is possible that too many access points within the range of one RF device might create a radio jam resulting in poor communication with that device.

- It might be better to position the access points at some distance from each other to avoid a radio jam.

- If you have an RF device you can walk around with you can turn it into be an effective debugging tool when used in conjunction with the ISY query capability and the eventlog

 

Thank you all again for chiming in. I'm glad I found a reasonable solution and all your folks' suggestions helped.

 

MuchHat