toymaster458
Active Member
What does one do if they need the main serial port for multiple uses? For example they want Cinemar intergration along with the M1XEP?
Main Serial Interface
- Thread starter toymaster458
- Start date
WayneW
Senior Member
If the Cinemar software cannot connect via TCP/IP sockets, then you can create a virtual serial port using this free software. Basically it translates from an application that demands a com port and communicates to an app that accepts TCP/IP. I use it with HomeSeer and Electron's my.elk script to talk to the M1 via the XEP, since the script is technically not able to do TCP/IP or socket connections.
http://www.hw-group.com/products/hw_vsp/index_en.html
Run this on the Cinemar computer, assign a non-existent com port number and configure Cinemar to use that com also. Enter the IP address of your XEP and set the port to 2101. I don't know what the "server port 23" setting means, but if it gets blanked out you get stupid errors.
http://www.hw-group.com/products/hw_vsp/index_en.html
Run this on the Cinemar computer, assign a non-existent com port number and configure Cinemar to use that com also. Enter the IP address of your XEP and set the port to 2101. I don't know what the "server port 23" setting means, but if it gets blanked out you get stupid errors.
toymaster458
Active Member
Correct me if I am wrong but when the Cinemar connects this way over TCP it would be the same as when the ELKRP connects via TCP which locks the M1XEP from browser access and email sending. And even if it didn't, this would only be a solution for software based options. What about hardware based options like having an M1XEP and a AMX, Crestron, HomeLogic or Vantage.
From what I understand the reason why these devices need to be connected to the main serial port is because the main serial port is the only port that transmits live information. It would be a great feature enhancement for any of the add on serial ports to be able to act like the main serial port.
From what I understand the reason why these devices need to be connected to the main serial port is because the main serial port is the only port that transmits live information. It would be a great feature enhancement for any of the add on serial ports to be able to act like the main serial port.
Spanky
Senior Member
Only ElkRP locks the main serial port on the M1XEP when it is reprogramming the system. Other devices can not lock out the serial port on the M1XEP.
On the expansion serial ports there are some data like light information and thermostat information that is automatically updated. All the data is available by way of polling the M1 on the expansion serial ports. There is too much data flowing out Port 0 that would tend to clog up the keypad serial bus where the expansion serial ports are connected.
On the expansion serial ports there are some data like light information and thermostat information that is automatically updated. All the data is available by way of polling the M1 on the expansion serial ports. There is too much data flowing out Port 0 that would tend to clog up the keypad serial bus where the expansion serial ports are connected.
Steve
Senior Member
I'm sure DavidL will jump in here but Mainlobby will talk fine via the Elk Plugin for MLServer. It will talk via TCP/IP (XEP). Make sure as Wayne said it is configured for non secure port 2101. I think David is setup using this and I had it working for my eval. There is a signal when RP is connected and CQC and I believe ML use it to 'go on hold' when RP is connected and then back on line when RP disconnects, so yes, you will not be on line with ML when RP is active. I do not find this to be an issue.
Edit: Also, Electron wrote a nifty little RP disconnect utility to disconnect RP just in case something gets hung and the driver does not reconnect (didn't see RP disconnect).
Edit: Also, Electron wrote a nifty little RP disconnect utility to disconnect RP just in case something gets hung and the driver does not reconnect (didn't see RP disconnect).
Hi All,
Yes, the Cinemar MLServer ELK plugin can connect to the ELK M1 either via a dedicated Com port, or via a TCPIP ethernet connection. It is the most full functioned plugin that I am aware of with regards to interfacing with the M1 panel. Once connected to the M1, MLServer distributes M1 states and control to other MLServer plugins, and to the MainLobby client user interface application. There can be multiple MainLobby clients on the network.
Oh, almost forgot. The Elk Plugin can also talk to an ELK panel via a GlobalCache ethernet connected serial port.
And, I haven't tested it yet, but no reason that if you have run out of motherboard com ports that a USB to serial Edgeport adapter couldn't be used. Many of these USB to serial adapters won't work, but the Edgeport seems to be very reliable for most serial devices.
For my setup, I am using a Com port as the Panel is within a few feet of my Automation Server running MLServer. For the Orlando EHX show, we will be using the Elk Ethernet adapter for no other reason than making wiring easier
Be sure to stop by the Cinemar booth at EHX and see it all working!
Yes, the Cinemar MLServer ELK plugin can connect to the ELK M1 either via a dedicated Com port, or via a TCPIP ethernet connection. It is the most full functioned plugin that I am aware of with regards to interfacing with the M1 panel. Once connected to the M1, MLServer distributes M1 states and control to other MLServer plugins, and to the MainLobby client user interface application. There can be multiple MainLobby clients on the network.
Oh, almost forgot. The Elk Plugin can also talk to an ELK panel via a GlobalCache ethernet connected serial port.
And, I haven't tested it yet, but no reason that if you have run out of motherboard com ports that a USB to serial Edgeport adapter couldn't be used. Many of these USB to serial adapters won't work, but the Edgeport seems to be very reliable for most serial devices.
For my setup, I am using a Com port as the Panel is within a few feet of my Automation Server running MLServer. For the Orlando EHX show, we will be using the Elk Ethernet adapter for no other reason than making wiring easier
Be sure to stop by the Cinemar booth at EHX and see it all working!
Hi Spanky,
The GlobalCache has an ethernet port and converts to both Serial (1 on the smallest GC up to 2 on the larger models. Larger models support Xpansion modules int he near future for more) and IR ports.
http://www.cinemaronline.com/globalcache.html
What the GC is great for is distributed hardware environments. See diagram on bottom of the above page for info.
works great!
The GlobalCache has an ethernet port and converts to both Serial (1 on the smallest GC up to 2 on the larger models. Larger models support Xpansion modules int he near future for more) and IR ports.
http://www.cinemaronline.com/globalcache.html
What the GC is great for is distributed hardware environments. See diagram on bottom of the above page for info.
works great!
Dean Roddey
Senior Member
Be a little careful of the GC serial ports. They are limited to N81, and a specific range of baud rates. There are a fair number of devices that are outside of that range. So be sure that the devices you want to control use N81 serial port settings and a baud rate within the GC's capabilities (I think they max out at 56K, which would mean you can't run the M1 at its maximum rate of 112K, though maybe some recent improvements in the GC have raised that limit.)
There are other serial port over IP solutions out there that both don't have those limitations, and which don't require the program to specifically unerstand it is talking through a GC, because they provide virtual serial port drivers that make the ports look like local serial ports. The GC does (or didn't last time I checked) provide such a virtual com port driver, so the program has to either provide its own abstractions of serial ports or has to specifically understand it is talking to a GC.
CQC and RP can connect to the M1 at the same time over ethernet. The M1 sends a 'shut up' message when RP connects, and the CQC driver backs off. The M1 sends a 'start talking again' when RP exits and the driver will recycle it's connection and reconnect to the M1 afresh (in case the changes just done might have changed something important.)
CQC's .Net interface viewer should run fine on the Elk .Net wall panel as long as it is a .Net 5.0 compatible platform, and I'd assume it would be if it's just now coming out. Some existing devices out there are still 4.2 level, but I'd assume anything coming out at this point would have long since planned on being 5.0 based, right?
There are other serial port over IP solutions out there that both don't have those limitations, and which don't require the program to specifically unerstand it is talking through a GC, because they provide virtual serial port drivers that make the ports look like local serial ports. The GC does (or didn't last time I checked) provide such a virtual com port driver, so the program has to either provide its own abstractions of serial ports or has to specifically understand it is talking to a GC.
CQC and RP can connect to the M1 at the same time over ethernet. The M1 sends a 'shut up' message when RP connects, and the CQC driver backs off. The M1 sends a 'start talking again' when RP exits and the driver will recycle it's connection and reconnect to the M1 afresh (in case the changes just done might have changed something important.)
CQC's .Net interface viewer should run fine on the Elk .Net wall panel as long as it is a .Net 5.0 compatible platform, and I'd assume it would be if it's just now coming out. Some existing devices out there are still 4.2 level, but I'd assume anything coming out at this point would have long since planned on being 5.0 based, right?
I may not have interpreted the discussion above correctly, so forgive me, I'm still learning about all of this.
Is it possible to both connect to the Elk via serial and via Ethernet at the same time? I would like to interface my WACI NX (serial) to the elk to give it a low level connection (I still don't trust PCs as a robust solution for real-time events) that is separate from the interface with MainLobby. Can I connect the ethernet port or the WACI to the serial bus instead of port 0? If so, is the serial API for the M1 the same?
The solution of writing a serial->TCPIP bridge is a good one, but the WACI is not sophisticated enough to run any scripting server side..
TIA
Is it possible to both connect to the Elk via serial and via Ethernet at the same time? I would like to interface my WACI NX (serial) to the elk to give it a low level connection (I still don't trust PCs as a robust solution for real-time events) that is separate from the interface with MainLobby. Can I connect the ethernet port or the WACI to the serial bus instead of port 0? If so, is the serial API for the M1 the same?
The solution of writing a serial->TCPIP bridge is a good one, but the WACI is not sophisticated enough to run any scripting server side..
TIA
WayneW
Senior Member
Short answer: nojlegault said:
long answer: maybe. The M1XEP requires serial port 0. That leaves XSP serial ports available for other things. BUT, serial ports > 0 do NOT get all the same information broadcast to them. So if an XSP serial port gives you everything you need, then yes.
I should have posted... I've been using both HomeSeer and MainLobby and ElkRP and Elk Java and Elk Remote all interchangeably for a couple of months now. They are all over IP/Ethernet. It is all completely seamless.
jlegault, I'm curious: what are you looking to do between the two devices (WACI & M1)?
jlegault, I'm curious: what are you looking to do between the two devices (WACI & M1)?
