It works as long as I have the three other channels & items (for my Hue). As soon as I add your channel example from post #154 the thing will return an error message saying
" Status: OFFLINE CONFIGURATION_ERROR
Remove and recreate: mqtt:topic:OH_MQTT:Hue_Go1:HueGo1_Farbe "
Hi,
this guide had converted me to use zigbee2mqtt, purchase USB zigbee dongle, and ditch Xiaomi smart home hub. Thank you very much.
I have almost everything working, but there is only 1 that I still have problem. I have xiaomi wall switch, without battery. A command from OH do change the physical state, but OH state does not change. I suspect it is because of mqtt published the command and state almost instantly. Can anyone give pointer to me to fix that?
Thing topic xmbackyardsw "XM Backyard Switch" @ "Hall"
{
Channels:
Type switch : state "state" [ stateTopic = "zigbee2mqtt/backyard_switch/state", commandTopic="zigbee2mqtt/backyard_switch/set/state", on="ON", off="OFF" ]
Type string : action "action" [ stateTopic = "zigbee2mqtt/backyard_switch/action" ]
Type string : click "click" [ stateTopic = "zigbee2mqtt/backyard_switch/click" ]
Type number : linkquality "linkquality" [ stateTopic = "zigbee2mqtt/backyard_switch/linkquality" ]
}
2nd question:
How to set request to get device state/consumption/etc?
I know there is /zigbee2mqtt/deviceID/get channel, but does not know how send this get command periodically.
@WeirdlyChosen I had what sounds like the same issue with a Hue switch. It would send the triggered state, but immediately clear it and OpenHAB would miss the triggered state 75% of the time. This is what worked for me, since a Command is different than a State change:
// Add "",postCommand=true" to incoming things like switches to make them generate OpenHAB commands instead of just state changes
Thing topic test_hueswitch {
Type string : click [ stateTopic="zigbee2mqtt/test_hueswitch/action", postCommand=true]
Type number : battery [ stateTopic="zigbee2mqtt/test_hueswitch/battery"]
Type number : counter [ stateTopic="zigbee2mqtt/test_hueswitch/counter"]
Type number : linkquality [ stateTopic="zigbee2mqtt/test_hueswitch/linkquality"]
}
Now my rule can check on command received instead of on state changed. OpenHAB doesn’t miss commands like it misses too-fast state changes.
postCommand: If true, the received MQTT value will not only update the state of linked items, but command it. The default is false. You usually need this to be true if your item is also linked to another channel, say a KNX actor, and you want a received MQTT payload to command that KNX actor.
Thank you for insight of postCommand, it really reduce the line length of the code compared commandTopic channel.
Unfortunately, this does not really help in my case. Using commandTopic channel send command to item, switch changed, but the state return back to old state. Same with using postCommand.
When adding an mqtt:dimmer channel for a zigbee light brightness value,
I use 0 as min value and 254 as max value for the channel.
There are two problems with 3.1.0 M3:
Values from 0 to 100 are converted to 0 to 254, but the value contains decimals e.g 152.76 . Zigbee2mqtt seems to handle this well, but I did define formatBeforePublish: “%d” so only integers should used. The %d seems to be ignored.
An item created for this mqtt:dimmer channel has a range of 0-254. I’d expect (and want) it to have a range of 0…100. For this item, the value of 100 already pushes a message with the value 254 to mqtt. A higher values of the dimmer slider are ignored by zigbee2mqtt, because they result in values above 254.
Thanks, but you are showing exactly why I love openHAB
The fact ‘Things’ are not the end-devices, like (all?) other HA systems, but you create them yourself as ‘Items’ and have great power on how they are composed (maybe of different things), represented, behave and offered to e.g. Google and Alexa.
I know there are virtual devices possible on some systems, but to make them work well in a bi-directional way (setting / reading values as if it is a ‘normal’ device) requires a lot of manual work which often includes a lot of scripting.
So sorry, I forgot to mention your proposal is the ‘solution’ I am using.
But IMHO this is a solution that uses an item to fix a ‘broken’ thing channel, which is again what openHAB was ‘made for’. Still I’d expect if I configure a channel as percentage (which results in mqtt:Dimmer) and specify the abolsute min and max, stating the max value must represent 100%, the channel has a range of 0…100 when repesented to items and hides the fact it internally uses 0…254
Sorry I don’t agree, zigbee2mqtt reflects the zigbee standard as mqtt. So brightness values should be 1…254 (0 is officially not legal, but most devices accept is as turn-off value)
The mqtt generic binding offers a percentage channel (Dimmer) which as far as I understand should always give a 0…100 range. If the underlying mqtt topic uses a different range, it should be translated, so channel 0…100 to min…max of topic, while also respecting the formatting setting.
This is how I understand the documentation, but in my case this seems not to work.
The strange thing is then when I look at the openHAB code (I didn’t do any debugging on it yet), this is also how I’d expect it to work…
not yet, once I am fully convinced it is an openHab issue, I will create the issue.
There are 2 ways to look at it:
can we work around it to just make things work → yes, multiple ways your first suggestion being the best one IMHO
is this how openHab should handle this. → I don’t think so, but maybe someone can explain I am doing it wrong (on the thing level) or that I expect functionality which was not intended to work like I am expecting it to work
“I have no idea why this all works, because the slider is 0-100%, but the bulb seems to receive 0-255 via MQTT - something somewhere is transforming the 0-100 from the slider to 0-255 for the bulb, but I don’t know what.”
Yes it works and the dimmer values from 0…100 on the thing channel are translated back and forth to 0…254 on the mqtt topic, but in my case the dimmer thing channel gets a 0…254 range, of which only 0…100 are usable. So my guess it has something to do with the way the thing channel reports min/max which should 0…100 for a dimmer but is 0…254.
I know I can set the dimmer range to 0…100 or add generic meta data to the item for this. But I’d expect it to work like that in the first place.
Is it normal that battery powered devices does not update it’s state periodically? I have some Xiaomi motion sensors, temp & humid sensors and window sensors. Z2m does not send any mqtt update at all, even for temp & humidity sensor. Do I need a rule to ask for update periodically?
Hi, tell me.I have configured the zigbeetomqtt binding there is one problem.after the reboot, the sensors that I connected go offline. at the same time, the broker itself is in the online mode.when I go to the broker’s thing and click on save, the sensors connect to the broker.how do I make sure that the sensors are online after a reboot?
Some sensors do only on “activity” or on a set timeframe. Example:
My Xiaomi motion sensor only updates (all) values (i.e. last seen) when motion is detected.
On the other hand, my Xiaomi smoke detector only updates every hour (when there is no alarm).
You can check the z2mqtt documentation, whereas some of this behavior is not necessarily documented there.
first thanks for this topic this helps a lot. Today i were able to “integrate” my Ikea LED1624G9 bulb.
I added channels for Power ON/OFF and for Brightness these work fine,
Now i want to add color but i never get “Sliders for color” i get always NULL
Here are my stats from MQTT Explorer:
i tried other ColorModes but i never get “Silders”
