Are there any known issues with the M1XEP and multiple sessions?

electron

Administrator
Staff member
So for many months, I have been running Girder with the Elk M1 plugin, and a Linux based Linksys router, with an Elk M1 driver, without any issues. However, in the last few weeks, I have been running into the issue where the tcp connection to the M1XEP goes 'stale'. Nothing happens when I send commands through either driver, and whenever I try to trigger a task/light using X10-RF (W800RF32 connected to an M1XSP, which should work, since it doesn't rely on software), tasks etc trigger, but it isn't being reported to any of the devices connected to the M1XEP.

Once I restart the Girder software, everything seems to be fine again, however, I have been able to fix it by restarting the Linksys router as well. The most frustrating part is that the M1XEP heartbeat was still being broadcast. Has this ever been an issue?
 
Perhaps the clue is the heartbeat because it continues to be received. Wild theory alert! I wonder if its transmission mechanism is different from other M1 commands. The difference may explain why the bulk of the M1 commands are not received.
 
You will see the behavior you are describing if you connect Elk-RP to the system. While connected with Elk-RP any messages you send the system will be ignored. The XEP does not drop the connections, but does send a message (see the RP command) to tell you this is happening.

I do know that the heartbeat command is originating in the M1 system and send out of the serial port to the XEP which simply forwards it over the network. This is the same process used for all messages originating from the M1 system.

Have you changed anything or reconfigured anything in the past few weeks? Given your description I would focus on the Linksys first. Are you using a static IP on the XEP or DHCP? If just restarting your Linksys seems to resolve the issue, that implies you may have a routing issue. DHCP lease durations come to mind.

Internal Linksys issues also comes to mind. I have had to help several eKeypad users with routing issues that we finally tracked down to their Linksys router displaying one configuration, but not operating that way. Deleting the configuration and re-creating it in the router/firewall resolved the problems.

I have not experienced the behavior you are describing in all of my testing with the ELK.
 
I don't have ElkRP running (it's installed on a virtual machine, which isn't even turned on). I also don't see the Elk M1 go into installer mode, plus it wouldn't explain why restarting the M1XEP tcp session fixes the issue.

The heartbeat is an M1XEP feature as far as I know, it doesn't show up when you do not have the M1XEP add-on.

As for the Linksys, it isn't running any Linksys software, it's just a network appliance (it doesn't even do any routing), with a hardcoded IP address, and I am running OpenWRT (White Russian) on it. I only mentioned the Linksys to show it's not just a Girder problem. Nothing has been changed in the last few months.
 
The heartbeat is an XEP feature, but does originate from the M1. The M1 only sends the message if you have an XEP setup in the system.

Did I understand correctly...The Linksys is not interacting with the XEP (even as a router or DHCP server) but restarting it resolves Girders XEP communication issues.
 
When the condition arises, are both Girder and the Linksys seeing the hearbeat but no other commands?

I'm wondering what kind of conditions are needed to induce this situation. If the M1 (or XEP) restarts, it will drop all of its network connections. Theoretically, Girder and the Linksys will no longer receive M1 commands unless they actively re-establish the connection. They should be deaf to all transmissions from the M1. Yet, there's the heartbeat that continues to be received. Hmm.
 
I need to do some more testing, I used a 3rd telnet session to monitor the M1 behavior, but can't confirm for sure that the other drivers are seeing anything at all. netstat does show the driver is still connected.
 
FWIW, I just wrote a script to open a few connections to the M1XEP and bombard it(1 request/connection/sec) with requests. It took about 10 minutes to kill the XEP(needed to be rebooted to form new connections) with 5 connections. Don't know if this is unique to my setup, but maybe ELK should run a quick robustness test of the interface to flush out any problems..
 
FWIW, I just wrote a script to open a few connections to the M1XEP and bombard it(1 request/connection/sec) with requests. It took about 10 minutes to kill the XEP(needed to be rebooted to form new connections) with 5 connections. Don't know if this is unique to my setup, but maybe ELK should run a quick robustness test of the interface to flush out any problems..

Not to hijack the thread, but this brings to mind the age-old question for some of us about when the XEP is going to be replaced by something a bit more robust and customizable. I'm still amazed that we're forced to use port 80, etc. IMO, this is the Achilles heel of an otherwise fantastic, "tank-tough, sun-up-in-the-morning reliable", system. I've come to find that if something isn't working correctly, suspect the XEP...
 
Back
Top