AS 1735.19 Lift Emergency Phone Requirements: Compliance Checklist
The Robustel EV8100 Industrial VoIP Gateway is designed to support deployments aligned with AS 1735 requirements by providing FXS, cellular and SIP/VoIP voice paths plus observable gateway status, but no gateway makes a lift compliant by itself. Compliance depends on the complete emergency communication system, installation, monitoring arrangement, maintenance evidence and the requirements applicable to the building and jurisdiction.
This guide is an engineering checklist, not legal advice and not a substitute for the current paid standard. Use it to organise a design review with the building owner, lift service provider, monitoring provider and competent compliance professionals.
Establish Scope and the Current Reference Set
Confirm which lift, building classification, jurisdiction, approval stage and contract are in scope. Record the edition of each standard or code used by the responsible designer. Avoid treating an online summary or an old maintenance form as the governing text.
AS 1735.19:2019 concerns remote alarm systems for passenger and goods-passenger lifts. The project’s responsible parties should consult the full standard and any referenced requirements. The Australian Government lift phone migration guidance is useful operational context for moving away from legacy services, but it is not a replacement for the standard.
SafeWork NSW states that lifts require emergency communication and highlights inspection and maintenance records. Requirements and enforcement pathways can vary, so apply the SafeWork NSW lift guidance only within the correct jurisdictional context.
Build an Evidence Register, Not a Feature Checklist
A compliance review becomes easier when every requirement has an owner and a record. Separate design evidence from commissioning evidence and ongoing maintenance evidence.
| Evidence item | Design record | Commissioning record | Ongoing owner |
|---|---|---|---|
| Alarm device and FXS interface | compatible equipment and wiring | call initiated from each lift car | lift service provider |
| Call destination and identity | approved monitoring arrangement | operator identifies site/car correctly | monitoring provider |
| Two-way communication | audio path and acoustic design | intelligibility witnessed in real conditions | lift service provider |
| Primary/alternative network path | carrier or SIP design and dependencies | failure and recovery behaviour | communications owner |
| Emergency power | load and autonomy design | power-loss call at required interval | building/lift maintenance |
| Routine tests and records | test schedule and escalation | baseline results | named service organisation |
This format also reveals gaps. A datasheet may support the first column, but only site testing can complete the second.
Trace the Alarm From the Lift Car to a Person
Start with the passenger action. Confirm what initiates the alarm, what indications the passenger receives and how two-way speech is established. Then trace the FXS or other local connection, gateway, mobile or SIP transport and monitoring-centre workflow.
The operator needs the information and procedure required to respond to the correct site and lift. Test this with production records, not a temporary technician destination. If there are several cars, verify that identification remains unambiguous.
Robustel’s PSTN elevator emergency-phone replacement Application Example explains how an analogue lift phone can be carried over 4G/VoLTE or SIP/VoIP. Use the pattern to identify components and dependencies; do not interpret the page as certification of a particular installation.
Prove Behaviour When a Dependency Is Removed
Emergency communication design should state what happens when normal power fails, the preferred SIM or mobile service is unavailable, a SIP registration is lost, or a local Ethernet link is disconnected. Not every architecture will maintain the same service through every failure, but the behaviour should be known, alarmed where required and consistent with the approved design.
Robustel EV8100 Industrial VoIP Gateway has dual SIM support and a holder for two compatible 18650 flat-top lithium batteries. Batteries are not included by default. The battery provision still requires cell selection, installation, environmental checks, service intervals and an autonomy test with the complete call-path load.
Where a building network carries SIP, include its switches, routers, internet service and power protection in the failure analysis. A gateway battery cannot keep an unprotected upstream switch operating.
Verify Coverage and Antenna Placement at the Final Position
Do not approve cellular service from a handset test in the lobby. Measure at the final antenna position with the lift plant and cabinet in normal condition. Steel, concrete and electrical equipment can make the machine room materially different from the surrounding floor.
Record the operator, SIM, antenna type, cable route and result. Place real calls and observe recovery after service interruption. If dual SIM is part of the design, test the intended transition rather than assuming that the presence of two cards demonstrates continuity.
This record should remain with the installation. Future maintenance must not move or replace the antenna with an unqualified part simply because the original design is no longer visible.
How the Robustel EV8100 Industrial VoIP Gateway Supports an AS 1735-Aligned Communications Design
Robustel EV8100 Industrial VoIP Gateway provides one FXS interface, supports VoIP and VoLTE, and documents SIP over UDP, SIPs, SRTP and several DTMF methods. It also offers dual SIM, two Ethernet ports and gateway management through RCMS. Those features can support a testable emergency communications architecture.
The product page lists EV8100-A-4L-A34AU and EV8100-B-4L-A34AU for ANZ with RCM. RCM is relevant product evidence; it is not a declaration that the entire lift installation satisfies AS 1735.19 or every state obligation.
Gateway LEDs and RCMS visibility can help maintenance teams investigate device, line and cellular status. Remote status is supplementary evidence. Periodic end-to-end calls remain necessary because a registered gateway does not prove that a passenger and monitoring operator can communicate.
The Robustel’s EV8100 Quick Pitch video is suitable for an initial technical briefing. Compliance review should rely on the current product documentation, exact order code, system design and witnessed site records.
Witness the Commissioning Sequence
Agree the witness list before the test. It may include the lift contractor, monitoring provider, building representative and communications integrator. Name who signs each result and who owns corrective work.
- Confirm the installed gateway, SIMs, antenna, power and configuration against the design record.
- Initiate an alarm from each applicable lift car and verify passenger indications, two-way speech, destination and correct site/car identity.
- Test any required DTMF or monitoring-centre interaction.
- Remove normal power, wait for the approved period and repeat the call.
- Exercise the designed network or SIM failure and confirm the expected response, alarms and recovery.
- Confirm remote status and maintenance records without treating them as a substitute for the call.
- Restore the service and check that no temporary destination, credential or bypass remains.
Robustel’s TSARO EV8100 case study shows why continuous testing and fleet evidence matter in a large North American estate. It does not establish Australian compliance; its useful lesson is operational—the call path needs evidence after installation, not only on installation day.
Maintain the Evidence After Handover
The handover pack should identify the building and lift, exact gateway model, firmware/configuration baseline, SIM and service owner, antenna, emergency power arrangement, monitoring destination and acceptance results. Store it where both field and service-desk teams can retrieve it.
Create a routine test schedule and an exception process. If a test is missed or fails, define who is notified, how the lift is assessed and when restoration is confirmed. Keep battery inspection and replacement records with the communications-system history.
Control configuration changes. A new SIM, destination, SIP credential, antenna or software version can alter the approved path and should trigger proportionate revalidation.
Foire aux questions
Q1. What is AS 1735.19?
It is an Australian Standard addressing remote alarm systems for passenger and goods-passenger lifts. Project teams should consult the current full standard and competent professionals rather than relying on an article summary.
Q2. Are lift emergency phones mandatory in Australia?
Emergency communication requirements arise through applicable building, lift and workplace-safety frameworks. The exact obligation depends on the lift and jurisdiction, so the building owner and responsible lift professionals should verify the current requirements.
Q3. Can a mobile phone replace a lift emergency phone?
A consumer mobile phone should not be assumed to meet lift emergency communication requirements. The system needs an approved passenger interface, reliable call routing, identification, power arrangements, monitoring-centre handling and maintained evidence.
Q4. How often should a lift emergency phone be tested?
Use the frequency required by the applicable standard, jurisdiction, maintenance regime and monitoring agreement. The schedule should include an escalation path for missed or failed tests and retain inspectable records.
Q5. Does the Robustel EV8100 Industrial VoIP Gateway make a lift AS 1735.19 compliant?
No device makes the whole lift compliant by itself. EV8100 is designed to support deployments aligned with AS 1735 requirements, but the complete voice path, power, monitoring, installation and maintenance process require professional assessment and testing.
Conclusion
The Robustel EV8100 Industrial VoIP Gateway can support an AS 1735-aligned lift emergency communications design by providing a documented FXS interface, cellular and SIP/VoIP options, ANZ models and managed gateway visibility. Those capabilities are useful building blocks, but the compliance case belongs to the complete installed and maintained system.
The strongest project evidence is not a broad product statement. It is a traceable register connecting the applicable requirements to design records, witnessed calls, power and network failure tests, monitoring-centre acceptance and ongoing maintenance ownership. Product evidence, deployment evidence and professional compliance judgement should remain clearly labelled.
Before replacing a legacy service, have competent parties confirm the current obligations, run the full commissioning sequence at the lift and establish the routine test process. That approach gives a building owner defensible operational evidence without claiming that a gateway alone can carry the legal or safety responsibility.
Explore More Articles About Robustel Lift Connectivity
À propos de l'auteur
Robert Liao | Technical Support Engineer
Robert is an IoT Technical Support Engineer at Robustel, specializing in industrial networking and edge connectivity. A certified Networking Engineer, Robert focuses on the deployment and troubleshooting of large-scale IIoT infrastructures. His work centers on architecting reliable, scalable system performance for complex industrial applications, bridging the gap between field hardware and cloud-side data management.