@jarrah Thanks. Digging into the “groups” discussion on the github page gives me the impression that bulbs can belong to multiple groups, which is huge. Allows for the creation of fixtures inside rooms that Hue hub can’t do! I’ll have to test this out.
Hoping someone can point out someone obvious here, its doing my nut in at the moment.
Made the mistake of doing some config and cleanup while at work today. Updated HA, z2m etc and redid some of the code as I hit some breaking changes along the way.
Now all my automations related to z2m have stopped working and for the life of me cannot figure out why.
This is one example with my Hue remote, I have the same issue with Xiamoi buttons and door sensors connected through it. HA seems to be ‘ignoring’ automations connected to MQTT triggers.
I copied the new sensor and automation code directly from the github config pages as it has been updated since I first put them in. It works, HA sees it and changes the sensors state perfectly fine, it just will not trigger any actions attached to it!
(script.bedside_toggle = working fine on its own and when connected to FLIC button event)
z2m Config:
'0x0017880104091dba':
friendly_name: hue_remote_master_bedroom
HA YAML
sensor:
- platform: "mqtt"
name: HUE Remote - Master Bedroom
state_topic: "zigbee2mqtt/hue_remote_master_bedroom"
availability_topic: "zigbee2mqtt/bridge/state"
icon: "mdi:gesture-double-tap"
value_template: "{{ value_json.action }}"
force_update: true
automation:
- alias: Bedside Toggle
hide_entity: false
trigger:
platform: mqtt
topic: 'zigbee2mqtt/hue_remote_master_bedroom'
condition:
condition: template
value_template: "{{ 'off' == trigger.payload_json.action }}"
action:
- service: script.turn_on
entity_id: script.bedside_toggle
I can see it in the z2m logs:
zigbee2mqtt:info 2019-2-15 22:11:31 MQTT publish: topic 'zigbee2mqtt/hue_remote_master_bedroom', payload '{"battery":100,"linkquality":97,"last_seen":"2019-02-14T20:54:16.623Z","elapsed":1003052,"action":"off"}'
I can see it in HA logs
2019-02-15 22:11:31 DEBUG ... Received message on zigbee2mqtt/hue_remote_master_bedroom: b'{"battery":100,"linkquality":97,"last_seen":"2019-02-14T20:54:16.623Z","elapsed":1003052,"action":"off"}'
2019-02-15 22:11:31 DEBUG ... <Event state_changed[L]: entity_id=sensor.hue_remote_master_bedroom, old_state=<state sensor.hue_remote_master_bedroom=off; friendly_name=HUE Remote - Master Bedroom, ... @ 2019-02-15T22:10:10.396659+00:00>, new_state=<state sensor.hue_remote_master_bedroom=off; friendly_name=HUE Remote - Master Bedroom, ... @ 2019-02-15T22:11:31.182320+00:00>>
But the script does not get run, no mention of it in HA logs at all.
Now this is the absolute kicker, using the other hue remote events (on, press-up, press-down) in the exact same yaml, literally changing ‘off’ to one of the others…it works perfectly…
absolutely killing me this is 
Check the status of your automation, it might be accidentally switched off.
1 Like
Check if your automations are on. If you don’t have initial_state set to on in the automations, they are probably off now after upgrading to the new version.
1 Like
Make the state_topic in the sensor and automatisme part the same as the topic topic of z2m.
zigbee2mqtt/0x0017880104091dba
1 Like
O.M.G. I could kiss all of you.
They were all off except the working one. I didn’t even think to look at the state of the automations themselves…
I could cry 
1 Like
@wixoff could you please confirm the flashing process (and firmware to use) for this device? Thank you in advance.
For everyone with a CC2531 stick and not yet using the latest firmware (1.1.1), it is now possible to flash the latest firmware without re-pairing the devices (or using tin foil etc).
You have to use this version https://github.com/Koenkk/Z-Stack-firmware/tree/dev/coordinator/CC2531/bin
More info here https://github.com/Koenkk/zigbee2mqtt/issues/1088
Flashed my stick yesterday and that worked like a charm 
2 Likes
If I want to avoid re-pairing and use the latest firmware for the coordinator, is it mandatory to use the very same stick? I have a spare one and would love to flash a brand new stick instead. Thoughts?
1 Like
You have to use the same stick. When flashing you also have to select Retain eee address so the config is not overwritten.
I suggest you flash the spare stick as router so you can improve the range of the Zigbee network.
2 Likes
Thanks man!
is there anyway to have HA notice that a light is still on, and have it mark it as switched on on the front-end?
So for example, if I reboot HA and a light is on already, it won’t be reflected that way in HA.
thoughts?
I did not set retain eee to enabled (as in the flash docs) but my devices still work (did not have to repair.
Do does this really make a difference?
Apparantly not as all your devices are still working 
I have read somewhere in the forum that this settings needs to be enabled when flashing a new firmware version, but maybe that’s was only needed with the old method.
It will be reflected that way.
I have one ikea TRÅDFRI bulb. Unfortunately, I still have a dumb wall switch. If I switch on the bulb, HA won’t notice it in my case. I must manually slide the item in HA, and then it will pick the state up.
I understand from your response that HA should pick it up automatically whenever the light turns on?? In my case it doesn’t apparently.
AFAIK that issue hasn’t been solved yet.
If you’d mentioned the dumb wall switch to start with it might have been clearer.
Well, isn’t it the same case with rebooting HA and switching on a light?
Yes there is a way! In the config file of zigbee2mqtt you have to set your bulb to “retain: true”:
https://www.zigbee2mqtt.io/configuration/device_specific_configuration.html