Quick answer: At ISE 2026 in Barcelona (3–6 February 2026), Iris Information Technology showed its Linux-based digital intercom line, a two-wire retrofit path and IP access control integration on a single booth. The five questions integrators asked most often were about SIP interoperability, PoE budgets, migration from analogue, GDPR-compliant video storage, and firmware lifetime. This article answers each one in the order they were raised, with the standards and figures that came up on the stand.
What we actually brought to Barcelona
ISE is the largest systems-integration show in Europe, and by 4 February 2026 it had passed 76,000 unique attendees, closing on 92,170 visitors and 1,751 exhibitors across 101,000 sqm — the largest show floor in its history.[1] For a Shenzhen manufacturer building intercom systems since 2016, the value of the show is not footfall. It is the twenty minutes per stand visit in which a distributor tells you exactly what stops them specifying your product.
We showed three things on a single 18 sqm booth:
- Product line 01 — Linux digital intercom system. The 10.1-inch LAN management centre unit, the 7-inch digital colour video substation and the 10.3-inch digital colour video substation, running on an embedded Linux image rather than a proprietary RTOS.
- Product line 02 — two-wire intercom. Demonstrated as a retrofit path: existing two-core cabling reused, no re-cabling of risers.
- Product line 04 — access control. Door controllers and readers sharing one credential database with the intercom layer.
The decision to lead with the Linux platform was deliberate. Most of the conversations we had in 2025 in Frankfurt and Dubai ended at the same place: "can we integrate it with what the building already has?" A closed firmware stack makes that question unanswerable.
Question 1: "Does it speak SIP, or only your own protocol?"
This was the single most frequent question of the four days, asked by roughly one in three visitors. It matters because most European integrators do not want a standalone intercom island — they want door calls to land on a device their client already manages.
Our answer: the Linux line exposes SIP for call signalling, so a door call can be routed to a SIP PBX, a softphone or a third-party indoor unit. What it does not do out of the box is the full range of vendor-specific extensions that a proprietary stack would carry.
The practical limit is worth stating plainly. RFC 3261 defines the SIP signalling that makes intercom-to-PBX routing possible, but it does not standardise door release, video codec negotiation with hardware acceleration, or multi-apartment addressing.[2] Those remain integration work. Budget engineering time for it, or buy the components from a single vendor and accept the lock-in.
What integrators should test before committing
Three tests, all doable on a bench in an afternoon:
- Place a door call and confirm it rings on the target PBX extension and that cancelling on the PBX releases the door-station channel. Half-day failures usually appear here.
- Check codec negotiation under load. A system that negotiates H.264 cleanly with two concurrent calls may degrade at eight.
- Confirm clock sync. If the intercom and the PBX drift, call logs become useless for post-incident review.
Question 2: "What is the real PoE budget per door station?"
The second-most-asked question, and the one where published datasheets are least helpful. A door station is not a fixed-load device. The figure that matters is peak, not idle:
- Idle, camera active, backlight off: roughly 3–4 W
- Active call with video and IR illumination on: roughly 10–13 W peak
- Door-release strike energised (if powered from the same run): add the strike's coil rating, typically 6–12 W
IEEE 802.3af supplies 15.4 W at the source and guarantees about 12.95 W at the powered device after cable loss over 100 m.[3] That is why a door station that benches fine on a 1 m patch lead can brown out on a 90 m riser exactly when the IR LEDs fire at night. Plan for 802.3at (Type 2, 30 W at source) on any run longer than about 60 m, or power the strike from a separate local supply.
At -10 °C, which was the outdoor temperature in Barcelona during the show week,[4] the IR array stays on longer per call. Add 15–20% headroom to your switch budget for cold-climate projects.
Question 3: "Can we reuse the existing two-wire cabling?"
Asked mostly by contractors working on refurbishment, and the answer is a qualified yes — which is why we brought the two-wire line to the show at all.
The attraction is obvious. Re-cabling the risers of an occupied 60-unit apartment building means chasing walls in every corridor and hallway, and in a heritage or occupied building that cost dominates the whole project. The value of a two-wire retrofit is that the cable already exists.
The constraints are equally real:
- Cable condition. Two-core cable installed in the 1990s may have water ingress or intermittent joints. Insulation-resistance test the existing runs before quoting.
- Topology mismatch. Legacy analogue systems are commonly bus or star topologies. Confirm which, because a two-wire IP retrofit assumes one or the other.
- Distance limits. Every two-wire architecture has a maximum run and a maximum number of stations per segment. Verify at the design stage, not at commissioning.
- Power over the same pair. In retrofit, the existing pair usually has to carry both signal and power. That caps the total load per segment.
If you are weighing the three architectures — two-wire, IP and analogue — the trade-offs are set out in more detail in our comparison of two-wire, IP and analogue intercom technology.
Question 4: "How do we handle video recording and GDPR?"
Asked by almost every EU-based integrator, and it is a genuine commercial risk, not a theoretical one. Intercom cameras capture identifiable images of visitors in semi-public space, which brings them squarely within EU data-protection rules.
Under Article 5(1)(e) of the GDPR, personal data must be kept no longer than necessary for the purpose it was collected.[5] For a residential door-entry camera, the European Data Protection Board's guidance on video devices treats continuous recording as a high-risk activity requiring a documented legal basis and clear signage.[6] In practice this means:
- Default to no local recording in residential installs. Record on event, not continuously, unless the client has a documented justification.
- Retention windows in the product, not in a policy document. A configurable 24–72 hour ring buffer is defensible; an unbounded archive is not.
- Signage at the entrance, naming the controller and the retention period.
- Data minimisation on transfer. Keep video on the local LAN where possible and avoid routing it through a third-party cloud the client has not assessed.
Our position on the stand was that the recorder should be the integrator's choice, not a forced cloud subscription — the API is documented so the client's own NVR can pull the stream.
Question 5: "How long will you support the firmware?"
The question that decides whether a distributor signs. Nobody wants to install a system in 2026 that stops receiving security patches in 2029.
We committed to a minimum five-year security-patch window from the date of last manufacture for the Linux line, with a published end-of-support date per model. Under the EU Cyber Resilience Act, which entered into force in December 2024, manufacturers placing products with digital elements on the EU market carry obligations covering security updates and a declared support period.[7] The Act's main obligations apply from December 2027,[8] so equipment specified now will be sold into the regulated window. A vendor that cannot state a support period in writing is a liability in a tender.
Why a Linux platform made this answer possible
A proprietary RTOS ties patches to the vendor's own development queue. A Linux base lets us inherit upstream kernel and OpenSSL security fixes, ship them to a field-updatable image, and keep the application layer stable while the platform underneath is maintained. That is the main reason we moved the flagship line — the trade-offs are covered in our note on why we moved to a Linux platform.
What integrators asked that we could not answer
Worth recording, because it shapes our roadmap:
- Matter and Thread support. Asked repeatedly. Not in the current line. Gateways are the honest answer today.
- ONVIF Profile S conformance for the door-station camera stream. Requested by several integrators who want to record on an existing NVR without a protocol adapter. On the roadmap, not shipped.
- Certification evidence for individual EU member states. We hold national security certification in China (see our certification announcement); country-by-country EU approvals are handled per project.
Frequently asked questions
Is the Linux intercom line shipping, or was ISE a preview?
Shipping. The 10.1-inch LAN management centre unit, the 7-inch and 10.3-inch digital colour video substations are in production and orderable through the Linux digital intercom system collection. The ISE booth demonstrated the shipping firmware.
Can the same system serve two-wire and IP in one building?
Yes, across a mixed riser: two-wire segments on floors where cabling cannot be replaced, IP on floors being rewired, with the management layer presenting one address book. It is more integration work and needs an accurate as-built of the riser before quoting.
What is the maximum number of units per system?
It depends on the architecture and on the number of concurrent video calls rather than on a hard device count. For a specific project, send us the unit count, riser topology and cable type and we will size it. Our guide to how a building video intercom system works explains the topology decisions that set the ceiling.
Do you support integration with an existing access control system?
Yes for our own controllers via a shared credential database. Third-party access control integration depends on the panel's own API — see our access control and video intercom integration guide for the wiring and design considerations.
The 2026 roadmap, in one paragraph
Priority one is completing ONVIF conformance for the door-station stream. Priority two is deepening SIP interoperability, including tested profiles for the PBX platforms our distributors actually deploy. Priority three is the EU approval programme per member state. Matter and Thread remain exploratory. If any of these matters to your 2026 tender, the useful thing to do is tell us the specific requirement — our contact page reaches the engineering team directly, and a project-specific answer beats a roadmap slide.
For distributors who visited the booth, the follow-up materials — datasheets, firmware support statement and the SIP integration note — are available on request with your project details.
References
- Integrated Systems Europe, "ISE 2026 Pushes Beyond with a Record-Breaking Show of Innovation, Creativity and Industry Momentum", press release, February 2026. Figures: 92,170 visitors; 1,751 exhibitors; 101,000 sqm.
- IETF, RFC 3261 — SIP: Session Initiation Protocol, June 2002. Defines SIP signalling; door release and multi-apartment addressing are outside its scope.
- IEEE, IEEE 802.3 Ethernet Working Group — IEEE 802.3af (PoE Type 1) delivers 15.4 W at source, minimum 12.95 W available at the powered device.
- Meteo Catalunya, Servei Meteorològic de Catalunya — surface temperature observations, Barcelona, week of 3 February 2026.
- EUR-Lex, Regulation (EU) 2016/679 (General Data Protection Regulation), Article 5(1)(e) — storage limitation principle.
- European Data Protection Board, Guidelines 3/2019 on processing of personal data through video devices, adopted 29 January 2020.
- EUR-Lex, Regulation (EU) 2024/2847 (Cyber Resilience Act), in force 10 December 2024 — security-update and support-period obligations for products with digital elements.
- European Commission, "Cyber Resilience Act", DG CONNECT policy page — main obligations apply from 11 December 2027; reporting obligations from 11 September 2026.