I do have some Xiaomi devices here and will take a look at these when I get a chance. It’s worth noting though that the Xiaomi devices are not Zigbee compliant - they use Zigbee like communications, and 802.15.4, but that doesn’t make them compliant. I’ve seen other notes on the net that they don’t work with other Zigbee gateways such as SmartThings.
That’s not to say it’s not possible, and I do intend to see if it’s possible to make it work, but please be aware it may not be possible if the Xiaomi sensors don’t fully implement Zigbee protocols.
I’m not sure that logging USB traffic will help too much though - I’d probably need to see a sniffer log.
When changing the coordinator’s (Ember) channel in both Habmin and PaperUI, I get the following errors. Also, what is the purpose of the Reset Controller field?
Configuration isn’t handled at that point - it only gets handled when the handler restarts. I’ll remove the log entry - but it won’t change anything.
It will reinitialise the coordinator - this makes changes to the coordinator configuration such as the PAN Id, EPAN Id, channel, etc. Otherwise the startup will just use the existing parameters.
Correction… when I make changes in PaperUI, I get the errors above. When I do it in Habmin, I get the following whether I set Reset Controller to true or not
I’m not sure I have this yet. If Reset Controller is false, will changes to the coordinator be saved and applied after the next startup… and if it is true, then the coordinator will restart immediately and apply the changes?
That’s just because PaperUI always updates every parameter, and HABmin only sends updates to parameters that have changed. This is one reason I don’t suggest to use PaperUI for this on ZWave - you can easily end up with 50 to 100 configuration updates being sent to the device when you change the device name (ie nothing actually changed, but now you have a LOT of configuration to send).
The configuration is only applied at the startup of the thing handler. What I can’t remember is if I restart the thing handler at this point in which case it would be immediate. It should restart immediately - I just have a feeling it might not…
When Reset Controller was false, none of the configuration changes were being saved in Habmin or PaperUI. When Reset Controller was true, PaperUI did not save the changes and did not restart the controller (or thing handler). Habmin did try to restart it, but then the binding was stuck in a loop of errors. I’m packing up the logs for you. Looks like the same errors I was seeing when restarting the binding. After I restarted OH, the changes to the settings I’d made were not applied. So, configuration changes did not save when Reset Controller was true or false.
I don’t think Reset is the best word to use here. And it’s a little scary too. Maybe changing Reset to Restart would work better?
Strange - I don’t know why there would be any difference, and I can’t see any way that the configuration won’t be saved. The method in the binding is very short and unless there’s an exception thrown, there’s no exit point that doesn’t save the configuration.
Well, it resets the controller if you change the parameters. It’s likely that it will scrub the network and all associations (it might depend slightly on the stick used - TI I’m sure will completely reset - Ember might save some configuration).
It is scary stuff - avoid doing it . If there’s some configuration that needs to change outside of this then we could look at it - channel might be a valid need, but anything else WILL need to reset the stick as you can’t change the PAN ids, mac address etc on a running network.
Neither PaperUI nor Habmin is saving the changes for me, so there’s no difference. I’ve tried now many times, but with no success. The binding only seemed to try to restart (but crashed) the one time (I opened a ticket and sent you the log).
The only setting I’m trying to change is the channel . The EZSP_ENERGY_SCAN in the log shows a better channel than what I’ve selected, so I thought I’d try it to see if my bulbs would stop dropping.
I expect the configuration is being saved - I can’t really see how it can’t be saved assuming it’s getting into the binding. However, when the binding starts it reads the configuration from the stick, and updates it so that the configuration you see in the UI is consistent with the stick configuration.
Excellent. That worked, but now I can’t get anything to join.
I’m using the Paper UI, and when I set the “Enable Joining” toggle and save, it just comes back as zigbee_permitjoining=false. And it’s not just the UI, the lightbulbs won’t join.
If you have a spare Hue sensor, then I’d be happy to have a play and see if we can get it working. It shouldn’t (in theory!) be too hard to add although I’ve found configuring Zigbee battery devices a little problematic in the past.
My guess is that ConBee support will be a few weeks off. I had quite a lot of queries regarding the interface which I sent to Dresden on Saturday so it might take a little time to respond. I suspect I’m the first to try and implement an interface with the dongle based on their docs as there are quite a few errors - we’re getting there though and I don’t expect major issues once the interface is working .
I tried everything I could think of, but couldn’t get a channel change to save. Even deleting the coordinator, shutting down, removing it from the jsondb, restarting, and adding it again with the same settings except the channel, it came up with the old channel. I could try hard resetting the controller, but all I’m after is testing the binding . If the channel change is getting saved somewhere, it is definitely not being applied to the controller. These mystery errors from dmesg could be related to this, but I haven’t correlated them to OH yet. The first one happens about every day, and the others I’ve seen maybe twice. The first one may occur with restarts of the binding (ttyUSB1 is the controller):
cp210x ttyUSB1: failed set request 0x7 status: -32
cp210x ttyUSB1: failed set req 0x1e size 4 status: -32
cp210x ttyUSB1: failed to set baud rate to 300
The settings only take effect when you tick the “Reset controller” box. Otherwise when the binding starts it reads the current configuration from the stick, and updates it so that the configuration you see in the UI is consistent with the stick configuration.
Yes - when it restarts it checks the state of this configuration. If it’s true, then it does the reconfiguration, then sets it to false again.
I do agree this logic needs an overhaul. It should restart the thing handler immediately when you select this, but it can be problematic as the interfaces need to be closed and reopened… It’s just not something I’ve put priority on implementing.
I know I’ve done this before, but tried it again. No luck… channel did not change. But I can now correlate the following error to stopping the binding, right before the serial port is closed. @Tetragramm, do you see this too?
dmesg --time-format iso | grep tty
2017-08-03T04:22:28,198655-0400 cp210x ttyUSB1: failed set request 0x7 status: -32
2017-08-03T04:22:28,203748-0400 cp210x ttyUSB1: failed set request 0x7 status: -32
from log
2017-08-03 04:22:28.059 [ZigBeeThingHandler ] - Handler disposes. Unregistering listener.
2017-08-03 04:22:31.984 [BeeCoordinatorEmberHandler] - Serial port [/dev/ttyUSB-55] is closed.
2017-08-03 04:22:31.995 [AshFrameHandler ] - AshFrameHandler IOException:
java.io.IOException
at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1274)[185:com.neuronrobotics.nrjavaserial:3.12.0.OH]
at com.zsmartsystems.zigbee.dongle.ember.ash.AshFrameHandler$1.run(AshFrameHandler.java:151)[10:org.openhab.binding.zigbee:2.2.0.201707291823]
. If there’s some configuration that needs to change outside of this then we could look at it - channel might be a valid need, but anything else WILL need to reset the stick as you can’t change the PAN ids, mac address etc on a running network.
. The EZSP_ENERGY_SCAN in the log shows a better channel than what I’ve selected, so I thought I’d try it to see if my bulbs would stop dropping.
.
. If the channel change is getting saved somewhere, it is definitely not being applied to the controller. These mystery errors from dmesg could be related to this, but I haven’t correlated them to OH yet. The first one happens about every day, and the others I’ve seen maybe twice. The first one may occur with restarts of the binding (ttyUSB1 is the controller):