Elk M1G claiming to be in remote programming mode once a minute

I use an Elk M1G, CQC, and an ISY99i. Last night, I decided to upgrade to the latest ISY release and add their Elk module. The ISY module has firmware prerequisites of M1G 5.2.8 and M1XEP 1.3.28. My versions were older, so I upgraded, set everything up, and at first glance, all seemed good.

While checking things in CQC, I noticed that the M1G connection went offline, then came online. I then noticed that $LostCommRes was higher, and as I watched things, the connection kept going offline and coming back online.

Much troubleshooting ensued including sniffing the traffic from the M1G to both CQC and the ISY. I discovered that, once a minute, the M1G is sending the RP (remote programming mode entered) code, and then 10 seconds later, it sends the IE programming mode exited code. 50 seconds later, at the top of the next minute, here comes RP again, and then 10 seconds later, IE again.

This behavior remains the same whether just CQC is connected, just the ISY, or both.

I have two rules that run in the M1G once a minute, so just in case it could be rule related, I made a copy of my Elk configuration, deleted all rules in the copy, and sent that to the control. The behavior remained exactly the same.

FWIW, during the ten second interval, the M1XEP web interface also becomes non-responsive, although it doesn't display the "Panel has entered programming mode" message that appears when running ElkRP.

I have no idea where to look next to figure out the potential source of the problem. I also remember seeing a note that said bad things happen if you downgrade M1G firmware, so going backwards doesn't seem viable.

Anyone have ideas of where I might try troubleshooting next?

Chris

The firmware downgrade may have been my post of the M1XEP. The issue was with using a firmware with an incompatible bootware. As far as the M1 control is concerned i would guess there would be the same issue. If the old version you want to revert to uses the same bootware version you may be in luck. DON'T take my work for it. There are others here that confirm or deny my guess about versions.

I tried downgrading the M1G to 5.2.4, with no change. I looked closer at what the M1XEP is sending, and realized that it is sending that code (RP02) that indicates that it is rebooting once a minute. This points me back pretty directly at Elk, so I've contacted technical support for any last ditch efforts and/or return information.

Chris

It's now a month later, and I'm just as dead with this issue as before. In the interim, my M1G has gone back to Elk and been replaced, but once a minute, it will block for 10 seconds, then resume. I've had some discussions with Brad about the problem and gathered a lot of data, but haven't heard anything back since December 30. I don't know if he is out, or if I'm just left to oblivion on this issue since I'm just an end-user who purchased direct.

I wanted to know more about what was going on, so I put together a little protocol analyzer and threw it bewteen the M1G and the M1XEP. When the problem occurs, the M1G makes a clicking sound, which Brad indicates is some type of reset. When that happens, the following little exchange happens:




In the lines, the > is sent from the M1G to the M1XEP, and < is M1XEP to M1G. Right after that sequence, the M1XEP starts sending the normal ASCII commands required to suck all of the configuration information out of the M1G. That part all looks reasonable, but it takes 10 seconds to happen, and when it happens again the next minute, things really aren't good.

It's the exact same sequence every 60 seconds. If I time it and unplug the serial cable just before the M1G sends this request, then plug it back in, I get normal behavior for 1-2 days, but then at some point, things go back to this obnoxious cycle.

As a short-term workaround, I've hacked together an M1XEP emulator that's running on a netbook and plugged it into the M1G. It's keeping CQC and the ISY99i happy in the interim, but it's definitely not what I want to do long term. Since I don't know what these non-ASCII packets are doing, it just ignores them, and the M1G stays happy.

I've observed this particular non-ASCII packet format if I run ElkRP over the connection. I assume it's totally proprietory, but is anyone perhaps familiar with it, and do you know what the M1G is saying exactly, along with what the M1XEP is saying back?

Thanks.

Chris

So this is over the serial connection from the Elk to the IP thingie? If so, what type of serial port is it going through? Is it a hardware serial port onboard, or an outboard one using virtualization software? Maybe they are using control lines in some way that's not working. So maybe have you tried some other serial port hardware?

Dean Roddey said:

So this is over the serial connection from the Elk to the IP thingie? If so, what type of serial port is it going through? Is it a hardware serial port onboard, or an outboard one using virtualization software? Maybe they are using control lines in some way that's not working. So maybe have you tried some other serial port hardware?

Click to expand...

Dean,

My whacky behavior is with my M1G plugged straight into my M1XEP using the same serial cable that came with the M1XEP. It all started when I moved up to M1G 5.2.8 and M1XEP 1.3.28 to support the new ISY99i module.

I built a protocol analyzer using a netbook and two serial ports that I could plug between the M1G and M1XEP to capture data, which is how I have the information I show in my post.

To make things function, I now have one serial port on the netbook plugged straight into the M1G, and wrote a program to multiplex incoming socket requests to the serial port and broadcast back out data to the sockets from the serial port, similar to how the M1XEP normally operates. With that, I have solid functionality again for CQC and the ISY99i, but I'd really just like to have the solid behavior that my M1G and M1XEP used to give me before I upgraded them.

I did hear back from Brad today and engineering is looking at things, so I'm a bit more hopeful of getting somewhere on this.

Chris

Hey Chris,

My M1 is doing the same thing. I had no issues until I upgraded to the new M1EXP firmware 1.3.28. another guy on this board suggested downgrading to 1.3.26 which I did and the clicking and reseting is less fequent now but still an issue. If you hear anything from Elk could you let me know as I would love to fix this problem.

thanks
Shaun

Shaun,

I think your quoting another post that I made about 1.3.26 clearing things up for me.

As far as I can tell, Elk has no other reports of the issue other than mine, and they don't have any explanation for mine, so I would encourage you to contact them as well to let them know I'm not alone. Perhaps they will notice some common thread emerging.

Chris

Well I started a new thread about my problem not being able to stay connected to ElkRP for more then a few minutes before I saw this thread but this *has* to be the same problem. And I'm running the same versions of everything.

Matt

I heard back from Brad at Elk regarding my issue. In ElkRP, I never set an RP access code. This didn't cause a problem in the past, but in this version, became the trigger of all of my grief.

I set an RP access code (which I was told must not be all zeros), upgrading the M1XEP firmware back to 1.3.28, and have been rock solid ever since.

Elk is going to change ElkRP in its next release to point out this requirement, but in the current release, if you update, be sure you also have a code set.

My thanks to Elk for following up with me once they found the answer.

Chris