Monitor and control zigbee2mqtt and zigbee dongle (CC2531)

[hafniumzinc (T)]

Inspired by a recent post from @tv-arnd, here is a simple method to:

• See if the zigbee dongle (CC2531 in my case) is online or offline
• Switch zigbee2mqtt permit_join on or off
• Change the level of zigbee2mqtt logging

things files

bridge.things

I use a separate things file for my Mosquitto bridge:

Bridge mqtt:broker:MosquittoMqttBroker "Mosquitto MQTT Broker" [
	host="192.168.1.92",
	secure=false,
	port=1883,
	clientID="OpenHAB2"
]

zigbee.things

Thing mqtt:topic:bridge "CC2531" (mqtt:broker:MosquittoMqttBroker) {
    Channels:
        Type switch : state "State" [
            stateTopic = "zigbee2mqtt/bridge/state",
            off="offline",
            on="online" 
        ]
        Type switch : permitJoin "Permit join" [
            stateTopic = "zigbee2mqtt/bridge/config",
            transformationPattern="JSONPATH:$.permit_join",
            commandTopic="zigbee2mqtt/bridge/config/permit_join",
            off="false",
            on="true"
        ]
        Type number : logLevel "Log level" [
            stateTopic = "zigbee2mqtt/bridge/config",
            transformationPattern="JSONPATH:$.log_level∩MAP:num2loglevel.map",
            commandTopic="zigbee2mqtt/bridge/config/log_level",
            transformationPatternOut="MAP:num2loglevel.map"
        ]  
}

Items

zigbee.items

Switch sZigbeeDongle "Zigbee dongle " (gReachable) {channel="mqtt:topic:bridge:state"}
Switch sZigbeePermitJoin "Zigbee permit join" {channel="mqtt:topic:bridge:permitJoin"}
Number nZigbeeLogLevel "Zigbee log level" {channel="mqtt:topic:bridge:logLevel"}

Sitemap file

snippet

Text item=sZigbeeDongle label="Zigbee dongle [MAP(switch2online.map):%s]" icon="shield"
Switch item=sZigbeePermitJoin label="Zigbee permit join"
Switch item=nZigbeeLogLevel label="Zigbee log level []" mappings=[0="D", 1="I", 2="W", 3="E"]

Map files

switch2online.map

OFF=OFFLINE
ON=ONLINE
NULL=UNDEFINED
-=-

num2loglevel.map

0=debug
1=info
2=warn
3=error
debug=0
info=1
warn=2
error=3

Further

There are many more topics which could be controlled or interrogated: | Zigbee2MQTT

Here’s a similar example:

Sonoff Zigbee (SNZB) Sensors & Switches with Zigbee2MQTT

With the recent release of the affordable Sonoff Zigbee range, I decided to upgrade some sensors around the house from RF to Zigbee. Here is how I added them to my openHAB installation. There are (at least) two ways to go about adding Zigbee things: The Zigbee Binding Using a Zigbee to MQTT bridge I chose the second option. Prerequisites: This guide assumes that you already have a working MQTT Broker such as the embedded openHAB MQTT Broker Moquette or Mosquitto. Note: This guide contains…

[Bruce_Osborne]

Please remove zigbee from the title. This is just for zigbee2mqtt, not the official zigbee binding.

[hafniumzinc (T)]

But it is relevant to a zigbee dongle, which is there in full in the title.

[Bruce_Osborne]

Flashed with zigbee2mqtt firmware which changes it a lot.

[rubens (Daniel Planets)]

Thanks for that. It didn’t work immediately for me but it does now after I fiddled with transformations and as a surprise suddenly 21 mqtt:homeassistant_zigbee2mqtt - things were autodiscovered. So apparently OH2 is happy, too.

At first, when I clicked on the Permit Join - switch mqtt wrote

z2m/bridge/config/permit_join 1
z2m/bridge/config {"version":"1.13.1-dev","commit":"89a6c97","coordinator":{"type":"zStack12","meta":{"transportrev":2,"product":0,"majorrel":2,"minorrel":6,"maintrel":3,"revision":20190608}},"log_level":"error","permit_join":false}

(command and state, the significant bit of the state at the very end, in short:
the binding messaged ON/OFF as 1/0 and zigbee2mqtt took 1 to mean false, too.)
So I tried this and that and finally appended your previously not referenced switch2online.map with

true=true
false=false

and while that looks completly redundant it still did the trick.
Sometimes I feel I’m just too stupid for those things…

[hafniumzinc (T)]

Interesting! Could you copy/paste your permit_join channel? Have you kept the on=“true”, off=“false” that I’ve got?

