ZigNewbee question: what should an IKEA E1743 dimmer switch look like in ZHA?

Configuration Zigbee
1

Hi,
I am just starting using Zigbee in HA, so please bear we me…, and sorry for the rather long post.
The zigbee devices that I connected to HA up to now are:

  • As Coordinator: ZBDongle-E - Sonoff Zigbee 3.0 EFR32MG21 Dongle Plus-E

  • As a bulb: LED1836G9 - IKEA Tradfri LED bulb E26 806 lumen, dimmable, warm white

  • As a dimmer switch: E1743 - IKEA Tradfri ON/OFF Switch

The bulb and switch have been in use for several years as stand-alone setup (directly connected together), and that was working fine: both on/of and the dimmer function were working perfectly.
I already bought some other Zigbee devices to add them later (some IKEA E1746 Tradfri Signal Repeaters and some Sonoff SZNB-03 PIR sensors), but as a first test I am now trying to get the same functionality with the IKEA bulb and switch via ZHA.

This are the steps I followed up to now:

  1. Installed the ZHA integration
  2. Installed the Zigbee2MQTT add-on. However, I then found out that I cannot use both ZHA and Zigbee2MQTT together, so I disabled Zigbee2MQTT again.
  3. Configured the ZHA OTA firmware update in configuration.yaml for IKEA devices.
  4. Connected the coordinator to an USB port of my HA server (HA Supervised on a x86 system) via a high quality 3 meter USB extension cable. The coordinator was immediately successfully auto-configured by ZHA.
  5. Paired the bulb successfully with the coordinator. I can control the bulb including dimming function via the ZHA GUI. The bulb firmware was updated immediately to version 0x23093631
  6. Paired the switch with the coordinator. This is where the troubles begun.

The switch was recognized and initialized as “IKEA of Sweden TRADFRI on/off switch”, but was shown in ZHA as an “unk_manufacturer unk_model” device:

afbeelding
afbeelding990×219 54.8 KB

I then found out that ZHA was in the process of updating the firmware for the switch as well: I could see this in the diagnostics file and in the real-time log while searching for Zigbee devices. It was show as “OTA upgrade progress: “ with a percentage:

afbeelding
afbeelding715×256 68.8 KB

This upgrading took more than an hour, but when it was finished the switch was still shown as “unk_manufacturer unk_model”, even after a full restart of HA. There were only four Diagnostic entities for the device shown: “Battery” and “Identify” enabled, and “LQI” and “RSSI” disabled. So there were no Controls and Configuration entities. The firmware version was now shown as 0x23079631:

afbeelding

So then I removed the switch device from ZHA, and paired it again.
After that the switch was configured in ZHA as “IKEA of Sweden TRADFRI on/off switch” device, but I still saw only the same four entities, and nothing to really use the switch as intended (on/off and dimming).
The battery status was shown as 21%, so I then replaced the battery with a new one, but the status stayed at 21 % for a long time.

So I removed the switch device again, and re-paired it.
However, it then showed up as “unk_manufacturer unk_model” device again, with a battery status of 74%, but with still the same four Diagnostic entities, and still no Controls or Configuration entities.

After a long time the device name has been changed again to the presumably correct name “IKEA of Sweden TRADFRI on/off switch”, but unfortunately I still saw only the four Diagnostic entities.

And this morning I found out that the switch had become “Unavailable” in ZHA since late last night, and pressing the buttons on the switch did not make it appear again:

afbeelding
afbeelding822×621 68 KB

I then removed the battery from the switch to check it (it was still 3 Volt, so OK) and re-installed it, after which the switch re-appeared in ZHA, but still with only the four Diagnostic entities, and now a battery status of 255 % ??? And pressing any button on the switch does not have any effect in ZHA or HA:

afbeelding

Searching the HA forums I then found out that a Blueprint exists specifically for the E1743 switch. So I installed this blueprint, and linked it to both the bulb and switch. However, this does not work either, and I get this error message “Error: UndefinedError: ‘dict object’ has no attribute ‘event’”:

afbeelding
afbeelding998×581 79.8 KB

So I am out of ideas now, and my questions are now:

  • How should the E1743 switch show up in ZHA, and with what functionality?
  • Did I miss something in the set-up?
  • How can I use this switch with ZHA in HA?
  • What is the Diagnostic “Identify” button in ZHA meant for?
  • Will it be better to switch from ZHA to Zigbee2MQTT?
