01
Two-wire and IP describe different layers.
Two-wire here describes the medium of a bus belonging to an equipment family. IP describes network communication. A bus-connected indoor station can also provide a connected function, and an installation may combine segments. Wi-Fi therefore does not mean the entrance station and every indoor station become wireless.
Start with the required service: which entrance calls whom, when, with what picture and conversation? Then draw entrance station → link → call handling → recipient, with a separate branch for the door command. For a SIP proposal, ask which functions both ends actually support. Ringing proves neither two-way audio, video nor the correct access command.
02
Four architectures to qualify, not four promises.
Scroll the table horizontally to compare all three columns.
| Proposal | Identify | Evidence to request |
|---|---|---|
| Reuse of a two-wire bus | Family, generation, supply, topology and cable condition. | Existing-system assessment and explicitly supported references. |
| Ethernet/IP intercom | Network, power, call handling and recipients. | Audio, video and command functions verified between proposed models. |
| Bus/IP gateway | Connected segments, versions and exact interface limits. | Manufacturer matrix; a gateway does not make every legacy station compatible. |
| Forwarding to an app | Required account, endpoint, local network, Internet and remote service. | Separate local and remote scenarios with documented limits and dependencies. |
03
Organise the useful survey into four groups.
Entrances and recipients
Give each entrance and station an identifier. Record the homes or departments served, hours, desired simultaneous or sequential calling, busy/no-answer cases and fallback recipient. Separate requested behaviour from confirmed functions: a station list is not a call plan.
Existing equipment and routes
Collect readable references and available plans. Have cable types, routes, branches, known lengths and spare capacity recorded; keep unknowns visible. Two conductors at a wall do not establish reusability. Environmental photos and backlight constraints help, without opening enclosures or touching conductors.
Power and dependencies
Identify the bus, station, any PoE switch, router and call server separately. Who supplies each device and administers each service? Ask which functions remain after Internet, local-network or mains loss. A battery on one component does not demonstrate continuity of the entire chain.
Door and access management
Map every command to a precise entrance and assign ownership of the lock, interface and permissions. Authorisation, a sent command and door state are three different pieces of information. Agree any data retention and access rules with the site owner, without enabling recording by default.
04
It rings. Is the job really complete?
ILLUSTRATIVE EXAMPLE
Fictional review: entrances E-01 and E-02 serve a reception desk and an office. A demonstration report contains three observations. This is neither a client test nor an instruction to open a door.
Call received, conversation incomplete
E-01 rings at reception, but speech travels in one direction only. Routing to this recipient is observed; the required conversation fails. Keep these results separate. A station’s “registered” status or a displayed picture does not make audio successful.
Command received, wrong entrance
The report then maps the E-01 command to a physical response at E-02. The mapping is wrong: opening any door does not validate the requested entrance. The item remains unaccepted until authorised correction and documented mapping verification. Broader permissions are not a workaround.
Local and remote remain separate items
After correction, a separate report validates the intended local call, but the app recipient has not been checked. Record “remote forwarding unverified”, with an owner and follow-up action. This local result proves nothing about all entrances, all phones or operation without Internet.
Identifiers and results are invented. Real tests require authorised scope and coordination with occupants; this guide configures no protocol, firewall or lock.
05
Request named results, not “everything works”.
One row per call path
Entrance, recipient, schedule, tested situation, expected result, observed result and unresolved issue. Include intended secondary destinations; reception answering does not establish them.
Evidence for each function
Separate ringing, two-way conversation, expected image, authorised command and state feedback where present. A sales demonstration video does not replace the project’s product/version mapping.
A usable handover
Keep the call plan, references, dependencies and owned issue list. Arrange secure administration handover and authorised removal of temporary access. Passwords belong in neither the quotation nor a public document.
06
Turn the survey into a comparable proposal.
In your Inovexia enquiry, group the equipment list by role: entrance stations, answering stations, supplies, network, interfaces and identified accessories. Separate retained, proposed and unqualified items. Request documentation for the exact combination; the legacy bus/IP interface cited below has generation restrictions and is marked obsolete. It illustrates a limitation, not a purchase recommendation.
Add open questions, the survey owner and acceptance criteria. Commercial terms, availability and services remain subject to the project response. Inovexia acts as distributor; this guide is neither a site design nor automatic installation approval.
07
Questions before selecting a system
Can any existing two-wire cable be retained?
No. Its type, condition, route and proposed system requirements must be assessed. Conductor count alone proves neither compatibility nor reach; reuse remains pending without the survey.
Does Wi-Fi replace the intercom bus?
Not necessarily. It may support a connected feature on a station that remains bus-wired. Request the exact functional diagram and identify the remaining wired links.
Does a SIP logo guarantee video and unlocking?
No. Check functions and supported parameters at both ends and any intermediaries. Establishing a call is not proof of every requested function.
Does an unlock command confirm an open door?
No. Available feedback depends on the specified equipment and sensors. Distinguish the command, any acknowledgement and observed physical state; an icon cannot create a missing measurement.
Is Internet required for every call?
It depends on the architecture. Describe local calls, app forwarding and remote services separately. Have each path’s dependencies confirmed without promising offline operation for an entire range.
Technical sources
External reading references. These documents explain principles; they do not certify catalogue products or their combination.
- Professional video door-entry kits — Design and installationBTicino · Sources consulted on
- 346891 — Legacy IP/2-wire interface and compatibility restrictions (obsolete)BTicino · Sources consulted on
- Classe 100 — Connected and wired internal-unit functionsBTicino · Sources consulted on
- SIP — An introductionAxis Communications · Sources consulted on