Did you know that you can enjoy many members-only features simply by quickly registering (no CAPTCHA!)?
Registering gives you access to our giveaways, forum features, increased search performance, access to our Download Library, create your own blog & gallery, and more!
Once you have registered, stop by in 'Hello World', and introduce yourself.
Elk M1G claiming to be in remote programming mode once a minute
Posted 04 December 2011 - 03:17 PM
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?
Posted 04 December 2011 - 08:50 PM
Posted 07 December 2011 - 01:59 AM
Posted 10 January 2012 - 02:52 AM
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:
00024 > 10 02 7f 01 00 01 10 03 b1 8a 30 36 49 45 30 30 41 > ..........06IE00A 00024 > 43 0d 0a > C.. 00024 < 10 02 7f 00 00 01 00 00 00 00 00 00 10 03 31 51 < ..............1Q 00024 > 10 02 7f 00 00 01 05 02 04 00 00 00 50 f7 00 0d 03 > ............P.... 00024 > 03 02 00 08 04 03 06 02 00 04 00 00 01 00 00 01 00 > ................. 00024 > 00 01 00 00 01 00 00 01 00 00 01 00 00 01 1b 93 48 > ................H 00024 > 03 00 0a > ... 00024 > 10 03 ae f4 > ....
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?
Posted 12 January 2012 - 03:40 AM
Posted 12 January 2012 - 07:03 PM
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?
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.
Posted 27 February 2012 - 05:58 PM
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.
Posted 27 February 2012 - 07:01 PM
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.
Posted 07 March 2012 - 09:43 PM
Posted 19 March 2012 - 10:01 PM
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.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users