Zigbee2mqtt revisited: No more ugly transformations

Yes I did. I’m not sure, but I assume that you included your thing in a mqtt-bridge configuration. Here is my thing definition:

Bridge mqtt:broker:zigbeeBroker [ host="YourHostname", secure=false, username="your_username", password="your_password" ]
{
    Thing topic permit_join "Z Permit Join" 
    {
        Channels:
            Type switch : permit_join [ stateTopic="zigbee2mqtt/bridge/config/permit_join",on="true", off="false" , commandTopic="zigbee2mqtt/bridge/config/permit_join", on="true", off="false"] 
    }
}

I used your Item, just changed the name of the mqtt broker (mine is zigbeeBroker)

Switch zPermitJoin "Zigbee Permit Join 2 min" (gXiaomi) { channel="mqtt:topic:zigbeeBroker:permit_join:permit_join"}

Or if you want it to auto expire after 2 minutes and having the expire Binding installed you can define your Item (this is what @chrode obviously initially tried when you look at the name of the item)

Switch zPermitJoin "Zigbee Permit Join 2 min" (gXiaomi) { channel="mqtt:topic:zigbeeBroker:permit_join:permit_join", expire="120s,command=OFF"}

Switching it on I got as a result the following lines in the log file of zigbee2mqtt:

May 16 ... 10:29:00: Zigbee: allowing new devices to join.
May 16 ... 10:29:00: MQTT publish: topic 'zigbee2mqtt/bridge/config', payload '{"version":"1.12.0","commit":"840b9d9","coordinator":{"type":"zStack12","meta":{"transportrev":2,"product":0,"majorrel":2,"minorrel":6,"maintrel":3,"revision":20190608}},"log_level":"info","permit_join":true}'

Switching it off:

May 16 ... 10:28:27: Zigbee: disabling joining new devices.
May 16 ... 10:28:27: MQTT publish: topic 'zigbee2mqtt/bridge/config', payload '{"version":"1.12.0","commit":"840b9d9","coordinator":{"type":"zStack12","meta":{"transportrev":2,"product":0,"majorrel":2,"minorrel":6,"maintrel":3,"revision":20190608}},"log_level":"info","permit_join":false}'

Thanks @chrode for the good Idea. So now you can disable permit_join in the configuration.yaml:

permit_join: false

And only when you want to add a new device make your system accept devices by switching it on via OpenHAB and either switching it off manually or by a timer.

1 Like

Just for completeness (to document the new door/window sensor).

  • Xiaomi Aqara Door and Window sensor MCCGQ11LM (rectangle, not round edges) thing:
Bridge mqtt:broker:MyMQTTBroker [host="localhost", secure=false] {
Thing topic SZKEY0 "SZKEY0" @ "SZ" {
        Channels:
            Type contact : contact "contact"            [ stateTopic = "zigbee2mqtt/SZKEY0/contact", off="true", on="false" ]
            Type number  : voltage "voltage"            [ stateTopic = "zigbee2mqtt/SZKEY0/voltage" ]     
            Type number  : battery "battery"            [ stateTopic = "zigbee2mqtt/SZKEY0/battery" ]     
            Type number  : linkquality "linkquality"    [ stateTopic = "zigbee2mqtt/SZKEY0/linkquality" ]               
    }
}
  • Xiaomi Aqara Door and Window sensor MCCGQ11LM (rectangle, not round edges) items:
    Contact SZKEY0_isOpen "SZKEY0 Status [%s]"  <window>  {channel="mqtt:topic:MyMQTTBroker:SZKEY0:contact"}
    Number  SZKEY0_VOLTAGE "SZKEY0 Voltage [%d mV]" {channel="mqtt:topic:MyMQTTBroker:SZKEY0:voltage"}
    Number  SZKEY0_BATTERY "SZKEY0 Battery [%.1f %%]" <battery> {channel="mqtt:topic:MyMQTTBroker:SZKEY0:battery"}
    Number  SZKEY0_LINKQUALITY "SZKEY0 Link Quality [%d]"  {channel="mqtt:topic:MyMQTTBroker:SZKEY0:linkquality"}

xiaomi_door_sensor

@rudi.tb
Good idea to post openHAB-instructions on the zigbee2mqtt.io website.
I get a warning for some ‘id’ not ok. Your way looks cleaner:
Thing