2

Hi,

It’s not you - it likely the end device hardware + firmware.

If you search the forum, you will find many posts detailing issues with IKEA Tradfri remotes behaving in odd and non-standard ways. Basically, IKEA added extensions to Zigbee to allow direct pairing between a remote and a device - and this causes issues, particuarly with ZHA, and some with Z2MQTT.

I’m surprised the firmware update was so quick as it usually takes a day or so to trigger.

The IKEA mains switches are fine, but I’d leave the radio remotes well alone unless you like troubleshooting Zigbee and replacing CR2032. There are lots of threads with recommendations with alternatives like Aqara, Sonoff, etc. The Sonoff 3 co-ordinator has a good name, although there are slightly different versions which act differently with other Zigbee stacks.

CR2032 start at about 3.2V and IKEA remotes die at about 2.9V - which gives lots of life for other devices such as bike lights.

ZHA also has a annoying issue where a battery device looses power, then either doesn’t come back after battery replacement, or looses attributes like battery level. Re-interviewing doesn’t work - factory reset and add new device sometimes does.

I hit a Tradfri single-button remote with a hammer as it only ever paired with a nearby Zigbee bulb, requiring two devices to be factory reset. :boom: :hammer:

(I hate landfill, but there are exceptions - the hammer put it beyond use to prevent ‘one more try…’)

I’ve heard Z2MQTT is better at handling IKEA oddities, which I can believe as currently a Sonoff door sensor is off-line as ZHA can’t find it after a battery replacement (but at least it lasted several months).

Oh, and always pair the device in the FINAL LOCATION where it will be used. Unlike Z-Wave (which recalculates with mesh every night), Zigbee seems to not like mesh changes, and some devices ignore new router devices right next to them (IKEA 5-button remotes being a ‘favourite’).

If this helps, :heart: this post!

1 Like
3

Hi James, thank you for your extensive answer.
Reading it, I conclude that there could be a mix of maximal three different problems with my current set-up:

  • ZHA has problems with specifically pairing to this IKEA E1743 switch
  • Battery powered IKEA remotes are troublesome with short battery live
  • ZHA has problems with connection persistency of battery powered devices that loose power for a while

So best would be to not use these IKEA switches at all with ZHA?
Or did I receive a “Monday morning” product (like we say in Dutch)? But on the other hand it has been functioning for me without problems for several years in a “normal” IKEA set-up. I only had to replace the battery once, and apparently it was still working like that with a 21% battery state.

So I am still curious as to whether anybody has successfully paired specifically an IKEA E1743 switch with ZHA, with full functionality? And if so, did this require specific settings that I missed up to now?

Regarding ZHA versus Z2MQTT: your second link brought me to some very informative forum posts about that: ZHA Vs Zigbee2Mqtt and ZHA or Zigbee2MQTT?
ZHA being an official HA integration, and Z2MQTT not, I assumed it would be best to choose for ZHA.
But in my case, because I still did not configure much Zigbee devices, it might be better now to switch over to Z2MQTT.
For what I understand about MQTT, one advantage of this protocol is that, due to the publish/subscribe set-up and the broker between the sender and the receiver, it is very insensitive to connection problems.
It is not clear to me what kind of protocol is being used by ZHA, but probably there is always a direct contact necessary between the Zigbee coordinator and the client device.
So ZHA might be more sensitive to connection problems, but on the other hand it normally should be more responsive (so faster) due to the direct contact?

One last question: I am now working with Home Assistant for two years, mainly using 433 MHz devices through a RFXtrx433XL and ESPHome devices using WiFi. This up to now always was a rock solid system. Can I normally expect the same from Zigbee devices, or is this more prone to connection problems?

4

Maybe I missed it but I could not see that you wrote about listening for events.
Did you not do that? That is how you use the device.
It sends events that you listen for.

Go to developer tools and listen for zha_event then click on the remote.

Everything you have shown seems to be as a working remote except the 200+ battery.

5

Thanks Hellis81.
Indeed I did not mention it, but I went that road, and there was zero traffic coming in from the E1743.
So there must be something wrong with the switch set-up?

Do you mean that it is as expected to only have these four Diagnostic entities in ZHA?

6

This is what mine looks like:

Screenshot_20221211-234312
Screenshot_20221211-234312720×1600 71.3 KB

7

Thanks, so that is exactly the same as mine, including the firmware version:
afbeelding

