I got all excited for a while when I found that page, it does show my modified values, however when I tried to change it and Apply I got
error 2021-12-05 13:53:10: Request 'zigbee2mqtt/bridge/request/device/configure_reporting' failed with error: 'Bind 0x00124b0022e93b79/1 msTemperatureMeasurement from '0x00124b001cde5703/1' failed (AREQ - ZDO - bindRsp after 10000ms)'
info 2021-12-05 13:53:10: MQTT publish: topic 'zigbee2mqtt/bridge/response/device/configure_reporting', payload '{"data":{},"error":"Bind 0x00124b0022e93b79/1 msTemperatureMeasurement from '0x00124b001cde5703/1' failed (AREQ - ZDO - bindRsp after 10000ms)","status":"error","transaction":"y8kyy-4"}'
and it went back to the original values.
On the page for the device on the zigbeeMQTT site it says:
It has been reported, that the sensor reports humidity changes quite frequently (changes on 2nd digit level), but temperature changes are reported only once per hour or when temperature has changed > ~0.6Ā°C. This results in a staircase development in recorded temperatures and inhibits fine-granular climate control. No resolution is known so far. See also Homeassistant Community Forums.
I saw that. Sounds to me as though you have the start of the fix for that. But it should really surface the control in the web interface. One to report as an issue I think?
On a slightly different tack, when you change any of those does it save it in the config file so that it is persistent? I wonder whether the problem is that it can only be reconfigured on initial connection, or something like that. If I manually put it in the config file it might work.
An assumption - better to be explicit since you have got the answer to hand and they don't seem to.
Yes it does.
Ah. Well I have my ZZH, I might consider getting one of these as a backup sometime in the future. The ZZH does cost 3x as much but given that you only need 1, I have fewer problems with that than I do spending more on individual plug/switch/sensor devices.
Now, off to try and buy some cheap ethernet RJ45 plugs because I've started to think again about where I want to put sensors a bit further away from the microcontrollers and while I can create custom dupont cables, it still isn't as easy as keeping the RJ45 cable in 1 piece and wiring in a plug I don't think (and I have a LOT of old RJ45 cables ).
Sorry, I don't, I just know that making adjustments to that page updates the config file. As I say, I'm not very expert with Zigbee2mqtt. Indeed, I've managed to mess up the whole thing several times when trying to do updates.
Assuming it is the same as the devce in the first post (the usb zigbee coordinator), that is a zigbee bus coordinator, which means it is the master device that slave devices (and routers, or repeaters) connect to. Mains powered zigbee devices are usually slave devices and also routers/repeaters so they can extend the bus.
zigbee2mqtt is a good software package to drive the coordinator and provide access via mqtt.
You can have multiple usb/serial devices. The next one will by AMA1. Which one to use is configurable in zigbee2mqtt. You might need to setup a udev rule to make sure they always connect to the same dev names.
It is a good idea to run a usb extension away from the board to the controller, so the rf wifi and zigbee signals don't interfere as much, if wifi is enabled on the pi.
Better still, you can use the device ID instead of the traditional /dev/tty* that saves you having to mess with udev rules. I did that after having my Debian server randomly swap the usb allocations. Indeed, you should also do that in Node-RED.
That's what I thought before I tried it and it put me off for the longest time. Much of it is badly written up to be honest because it really is very easy.
You need something to act as a controller. It defines the network. Then you need devices that you link to the controller - very much like Bluetooth. Really, that's it.
The only other thing to note is how the mesh is formed around the network. Also easy. any Zigbee device that is plugged into the mains acts as a local hub other devices close to a hub will connect to it rather than to the controller (assuming the controller is further away). Again, that's it.
You will very rarely need to know anything more unless you have so many devices that you run out of slots on the controller.
Setting up Zigbee2mqtt was slightly fiddly to start as they make some assumptions in their documentation. Running an update to it is also annoyingly fiddly until you've done it twice and realised that the instructions are unnecessarily complex and again make unwarrented assumptions.
But really even all that is actually not hard, just a bit annoying. I wrote myself this BASH script to do upgrades:
#! /usr/bin/env bash
# Stop Zigbee2MQTT and go to directory
sudo systemctl stop zigbee2mqtt
cd /opt/zigbee2mqtt
if [ -d data-backup ]; then
echo "ERROR: Backup directory exists. May be previous restoring was failed?"
echo "1. Save 'data-backup' and 'data' dirs to safe location to make possibility to restore config later."
echo "2. Manually delete 'data-backup' dir and try again. rm -rf /opt/zigbee2mqtt/data-backup"
exit 1
fi
# Backup configuration
echo "Backing up data folder to data-backup - will delete at end"
cp -R data data-backup
echo "Making extra backup of data folder to ~/nrmain/zigbee2mqtt-data-backup"
cp -R data /home/home/nrmain/zigbee2mqtt-data-backup
# Update
echo "If this fails - check if data/data/ exists - maybe run 'git stash'"
git checkout HEAD -- npm-shrinkwrap.json
git pull
npm ci
# Restore configuration
cp -R data-backup/* data
rm -rf data-backup
# Start Zigbee2MQTT
sudo systemctl start zigbee2mqtt
echo "Completed. Run 'sudo journalctl -u zigbee2mqtt' to see log"
cd ~/nrmain
It takes care of the two possible failure modes and reminds me what to do in each case.
I went through pretty much the same phases. I've now got 43 devices on our my Zigbee mesh within our 75mĀ² apartment(!). I have a bit different view of how easy/simple it can be. For me, setting up Zigbee2MQTT was easy. I'm running it on Docker with the help of Home - IOTstack. Connecting new devices using the web frontend has also been mostly easy, but I have already encountered few devices that were supposed to be supported by Zigbee2MQTT but in reality turned out to have incompatible hardware/firmware revisions on the market. To the credit of Koenkk, the wiz behind Z2M, most of the issues have been resolved within a few weeks at most.
When talking about Zigbee in general, I haven't yet gained pretty much any understanding of things like bindings or clusters for example. Understanding them doesn't seem to be necessary in order to use and like Zigbee but I would not go as far as say it is easy.
).