Thing mqtt:topic:MijiaDoorSensor "MiJia door & window contact sensor"  @ "Your room"

Item

contact  door_window_sensor_isOpen      "open status" <door>                    {channel="mqtt:topic:MijiaDoorSensor:status"}

But the way as described in the 1st post does not throw any warnings.

Thing topic SZKEY0 "SZKEY0" @ "SZ"

@tv-arnd Could you please be more precise?

I made all my zigbee2mqtt things like described on MCCGQ01LM and i don’t get any kind of warnings. So please tell me when and where you get which warning?

I have used this thing-file

Bridge mqtt:broker:MyMQTTBroker [host="localhost", secure=false] {
// Xiaomi Aqara Door and Window Sensor (MCCGQ11LM)
    Thing mqtt:topic:MijiaDoorSensor "MiJia door & window contact sensor"  @ "Your room"
    {
        Channels:
            Type contact  : status      "status"      [ stateTopic = "zigbee2mqtt/CONTACT1/contact", on="false", off="true" ]
            Type number   : voltage     "voltage"     [ stateTopic = "zigbee2mqtt/CONTACT1/voltage" ]
            Type number   : battery     "battery"     [ stateTopic = "zigbee2mqtt/CONTACT1/battery" ]
            Type number   : linkquality "linkquality" [ stateTopic = "zigbee2mqtt/CONTACT1/linkquality" ]
    }
}

And get the following log-message (with an ‘INFO’ not a ‘warning’):

2020-05-26 08:24:38.780 [INFO ] [el.core.internal.ModelRepositoryImpl] - Validation issues found in configuration model 'zigbee2mqtt.things', using it anyway:
Provide a thing type ID and a thing ID in this format: <thingTypeId> <thingId>
2020-05-26 08:24:38.786 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'zigbee2mqtt.things'

I use openHAB 2.5.5-1 (Release Build)
It works (the 4 sensor channels/items are updated on sitemap). I like this nomenclature. It is also ‘officially’ recommended here: https://www.openhab.org/blog/2018-12-16-mqtt-arrives-in-the-modern-openhab-2-x-architecture.html#configuration-via-text-files
Maybe it is just a cosmetic issue? Shall we keep going on with this nomenclature (might be confusing to others)? We could add further openHAB configuration instructions to more sensors on zigbeetmqtt.io.

It is quite interesting. I’m using 2.5.4 (Release Build). But maybe they changed the rules and now they throw an info message. My suggestion is, let me figure out if this is a general 2.5.5 issue or it is just a configuration on your side. But I totally agree that we should use on the zigbee2mqtt documentation only one nomenclature. I prefered this one as the item channels linking is more clear to me as you do not need the brdige name in the channel path. But if this nomenclature is throwing a warning we have to change to the other one.

Finallly I found the time to upgrade to openHAB 2.5.5-1 (Release Build). And there we are, I also got your warning message. For me it is unbelivable, that they put so much change into a 0.0.1 Release update. But this is not the right place to discuss that topic.

I changed my whole configuration from:

Thing topic:mqtt:myMQTTThing "Description" @"room" {...}

to:

Thing topic myMQTTThing "Description" @"room" {...}

and in the item file I changed from:

ItemType MyItemName  "My Item description/text" <icon> {channel="mqtt:topic:myMQTTThing:occupancy" }

to

ItemType MyItemName  "My Item description/text" <icon> {channel="mqtt:topic:NAME_MQTT_BROKER:myMQTTThing:occupancy" }

@tv-arnd Thanks for your hint. And now of course I will also change the nomenclature on the zigbee2mqqt.io website.

Update:
I already changed my documentation on MCCGQ01LM to the OpenHAB preferred nomenclature.

1 Like

Has someone a solution to dimm Tradfri Bulbs?

By using brightness? On openhab side either use a slider or a color item. Both must simply send the brightness to zigbee2mqtt

See here: Zigbee2mqtt revisited: No more ugly transformations

1 Like

Thank you, now its working, i missed this post :slight_smile:

Here is an example how to monitor presence of the Zigbee-bridge - similar to the network-binding (ping to detect presence).
What you get:
Zigbee01_sitemap
Find everything here (rename to zip): zigbee-bridge_monitoring.zip.pdf (3.3 KB)

