IKEA blinds (E2102/E2103) stop mid-move when upOpen/downClose is delivered twice; use goToLiftPercentage for open/close

Open
  • Is something wrong?
#33,685 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
68/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
typescript
Domain
backend, embedded-iot

Research direction

The report names E2102 and E2103 and includes an external converter, but no repository files or tests. Start by locating their device definitions and the window covering state converter; check how stop and inverted lift percentages are handled. Implement the reported change for the tested models, then verify repeated open and close commands continue the movement; E1757 and E1926 are suggested but untested.

Written by the indexing model from the issue text.

Description

What happened?

IKEA cellular blinds (11 x TREDANSEN E2103, 2 x PRAKTLYSING E2102, firmware 24.4.13) occasionally accept an open or close, move about 2 percent, and stop. A second command always works.

The cause is a duplicated command frame. The blind treats a second upOpen/downClose received while it is already moving as a stop. A duplicated goToLiftPercentage is ignored and the move completes.

Details of a stalled move:

  • The blind answers the command with Default Response SUCCESS, starts, sends one position report (about 2 percent travelled), then stays still.
  • Nobody sent a stop. No rejoin, announce or route error.
  • Only seen when many blinds are commanded at once (13 blinds by one automation). Over one month: 8 of 77 such runs had one stalled blind, 0 stalls in single-blind moves.
What did you expect to happen?

The blind completes the move. Since retransmissions inside the mesh are outside Zigbee2MQTT's control, I would expect state: OPEN / CLOSE for these blinds to be sent in a form that survives duplication, which goToLiftPercentage (0 / 100) does.

How to reproduce it (minimal and precise)

Publish the same state twice, about a second apart, while the blind is moving:

zigbee2mqtt/<blind>/set {"state":"OPEN"}
(wait for the first position report, then 1 s)
zigbee2mqtt/<blind>/set {"state":"OPEN"}
Sequence Result
OPEN, then OPEN again 1 s into the move blind stops (3 of 3 tries, including CLOSE/CLOSE and a repeat 6 s into the move)
position 100, then position 100 again blind continues to 100 (2 of 2, also position 0)
Zigbee2MQTT version

2.8.0 (zigbee-herdsman-converters 25.120.0, zigbee-herdsman 9.0.2)

Adapter firmware version

20250321

Adapter

zstack (Sonoff ZBDongle-P)

Setup

Docker on a Raspberry Pi. Mesh of about 80 devices, routers mostly Philips Hue and Inovelli.

Device database.db entry

Not attached. Available on request.

Debug log

None. The evidence is a sniffer capture, summarised below. I can share a filtered pcap privately.

Notes

How the duplicate happens without anyone sending it twice

Sniffer capture of one natural stall (all 13 blinds commanded together, eight times, one stall):

  1. A relay router forwarded the coordinator's downClose to the blind's parent router and evidently retransmitted it: the parent sent two MAC acks for the same MAC sequence number, 4 ms apart.
  2. The parent (Philips Hue LST002, firmware 67.116.8) queued both copies for its sleepy child and delivered them on two consecutive data polls, 1.005 s apart, under different MAC sequence numbers.
  3. Both copies were the same NWK frame (same NWK sequence number, same APS counter, same ZCL transaction number). The blind MAC-acked both and answered both with its own Default Response (two different APS counters), so it processed the command twice.
  4. It sent the one position report already due and then stopped. It kept polling its parent at the normal 1 s interval.

In the same capture the same blind made 7 other moves and its sibling 8, each with exactly one delivery, all completed. Duplicate deliveries of Default Responses and APS acks to the blinds happened 19 times in that capture with no effect. Only the duplicated command stops the motor. This is one captured case plus the direct reproduction above.

Proposed change

For the IKEA blinds, send goToLiftPercentage for state open/close and keep stop as is. I am running this now as an external converter. With it, a doubled OPEN or CLOSE no longer stops the blind, and the sniffer shows goToLiftPercentage on air.

const stateViaPosition = {
    key: ['state'],
    convertSet: async (entity, key, value, meta) => {
        utils.assertString(value, key);
        const options = utils.getOptions(meta.mapped, entity);
        const v = value.toLowerCase();
        if (v === 'stop') {
            await entity.command('closuresWindowCovering', 'stop', {}, options);
            return;
        }
        const position = utils.getFromLookup(v, {open: 100, on: 100, close: 0, off: 0});
        const lift = meta.options.invert_cover ? position : 100 - position;
        await entity.command('closuresWindowCovering', 'goToLiftPercentage', {percentageliftvalue: lift}, options);
    },
};

const cover = m.windowCovering({controls: ['lift']});
cover.toZigbee = [stateViaPosition, ...cover.toZigbee.filter((c) => !c.key.includes('state'))];

This could be an IKEA-specific extend used by E2102 and E2103, and probably E1757 and E1926, which share the firmware family. I have only tested E2102 and E2103 on 24.4.13.

Related

Dominant language
TypeScript
Stars
15.8k
Forks
2.1k
Avg merge
1d 6h
Merged PRs (30d)
38

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Koenkk/zigbee2mqtt

All issues in Koenkk/zigbee2mqtt

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.