[shorty707]

@Bruce_Osborne

official

Official?

Isn’t any solution from the community valid …

[Bruce_Osborne]

@shorty707

Official?

Yes. Distributed with the openHAB distribution and has been for years.

[Gad_Ofir]

Thank you!
keep up the good work !

[rubens (Daniel Planets)]

my apologies to @Bruce_Osborne for me showing continued interest in unofficial ways to talk to my tradfris, but hej, [Solved] Zigbee2mqtt vs "ordinary" zigbee …

@hafniumzinc:

    Thing topic z2mBridge "CC2531"  {
    Channels:

        Type switch : permitJoin "Permit join" [
            stateTopic = "z2m/bridge/config",
            transformationPattern="JSONPATH:$.permit_join∩MAP:switch2online.map",
            commandTopic="z2m/bridge/config/permit_join",
            transformationPatternOut="MAP:switch2online.map",
            off="false",
            on="true"
        ]
...

and the map goes:

OFF=OFFLINE
ON=ONLINE
NULL=UNDEFINED
-=-
true=true
false=false
0=false
1=true

The last 2 lines are left over from my try-things phase. W/o the true=true - lines mqtt would give

z2m/bridge/config/permit_join (null)

No surprise, there has to be a match. But apparently the value already is one out of [true, false] so why would a [1, 0] be written to mqtt? Interesting indeed.

[jfrank1845 (Jared Frank)]

While I agree the “official” zigbee is great - I have also found it to be completely useless due to the development path. Now that we have only the color Channel and CT channel with color bulbs it is impossible to have the bulb and know what state the bulb is in relating to switch or dimmer level. I tried to create a discussion around this as I can’t believe I’m the only other that finds this to be prohibitive. It is because of this I had to stop using the built in binding and ultimately switch to hubitat. (I had done zigbee2mqtt but didn’t get colors to translate correctly / just went with a retail solution for simplicity.)

I guess the TLDR is that other methods are still needed because of limitations and design patterns adopted by the official binding that don’t work for everyone.

[Bruce_Osborne]

@jfrank1845

I have also found it to be completely useless due to the development path

Really? I think @chris is one of our more dedicated developers.

[chris (Chris Jackson)]

@jfrank1845

I have also found it to be completely useless due to the development path.

What development path do you mean?

@jfrank1845

Now that we have only the color Channel and CT channel with color bulbs it is impossible to have the bulb and know what state the bulb is in relating to switch or dimmer level.

I agree - this is not nice, but I was forced into this by openHAB maintainers. We originally wanted a separate channel to indicate what mode the bulb was in and I was forced to remove this channel.

Add color_mode channel and minor code fixes to all converters

Remove color_mode status channel

I tried to make this useful, but I can only apologise that it was not possible. I guess other bindings were able to sneak this past the eagle eyes of the maintainers .

[jfrank1845 (Jared Frank)]

He is a great developer I agree - as he posted though he was pushed down this path and it is such a fundamental aspect that I can’t utilize the binding as I have logic that depends on knowing when a bulb is on /off. To me this is basic functionality that should have never been taken away.

It is crazy that knowing if a bulb is white we color mode trumps on vs off.

[AFromD (Arno)]

I worked around this with a rule that allows keeping lamps in HSB mode all the time. It will “translate” any CT commands into HSB commands. The CT channels are therefore not linked to their respective channels, they are just used to start off the rule.

How I remedied the glaring white Alexa insists on

Problem: Right now, the OH Alexa skill doesn’t support color temperature yet. “White” will command the most unfriendly, glaring shade of white the lamp is able to produce. The whitest it can do. Challenge: My Hue lamps do support color temperature, and I can control that via the zigbee binding, but it is a seperate mode of operation. This means that once you use color temperature, the HSB color channel is not updated to reflect what the lamp is doing. So after you have corrected the glaring w…

[Bruce_Osborne]

We definitely need a more flexible system for developers.

[chris (Chris Jackson)]

@jfrank1845

It is crazy

I agree, it is, and was then, really a crazy situation and I really don’t think it was understood by those telling me to remove it. I might revisit this PR and add it back again.

A lot has changed in the 2 years or so since this was first added, and then removed. Back then, ESH roamed the planet, and a lot of this was driven by German Telekom. Much of the work I was doing on the binding was specifically for Deutsche Telekom and therefore options were limited with my direction.

Now all that has changed. ESH is dead, and DT and others have forked code into separate systems. This includes the ZigBee binding, so I think there is a little more freedom for me to add this back again.