Monitor and control zigbee2mqtt and zigbee dongle (CC2531)

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"]

image

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: https://www.zigbee2mqtt.io/information/mqtt_topics_and_message_structure.html

Here’s a similar example:

5 Likes

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

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

Flashed with zigbee2mqtt firmware which changes it a lot.

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… :wink:

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

Official?

Isn’t any solution from the community valid …

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

Thank you!
keep up the good work !

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.

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.

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

2 Likes

What development path do you mean?

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.

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 :wink: .

2 Likes

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.

2 Likes

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.

1 Like

We definitely need a more flexible system for developers.

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.

1 Like

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.