If you take a look at the MQTT-Explorer, the bridge has a state (online / offline):
Zigbee02_MQTT-Explorer
This requires some mappings and renamed icons.

things-file:

Bridge mqtt:broker:MyMQTTBroker [host="localhost", secure=false] {

// Texas Instruments ZigBee to MQTT board
Thing topic bridge "TI ZigBee Bridge " @ "Your Room" {
        Channels:
            Type contact : state "state"            [ stateTopic = "zigbee2mqtt/bridge/state", off="offline", on="online" ] // online=on=open, offline=off=closed       
    }

items-file:

    // TI ZigBee to MQTT board
        Contact ZigBeeBridge_state "ZigBee Bridge (TI CC1352P) [MAP(contact_online.map):%s]" <myswitch> {channel="mqtt:topic:MyMQTTBroker:bridge:state"} // use modified switch-icon for contact with open/closed

transformation-file (contact_online.map)

CLOSED=OFFLINE
OPEN=ONLINE
NULL=undefiniert
-=Hyphen

sitemap-file

sitemap default label="Home" {
Frame label="Network Monitoring" {
        Text item=WiFi_AP                   icon=switch  // just as an example for a ping-device
        Text item=PhilipsHUE_ZigBeeBridge   // just as an example for a ping-device
        Default item=ZigBeeBridge_state // use myswitch icon
    }

This nicely detects unplugging the bridge from USB-port (and its re-connect). Very fast.
Can be used in a section together with ping-devices (same icon / status-text appearance).

6 Likes

This is a long and useful topic! This may be more of a Zigbee2MQTT question but how do we find out all the available options that something like a Hue RGB bulb has?

I am used to my Xiaomi sensors and sockets which seem to broadcast their current status. Am I right in saying the HueBulbs don’t broadcast their current state and settings?

What I do with a new Zigbee device, after pairing with zigbee2mqtt, is use MQTT Explorer to ‘sniff’ what the new device parameters are.

Sometimes you’ll also have to command the device to see what the ‘extra’ parameters are, such as double or triple button presses, though I don’t know if that’s necessary for a bulb.

1 Like

Yeah that’s what I do with my sensors… But with the Hue Bulbs I don’t have a hue hub or remote so now way to control the bulbs except for using Zigbee2MQTT…

Look for your device in this table - it includes the modes (and therefore the commands) which are supported.

Either way, surely when you turn your bulb on (as in, supply it with power), it will initially communicate with zigbee2mqtt, and therefore you’ll be able to pick up most parameters?

Yeah that was what I thought, but all I see in the Zigbee2MQTT logs is the bulb “announcing” itself… It doesn’t send anything else about itself…

Ah, but I was on about using something like MQTT Explorer or mqtt.fx to do the sniffing, not looking in the zigbee2mqtt logs…

I’ve never used Hue bulbs, so they may be different, but I’ve used this method successfully for two different types of IKEA Tradfri bulbs.

I also have an Osram RGBW Bulb but unfortunately, your solution doesn’t work for me :frowning:

I have set the same “formatBeforePublish” pattern but only the first value of the color state is being published. For example the color state is 230,100,100 then only 230 is inserted as the %s inside the format.

I just found the solution:
When we have a comma separated string, the first %s in the format represents the first value, the second %s the second and so on.
Example (you can set the outgoing value format via PaperUI and it will do the necessary escapes for you):
color state: 230,100,100
outgoing value format: {"color": {"hsb": "%s"}}
result: {"color": {"hsb": "230"}}
… doesn’t work!

outgoing value format: {"color": {"hsb": "%s,%s,%s"}}
result: {"color": {"hsb": "230,100,100"}}
… exactly what we need :slight_smile:

I also made a pull request to update the readme of the mqtt-binding.

3 Likes

Hello.

I have a problem can you help ? about

  • Osram SmartPlug thing:

    Thing topic SZLV “SZLV” @ “SZ”

can you tell me why when i remove this from the line it works " @ “SZ”` "

i dont know were to find any thing about it ,becourse i dont know what it do ?

I hope you can help Simon . :slight_smile: I know it`s a mqtt thing problem but ?

PS : can you show some of your zigbee sitemap ? i have it working i paperui and shows up in log fine ,but i can`t get anything to show up on sitemap ??