Mitsubishi Lift support with E-LIP


A new method of integrating with Mitsubishi lifts has been developed in the GuardPointPro Software.

The integration complies with the Mitsubishi integration document “specification of communication between E-LIP and access control system” 2015/08/23

The development allows the GuardPointPro software to send lift floor information over TCP/IP to the E-LIP controller. 



The E-LIP controllers then send the floor commands to the Lift panel (Gates), enabling the authorized lift buttons for few secs.


GuardPointPro v3.2.237 with ACM Module and a PC with network connection to the E-LIP

The latest Version of GuardPointPro can be downloaded from here


Actions/Processes/Global reflexes 

The integration uses the actions/processes and global reflexes part of GuardPointPro to dictate when to send the lift commands. you will need to understand the logic of actions/processes and reflexes before learning how to set up the lift integration.


The Action - Would be the task which is triggered, for example: open all the doors, print a report, arm a group of inputs.

The process - This is a container or folder which can hold a group of actions and also dictates the order in which they are triggered. 

The Global reflex - This defines what event should trigger the process ie an access granted, start of alarm etc 

Actions/processes and reflexes are commonly used within GuardPointPro for tasks such as open all the doors in the event of an alarm, Schedule an import of cardholders, automate a backup, arm a group of inputs from a reader.  


To learn more about actions/processes and reflexes please see:

The "Send Mitsubishi command" to socket action 

A new action type called “Send Mitsubishi Command to socket” has been added in the actions window. This action defines the list of floor number to send and also the IP address of where this list of floors should be sent.


The Fields within this action are

Gate/reader number - (select a number from 1 – 255)

Parameter 1 - Defines the IP address and port number of the E-lip panel (syntax must include the TCP letters for  example "TCP:")

Parameter 2 - Is the header (fixed to 4C 41 00 00) sent with each lift commands.

The Floor selection: up to 255 floors can be selected with the option of choosing the front or rear doors of the lift

Pls refer to the following Mitsubishi documentation for full command explanation:

Specification of Communication between E-LIP and Access Control System. attached to this article 


The Mitsubishi health check

It is important that the Mitsubishi lift receives data from the access control software every 30 mins even if the lift is not being used. If no data is sent from the access control system after 30 mins the E-Lip panel will disconnect from the access control software.  To keep informing the lift that the access control system is still live we can send a small amount of data referred to as a "health check"


The action type should be "Send Message to communication port"

The communication Setting is the IP Address and Port number of the E-lip panel - (syntax must include the letters TCP for example "TCP:") 

The command line field should contain the data "11 00 00 00" which is the Mitsubishi health check data. 

This action should then be associated to the scheduler global reflex to schedule the health check data to be sent at certain times:




The E-lip Emulator software  

For testing the lift commands from the access control system without the need of having a physical lift the Mitsubishi E-LIP emulator software can be used.  

by clicking the start button the emulator software will wait for a connection from the access control system.  

once data has been you can check if the data complies with the correct syntax to what the lift is expecting. 


by clicking the details button you can see exactly what floor numbers are being sent in the command


 The Emulator application is attached to this article:

GuardPointPro optimization 

To prioritize the events received from the reader used for the lifts the controller's polling frequency can be adjusted so that the lift controller networks are polled more frequently than the other readers in the building.



For example increasing the controllers networks "waiting for delay" to 200ms on controller networks which do not contain lift activation readers and keeping the controller network which does have lift reader at 50ms would mean the lift readers would be polled 4 times more frequently than the other readers.





Have more questions? Submit a request


Please sign in to leave a comment.
Powered by Zendesk