Help Troubleshooting RC80 with Elk M1G

[mstarks01]

I have a functional RC-80 thermostat, but only as it relates to manual operation. It won't talk to my Elk at all. A bit of history..

I had the thermostat basically working. I could control it from the Elk and the tasks seemed to work. But after awhile, I noticed that certain temps wouldn't be set. I viewed the forums here, saw posts that said I should set hold to off and so on, but nothing gave it 100% reliability. So, besides the rules, here is what I have done:

1. Upgraded firmware on M1XSP to 70.x, at the suggestion of Elk support.
2. I re-did all my connections. I was sending each flying lead down a twisted pair of CAT5, using but splices. I wasn't sure if I would have issues that way, so I replaced it with single wire to single wire and used wire nuts instead.
3. I checked the connections from the M1XSP to the Elk and even re-enrolled the device. It finds it just fine.
4. I checked the jumpers on the M1XSP about 10 times, thinking maybe I missed something. They all match what is in the M1XSP manual.
5. I triple-checked the thermostat settings to make sure the address and other settings were correct.

At this point the Elk can't find the thermostat at all. I'm thinking I have a basic connectivity problem. Could it be that CAT5 isn't thick enough for the RS-232? It seems to me like that should be fine.

One things I noticed was that on the M1XSP there is a light which blinks about once per second. Not sure if that's normal...

I would welcome any basic troubleshooting steps I could perform at the physical layer. If this were ethernet I would just pop a sniffer inline to see what was happening, but I really don't know how to troubleshoot RS-232.

Thanks in advance.

 

[ddennerline]

You may want to check your RS-485 bus to ensure that it's properly terminated, and all devices have sound connections. There are a plethora of posts related to Elk RS-485 integration. I had a problem where somehow, after installation, one of the keypad data wires, became slightly unhooked. This caused several random problems with my M1XSP. I accidently found out the problem when I reordered my RJ-45 connections at M1DBH. Suddenly, the wireless receiver could not be found during startup. If I moved the keypad to last RJ-45 position, then system would boot without any errors – albeit with hidden/unreliable gremlins.

I wish that all Elk devices/controllers had a M1DBH compatible RJ-45 connector because this configuration would make it easier to verify termination using an Ethernet/LAN checker. I suspect a good majority of people are using a M1DBH. I too used red butt splice connectors, but it’s nearly impossible to be 100% certain everything is securely fastened.

 

[ddennerline]

The light switch should blink once per-second. It may blink faster when data is being exchanged over the RS-232 link. If no blinking, then you have a problem.

 

[mstarks01]

Well, after much banging of my head (which is not as fun as when I was a teen), out of desperation I decided to roll back the M1XSP firmware from the 70.0.2 Ominstat version to the stock version, 1.0.42. So, my HAI RC-80 doesn't seem to like the Ominstat firmware but it does like the stock firmware. Or, at least I hope it does. At least I can talk to the thermostat now.

 

[signal15]

How long is your RS-232 run? Anything approaching or over 50 feet might give you sketchy results.

 

[mstarks01]

How long is your RS-232 run? Anything approaching or over 50 feet might give you sketchy results.

It was probably 50-60 feet, but I shorted it to about 12 feet. It doesn't seem to have made a difference to the original problem. Last night the "night mode" kicked in. I watched the thermostat receive the remote command but it did not set the temp correctly. However, when it was armed away earlier in the day it did set it back. This flakiness is driving me nuts!

 

[mstarks01]

Here's an update. Maybe someone will find this familiar. I also sent this to Elk support:

Well, I have run a few more tests. I'm currently using 1.0.42 since that at least allows me to communicate. Here's what I did with some interesting results:

Using the web interface, I sat down on a chair in front of the thermostat and changed the temp by one degree 20 times. I waited about 5-10 seconds between each attempt so I could observe the thermostat receiving the change. Out of 20 attempts, 19 were received and it changed to the right temp. I'll take that as acceptable for now.

Here's the more interesting test. I fired off my various rules for different thermostat settings (comfort, away, etc) and I found that the thermostat changes the setting to whatever the *previous* attempt was. For example, if I file off the comfort setting, and the attempt prior to that was the away setting, then it changes it to the away setting. If I then change it to the vacation setting (after the comfort), it would change to the comfort. Strange, indeed (to me, anyway).

 

[jcrack_corn]

well, i could be wrong, but i'm pretty sure your problem is jumper S1 is set to 0.

the HAI omnistat firmare requires jumper changes to function, the m1xsp manual says for 300 baud (or HAI therms) to set
s1, s2, s3 to zero.

with new HAI firmware, with your RC-80 the jumpers should now be:
s1 = 1
s2 = 0
s3 = 0


so move jumper s1 up to 1 and you should be could to go, with very good communication in my experience....it is a really good firmware update.

 

[mstarks01]

I have some good news. As best as I can tell, everything is working correctly now. I think the troubles were caused by a few things: the generic firmware does not work so well for the RC-80, the RS-232 length was too long, and, as noted above, the S1 jumper setting was incorrect for the Omnistat firmware. It's always more difficult to troubleshoot something with more than one root cause, but as of now, the thermostat is changing to the correct temp based on the rules. I'm going to monitor for the next week or so but I really do think we're all set.

Thanks everyone for your help.