Zigbee2mqtt: Friendly Name Issue

[Imperial-Guard]

Seems to be a issue with friendly names for switching a device like a light bulb or thermostat like the Ecozy.

With the sensors I don't have any issues with the following topic names:

devices:
'0x00158d00022d2d2c':
friendly_name: living_room/sensor/0004/doorsensor
retain: false
'0x00158d000232c194':
friendly_name: living_room/sensor/0003/gardendoorsensor
retain: false
'0x00158d000243753d':
friendly_name: scullery/sensor/0001/gardendoorsensor
retain: false
'0x00158d0002b45f88':
friendly_name: kitchen/sensor/0001/motionsensor
occupancy_timeout: 300
retain: false
'0x00158d0002b4863d':
friendly_name: hallway/sensor/0003/motionsensor
occupancy_timeout: 60
retain: false

For the following devices I got issues, for testing purposes I changed the name for light bulb in the basement to _ instead of /. When I use the / I can't switch the light or change the setpoint of the thermostat

'0x0017880100de56d3':
friendly_name: basement_light_0003_basementlight
retain: false
'0x001788011032d314':
friendly_name: '0x001788011032d314'
retain: false
'0x70b3d5de00000ece':
friendly_name: bedroom/switch/0001/thermostat
retain: false

[Koenkk]

Are you on zigbee2mqtt version 0.1.6?

[Imperial-Guard]

Are you on zigbee2mqtt version 0.1.6?

Yes :)

[Koenkk]

That's because zigbee2mqtt doesn't listen to those messages (https://github.com/Koenkk/zigbee2mqtt/blob/master/lib/controller.js#L69).

I would not recommend using / as a seperator.

[Imperial-Guard]

Oops wrong button.

Too bad, is it possible for a feature request?

All my other MQTT devices are build up with this type of naming convention.
The sensors itself work with this kind of format not the devices with a subscribe on set.

[Koenkk]

Could you change https://github.com/Koenkk/zigbee2mqtt/blob/master/lib/controller.js#L69 to

                    const subscriptions = [
                        `${settings.get().mqtt.base_topic}/+/set`,
                        `${settings.get().mqtt.base_topic}/+/+/set`,
                        `${settings.get().mqtt.base_topic}/+/+/+/set`,
                        `${settings.get().mqtt.base_topic}/+/+/+/+/set`,
                        `${settings.get().mqtt.base_topic}/+/+/+/+/+/set`,
                        `${settings.get().mqtt.base_topic}/+/+/+/+/+/+/set`,
                        `${settings.get().mqtt.base_topic}/+/+/+/+/+/+/+/set`,
                        `${settings.get().mqtt.base_topic}/bridge/config/+`,
                    ];

[dirstel]

I'll sign this one. I'd like to use some structured topics as well.

[Koenkk]

@dirstel can you make the change and check if it works?

[dirstel]

May take some time... Right now I'm using the Docker-Image "as-is". But I'm surly willing to contribute.

Thinking about this issue, I thought of different solutions:

1) hardcoded "depth" as you suggested => quick and should do => Step 1
2) configure "depth" in configuration.yaml => some more work, some less topics to check in certain environments (up to "/+/+/+/set" should be enough for me)
3) subscribe to topics based on devices => lots of work, but clean solution

I'll take care of 1) as soon as possible. 2) and 3) may come later. But do not expect results that soon :-)

[dirstel]

For the sake of a quick proove I added the lines inside the container (without rebuilding):

zigbee2mqtt:warn 2018-10-26 18:07:38 Cannot handle MQTT message with topic 'home/0_ug/archiv/lampe-1/set' and message '{"state": "ON"}'

So it helps by making aware of the message (before there has been no reaction to the message). But there has to be some parsing part which prevents interpreting the topic/message right.

:-(

[Imperial-Guard]

Hmm too bad...

[Koenkk]

Implemented! You can test it by checking out the latest dev branch.

Configurations like:

mqtt:
  base_topic: zigbee2mqtt/my/sweet/home
  server: 'mqtt://localhost'
devices:
  '0x000b57fffec86dbb':
    friendly_name: 'garden/outdoor/light'
    retain: false

are now possible.

[dirstel]

I tried latest-dev docker image today: Works like a charme! Thanks a lot!

[Koenkk]

@dirstel thanks for reporting back :)