So the configuration in ZHA seems to be OK, and it probably is a kind of connection problem or battery level problem?

8

It’s hard to know how much the root cause lies with ZHA or the IKEA firmware, but I decided that the HASS phone app was easier to use than re-pairing / new batteries / repeat so don’t use IKEA remotes anymore. Interestingly, after replacing the CR2032 in a discarded 5-button remote and adding again as a new device, it now appears with 255% battery just like yours, suggesting something has changed recently.

I actually use one IKEA 5-button remote which is about 1m from the coordinator - strangely, this has always worked, and due to the short radio range, the battery lasts months. Zigbee does have both mesh networks, and for small numbers of devices or short-range links, also has direct connect mode (device straight to the coordinator). This makes me suspect the issue is linked to faulty router discovery triggering constant transmissions and hence running the battery down.

Any differences between ZHA and Z2MQTT will be on the Zigbee radio protocol and device definition side - the HASS interface is all local so the benefits MQTT brings to remote telemetry devices are unlikely to be used.
I’d agree that in theory, ZHA could allow a closer integration with HASS as it can use direct API calls without the need to model Zigbee devices in the intermediate format of MQTT Discovery.

As for reliability, there are many factors at work here other than radio frequencies and transmission power levels.

Z-Wave devices need a license and lab testing so tend to be higher cost. Zigbee is an open standard (think v3 may be different), so cheaper hardware seems to lead to lower build quality, “odd devices” like IKEA’s protocol extensions, and being newer, smaller batteries (e.g. cheap small CR2032 rather than expensive CR123A).

You can manually “heal” a Z-Wave mesh network - but I believe each Zigbee device has to discover neighbours on its own. This is why devices are best paired in their final location.

My experiments suggest IKEA remotes are terrible at noticing new mains powered routers. My living room 5-button IKEA remote ignored a new IKEA switch (Zigbee router) 0.5m away, and happily exhausted another CR2032 trying to shout back to the coordinator point-to-point!

I suspect this is why Thread uses the same IEEE 802.15.4 radios as Zigbee, but has a different protocol with support for multiple “coordinators”. It’s too early to tell if Thread is “better” than Zigbee as there are only a handful of devices available, and Zigbee 3 appeared with some protocol fixes and compatibility testing.

ESPhome kit tends to be mains operated for Wi-Fi high power levels so isn’t a direct comparison, and my experience of 433MHz kit is RTL-SDR so receive only without error correction so not great comparisons with Zigbee. Cheap Sonoff Zigbee sensors work fine, although the tiny reset hole and buttonswitch can confuse.

A decent Zigbee technology primer with lots of diagrams might help:

1 Like
9

Another datapoint: I have about 10 IKEA on/off and 5-button remotes and they work nearly flawlessly, but I’m running them in HA through deconz, not ZHA. The battery life is very good and they pair reliably. I run deconz on one USB stick and ZHA on another to have two zigbee networks.

10

Thanks again James for your extensive answers.

Interesting! So there might be a bug introduced recently?
I saw in the release notes of HA version 2022.12.4 that the ZHA quirks went to version 0.0.89, but after installing this update I could not see any difference, so unfortunately it does not solve this problem.

I already came across this “ZigBee and Wi-Fi Coexistence” web page, and before I installed ZHA I changed my 2.4 GHz WiFi network to use channel 11 now, and my Zigbee network uses the default channel 15, so this should be OK.

This indeed is a very interesting and extensive web site! Lots of Zigbee info to chew on…

11

Thanks David.
So the IKEA switches can work with HA, but the combination with ZHA appears to be the problem.

deCONZ is completely new for me again, so for now I prefer to first get to grips with ZHA before trying another variant.
But I am interested to know how these IKEA E1743 switches are presented in HA when used via deCONZ: are there more entities shown than only the four Diagnostics in my case, like Controls and/or Configuration entities?
As an example, this is how the IKEA LED 1836G9 bulb is presented for me via ZHA:

HA_ZHA_LED 1836G9_1

HA_ZHA_LED 1836G9_2
HA_ZHA_LED 1836G9_2327×783 23.5 KB

12

The only thing that shows up in HA is the battery. All the other information you have to get through the deconz plugin. There you have access to all the clusters and the like.

13

There is nothing wrong with ZHA and this remote type.
It works, it could be something faulty on your device or that it’s not paired correctly.
Try and reset the remote and pair it again.

