That’s great news, I picked up a cheap ConBee off eBay a month or so ago.
Hue also have some nice motion detectors which I think are quite popular, I can send you one if it would help.
Thanks
1 Like
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 
.
1 Like
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.
In PaperUI, or set it to true in Habmin. I’ve done both. Does the binding then need a manual restart? Because it isn’t restarting after saving.
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]I will take a look at the way the binding closes the ports. I know that it’s possible for the port to be closed when the threads are still open, and that’s what causes this exception. The exception can happen a few times (max 10) in quick succession, then the thread will exit. However I don’t think that this should impact the binding startup does it?
I count 12 exceptions before ‘AshFrameHandler exception count exceeded’. Startup seems unaffected.
It’s possible to get 12 if some data comes in between the first two exceptions. There’s a counter that allows these to occur (to avoid the thread exiting unnecessarily) and if there’s more than 10 (ie 11) since the last received data, then it exits.
I don’t think it really matters that much - the question you have relates to the binding startup, so as long as the port is closed before it attempts to open it again, it shouldn’t matter (although it should be tidied up, so I will look at this).
I agree… the exceptions and errors from dmesg all seem superficial. Applying config changes is the main issue.
I am trying to setup Linear-HUSBZB-1. I set the baud rate to 57600. I am using the 2.2.0 snapshot as mentioned here. My GE bulbs unfortunately do not pair.
The openhab.log shows
2017-08-14 21:44:36.193 [INFO ] [andler.ZigBeeCoordinatorEmberHandler] - Connecting to serial port [/dev/ttyUSB1]
2017-08-14 21:44:36.501 [INFO ] [andler.ZigBeeCoordinatorEmberHandler] - Serial port [/dev/ttyUSB1] is initialized.
2017-08-14 21:44:36.689 [WARN ] [bee.dongle.ember.ash.AshFrameHandler] - Trying to send when not connected.
2017-08-14 21:44:36.940 [INFO ] [.dashboard.internal.DashboardService] - Started dashboard at http://192.168.1.165:8080
2017-08-14 21:44:36.949 [INFO ] [.dashboard.internal.DashboardService] - Started dashboard at https://192.168.1.165:8443
2017-08-14 21:44:38.026 [INFO ] [basic.internal.servlet.WebAppServlet] - Started Basic UI at /basicui/app
2017-08-14 21:44:38.179 [INFO ] [arthome.ui.paper.internal.PaperUIApp] - Started Paper UI at /paperui
2017-08-14 21:44:38.445 [INFO ] [panel.internal.HABPanelDashboardTile] - Started HABPanel at /habpanel
2017-08-14 21:44:38.655 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - initResponse is JOINED
2017-08-14 21:44:38.655 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - initializeNetwork is false
2017-08-14 21:44:38.753 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Initialise done....... 26 6638 21EC68D7B1CFE4BC
2017-08-14 21:44:38.959 [INFO ] [ui.habmin.internal.servlet.HABminApp] - Started HABmin servlet at /habmin
2017-08-14 21:44:39.244 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - ZigBee Node discovered: IEEE=000D6F000B1317B1, NWK=0000, Type=COORDINATOR
2017-08-14 21:44:48.758 [ERROR] [bee.dongle.ember.ash.AshFrameHandler] - Received a BAD PACKET 11 11 01 47 A1 9C 54 43 16 4A
2017-08-14 21:44:54.456 [DEBUG] [bee.discovery.ZigBeeDiscoveryService] - Starting ZigBee scan for zigbee:coordinator_ember:1c9fcadc
Have you reset the bulbs and started discovery on the Zigbee binding?
For troubleshooting, you should also enable debug logging (looks like you are missing com.zsmartsystems.zigbee). Creating an appender will filter out extra stuff and make the logs easier to read.
@chris, is com.zsmartsystems.zigbee included in the nightly build?
No - the library isn’t rebuilt nightly due to issues handling snapshots. I need to update it after the Ember synchronisation fix you confirmed a couple of days back - I’ll do this tonight.
Chris
I reset the GE bulbs again, and tried to discover them. And this they worked!. I did not have to install com.zsmartsystems.zigbee binding.
This is not a binding - it’s the library that is part of the binding, so is effectively installed for you… (just FYI).
It is included in the Zigbee binding. I was meaning to enable debug logging for it. But if your bulbs are running, then no need!
Another thing, you will want to get the synchronization fix Chris mentioned. Until then, you may notice the binding and bulbs become unresponsive. You’ll need to restart OH to get them responding again.
Also, your bulbs may take a while to come online after a restart. I find power cycling the offline bulbs gets them up quicker. Although, depending on the number of GE Link bulbs you have, you may not notice this.
Can you please point out the post which has the fix.
This one