• You've been granted Beta access to this site, allowing you to explore some of the new features while they're still under construction. More information can be found in the Beta forum.

M1G Lightning Strike Damage Repair

TheHeadFL

Member
Well, this is my first post on this forum, so hopefully I am putting this in the right place... :)

To start with, I am a total newbie when it comes to the Elk products. I bought my house in 2009 and it was already equipped with an M1G and a touchscreen to control it. I had nothing to do with installing it, and the previous owners didn't leave me any documentation.

Since then I've tried learning a bit here and there about controlling it, but I am still sort of in the dark.

Anyway, last week I had a serious lightning strike very close to the house (although I don't think it hit the house). All my stuff is surge protected, but I believe this was inducted current on the low voltage circuits. I was actually home when this happened, and immediately the alarm speaker for the M1 system started going haywire. (Not a normal alarm sound, it sounded very unusual, like a piece of electronics dying, for lack of a better description) The only way I was able to stop the racket was by flipping the switch off on the M1G board itself.

Well, I troubleshot it quite a bit and determined that a simple reset wasn't going to do it. Even rebooting it, the horrible alarm sound would come right back when I flipped the switch on. I was unable to connect anymore via ElkRP and the touchscreen was also unable to connect. (Although I could ping the IP, which I assume runs on a separate board)

Reasoning that the M1G was blown, I ordered a new one (control board only) online. Finally got it tonight and put it in, using the terminal blocks off the old one so as to keep the same setup. Loaded it up in ElkRP, sent my saved programming to the device, and all is well. Well, except my thermostat doesn't seem to work with the M1 system anymore.

I have an HAI Omnistat 1 series. (122 I think?) It operates normally as a standalone unit, but I cannot seem to get it to respond to the Elk system.

Here were my troubleshooting steps:

- I have two M1XSPs. One for the HVAC, one for exterior lighting. Reasoned that maybe the M1XSP controlling the HVAC was dead.

- Powered off the M1 system entirely.

- Disconnected the 'known good' one that was running my lighting, and configured all of the jumpers and dip switches (address, baud rate, etc) identically to the one that was running my HVAC. Connected it up that way, making sure to move the terminator plug on the data bus to account for one less device.

- Fired up the M1 system.

- Verified that (as expected) I am no longer able to control lighting, but thermostat data is still not working.

- Removed HAI Omnistat from the wall and verify serial connection is still in place. It is. No visible damage or scorch marks.

- Replaced HAI Omnistat and verified that I am still able to operate HVAC. Still no thermostat data.

Does anybody have any idea how else I might test this? I am guessing I may need to buy a new thermostat, but I really am not looking forward to throwing more money at this problem without knowing what I'm doing. I'm already a few hundred in just with the M1G replacement.
 

tmbrown97

Senior Member
From what I remember, at least in my scenario, the lighting and thermostat XSP's have pretty different settings - I don't think just swapping them is a sufficient test - you'd need to ensure correct firmware and all dip switch settings.
 

TheHeadFL

Member
Well, based on what I could see, the dip switches and jumpers were configured for a few settings: 'baud rate', 'mode', 'address', and a handful of other single-jumper settings that were already configured identically.

To test, I configured those 3 settings identically.

The firmware versions obviously I have no idea how to verify.

So here is another question... with these serial interfaces... can I just hook it up to my laptop with a USB-serial cable (and the appropriate baud rate) and watch the console traffic? Should I be seeing anything being sent by the M1XSP or the thermostat itself?
 

TheHeadFL

Member
Well its not the thermostat... at least, I don't think.

Followed these instructions:

Testing Serial Communications to OmniStat2 via PC
Question:
Can I test the serial communications on the OmniStat2?


Answer: Yes. You will need a software application designed to send test commands. One such application is available for free download from H.A.C.K. Consulting (link removed). You can take the following steps:
Install the software. NOTE: Registration is optional, as the program will wait 15 seconds to load unless registered.
Go to Comm Port and set the following:
Port Number – this should match the serial port on your PC
Baud Rate – 300
Parity – none
Data Bits – 8
Stop Bits – 1
Handshaking – none
Click on OK. NOTE: do not check/uncheck either of the boxes at the bottom.
In the “Treat Input Data As” field, bullet Hexadecimal.
In the “Auto Response Settings”, select Never Send.
Click on COMM Port and select Connect.
In the “Data to Send” field enter 1 2 3 (remember to enter spaces) and click on “Send Data”.
This should yield a reply similar to:
Example Messages (Data shown in parenthesis are in Hex)

Host: Poll thermostat 1 for Group 1 data:

RA(01), DL/MT(02), CS(03)

Thermostat 1: RA(81), DL/MT(63), low setpoint(xx), high setpoint(xx),

mode(xx), fan(xx),

hold(xx), current temperature (xx), CS(xx)

Also referencing the serial protocol spec for the OmniStat RC series. (Sorry, won't let me link it)

Sent data 01 02 03, received:

FF
81 63 81 72 03 00 00 82 5C

This seems to be legitimate, as when I convert the hex values to decimal and reference the table in the OmniStat serial spec, the 'OmniTemp' numbers correspond to my real setpoints.

Ugh... even more lost now...
 

TheHeadFL

Member
Well I hooked the PC up to the M1XSP that was running my thermostat... and I listened on the serial port at 300 baud rate.

Sure enough, when the M1G boots up, I see the 01 02 03 message, which I assume is what I should be seeing... so I can 'confirm' that the M1XSP is working, the thermostat is working, but they don't work together??

I am baffled honestly... this all worked before and I just loaded the exact same configuration to the M1G!
 

TheHeadFL

Member
Discovered more non-working functionality... apparently none of my wireless zones are working. For example, when I click the arm button on my keyfob, I can see the receive lights on my M1XRF flash, but nothing seems to happen.

The only thing I can come up with at this point is that maybe my data bus card (M1DBH) is fried, but that seems extremely unlikely since it doesn't appear that it even contains any electronics...
 

WayneW

Senior Member
Well, based on what I could see, the dip switches and jumpers were configured for a few settings: 'baud rate', 'mode', 'address', and a handful of other single-jumper settings that were already configured identically.

To test, I configured those 3 settings identically.

The firmware versions obviously I have no idea how to verify.
Sounds like your XSP and/or RF module might not be enrolled into the new board?
Connect with ElkRP, go into send/rcv, then into enroll/update. It should list your devices and what type of firmware/feature is loaded into the XSPs. If in doubt, re-run the enroll process, you won't hurt anything. If your XSPs have the wrong flavor of firmware, this is the place to load the right flavor.
 

TheHeadFL

Member
Sounds like your XSP and/or RF module might not be enrolled into the new board?
Connect with ElkRP, go into send/rcv, then into enroll/update. It should list your devices and what type of firmware/feature is loaded into the XSPs. If in doubt, re-run the enroll process, you won't hurt anything. If your XSPs have the wrong flavor of firmware, this is the place to load the right flavor.

Turns out this was the exact problem. I actually just figured that out and was logging on to post that I had figured it out. This would have saved me a lot of frustration! :)

I guess thats what I get for assuming that the 'configuration' that I loaded via ElkRP contains *all* of the device configuration. I guess there is some device configuration that is independent of all of that.

Thanks for the help! On the plus side at least I think I'm starting to understand how this thing works...
 

tmbrown97

Senior Member
Funny - reading your last post, I'm thinking to myself "hrm - I wonder if it's just not enrolled?" then kept reading the last 2 posts.
 
Top