But you will not get any more entities from ZigBee devices.
As far as I know all ZigBee integrations use events or MQTT (which is also kind of events).

You need to either listen to events or use device automations.

14

There is nothing wrong with ZHA and this remote type.

I’m pleased your systems seem to be working, however, regrettably, several other ZHA users are experiencing remarkably similar same issues with IKEA Zigbee remotes, especially after replacing a battery. Factory resets are often required to get a newly powered device to connect at all.

The ZHA integration connects directly to zigpy via direct Python calls without any dependency on MQTT. It’s pretty clear that the ZHA integration start-up Python code imports zigpy objects.

The docs state Zigbee2MQTT does explictly require a MQTT broker, and does use MQTT Discovery to export discovered devices into HASS.

An issue report in GitHub with debug traces to help ZHA / Quirks is on my list of stuff to do.

15

I use 2 x E1743 switches and both work without issue.
I’ve installed the required blueprint from here:-

And HA is using the following quirk:-

image

The blue print needs a tiny tweak to make the ZHA double click virtual event work, but it does generally work even without that tweak.

Both switches have been reliable and don’t seem to overly drain the batteries. The one thing I have noticed, which could be to do with their positioning, is that the switch thats furthest away, often appears offline, but when clicking the button on it, the automation works and it immediately becomes online again. The nearer switch appears online all the time.

The plus side of these buttons are that they are super cheap, and you can have up to six events fired off them (up and down for single, double and long press)

16

I also find these remotes very easy and not problematic.
The rotary one and four button remote has had more issues.

This on/off has just worked since day 1, last week I changed battery and it just connected on its own and worked after the new battery was installed.
I use events and node red to listen for button presses

17

Thanks again @dbs @Hellis81 @FloatingBoater and @Rofo for the additional info.
And I am pleased to tell that in the end I succeeded in getting this IKEA E1743 switch to work in ZHA.
What I did was resetting the switch by:

  1. Pushing the internal button four times rapidly
  2. Removing the existing entry from ZHA
  3. Letting ZHA find it again and pair with it

I did this several times before without success, but I now think that I did forget step two (removing the existing entry) in these previous trials.
Anyhow, it is working perfectly now with the IKEA bulb, including the dimmer function, using the “ZHA IKEA Tradfri on/off switch” Blueprint.
The only thing that is different from the original “IKEA only” set-up is that the dimmer responds much slower, but I don’t mind that because this makes the setting more accurate.
Just to be clear: I did not have to do anything else than re-adding the switch to ZHA, and the switch indeed is still shown in ZHA with only those four “Diagnostic” entities.

In the mean time I also added some IKEA E1746 Tradfri Signal Repeaters as Routers and one Sonoff SNZB-03 PIR switch, and these are all working fine as well at the moment.
So I am happy for now with my Zigbee set-up :smiley:

However, there is one new question that comes up now:
The IKEA light bulb is mounted in a ceiling lamp that can also be switched on and off via a physical wall switch.
When the light is switched-off via the IKEA E1743 switch and I want to switch it on with the physical wall switch I have to toggle this switch twice. This is logic and fine.
However, when I do this the light goes on but this is not seen by HA: in the GUI the light is still shown as “off”.
I then can still switch the light off again with the E1743, but I would prefer that the light status would always be shown in HA.
With a Shelly 1 I do not have this problem.
Is this solvable somehow by changing some settings in HA?

18

If you go into the Configuration for the bulb in HA you should have an option “Start-up behavior” which can be set to “on”. That way turning on wall switch should always turn the bulb on, regardless of what its previous state was. I have found that when bulbs are powered on from the wall they show up quite quickly in HA. However, if you have a lot of bulbs (I have 14 IKEA GU10s in track lights) if they get switched off, you will lose a lot of your zigbee network and it will take a while for that network to rebuild once it is all turned on. Individual bulbs are much faster, in my experience.
-David

19

Yes thanks David, but that is not the issue.
I already have this setting set to “on”, and the light indeed goes on when I switch the wall switch on:

afbeelding

The issue however is that when the light is switched on via the physical wall switch (so not via the E1743), the status “light on” is not shown in the HA GUI:

afbeelding

It is not a big issue, but it would be nicer when the status in the HA GUI would be accurate in this case as well.

20

You shouldn’t switch off the power to a smart bulb.
It makes no sense to do so, you risk destroying the bulb and you get this out of sync behavior.

Use remotes to switch the light.