@chris I have seen that the reason why reporting was not working for me was that the “bindrequest” code was mostly uncomplete… in the snapshot I was using
After some fixing, completing it, and making it work, I just see that you have already done it also, so no point in merging my code Good anyway for me to understand the code and being able to contribute if necessary…
Just one comment, as I have not found it in the current version : as many devices need binding to know where to send the reports to, are you calling bind() by default somewhere else ?
In my fix, I had put this in the ZclCluster setReporting function:
public abstract class ZclCluster {
// ...
protected boolean isBound = false;
// ...
public Future<CommandResult> setReporting(final ZclAttribute attribute, final int minInterval,
final int maxInterval, final Object reportableChange) {
// ...
// Try to bind the device the first time reporting is set for some attribute in the cluster
if(!isBound) try {
bind();
isBound = true;
}
catch(Exception e) {
e.printStackTrace();
logger.debug("bind exception", e);
}
// ...
}
Is this addressed somewhere else or do you think it would be worth putting in here for all devices setreporting work correctly by default even if they need binding ?
The problem with this is it then means the application has no influence on the binding which is wrong. This is an application level choice - not framework (IMO anyway).
I had put the call to bind() in the setReporting method to avoid touching the Zigbee OH binding. But I agree that the right place to call it is, as you say, at the application layer, as even assuming that the binding must be setup whenever reporting is, this binding could be done either against the coordinator or whatever other device.
Will now start moving my bunch of Zigbee devices from my ST hub to the OH. If I see something not working I will let you know (including a proposed fix in the code if I can work it out)
Are you using Ember dongle? I’m not sure that ST motion sensor will join some dongles - this is something I’m looking at at the moment and I’ve hit an issue with the Telegesis dongle with this but I think it can be solved on the Ember firmware…
I’ll also try and get my binding code pushed today so there’s a clean baseline - there are a lot of updates going in at the moment…
I am using a CC2530, at least till my CC2531 arrives…
I have a ST hub, but no other ST devices, so my testing will be focused (by now) on IKEA Tradfri lights and Osram plugs. Ideally, I would like to make Xiamoi Aqara switches joining directly with the Zigbee binding (but these are difficult to make join even in ST)
Will wait till you have the new binding code pushed.
Ok, I might also try and test some changes I’ve made to see if it helps the ST motion sensors.
I’ve tested both of these (I’ve just received 3 more Osram bulbs today and I think they will all be different - will see what they are soon…). I know some older Tradfri bulbs have issues with color at the moment. I have ideas on solving this so if you hit this issue, we can discuss further.
Sorry - I missed this post. I don’t suppose you would want to sell it to me or swap it with a new bulb? I’d be keen to get my hands on one of the old bulbs to test out some code - there are two things I want to test with this, but I’ve not been able to find a bulb… We did do some testing at the SmartHome day, but when I checked the logs it didn’t have the information I needed.
I’ve pushed some changes to the ZigBee binding - this is quite a large update of the binding and more importantly, the ZigBee library. It adds a lot of features, and of course may break something so comments appreciated
Main changes -:
Added the Telegesis dongle
Added firmware update functionality for Telegesis dongle
Added binding commands into the converters so there should be updates sent to the binding
Possibly improve the discovery of devices when the binding restarts
Lots of minor changes to the library…
Note that I suspect the binding commands may be causing some interesting behaviour in the UI and parameters might need tuning to make this work a bit better. I’ve noticed that when changing a dimmer for example, the slider moves to the position you want, then moves back and then up again - I think this is probably related to this change and I’ll take a better look at this.
The discovery changes are experimental at the moment - I added a new feature to the library to search for devices that were previously associated, but are now not seen. This seems to solve some problems that I could reproduce, but I’d appreciate feedback on this (@5iver I think you were having this issue with having to power cycle bulbs after the binding was restarted - I’d be interested to know if there’s any change in this).
I hope that the general source will start to stabilise - there are a few big changes coming though that will impact the binding a little, but I hope to start to tidy the binding side up a little now .The main “big feature” that’s in the pipeline is OTA firmware updates - this is integrated into the library now but I still need to update the thing handler to support this in the binding.
Yes - it will work through PaperUI - but probably not right now as there are some elements missing. The system needs a FirmwareProvider to actually provide the binary files and currently there is no such provider. For my testing I wrote a simple provider to provide the firmware, but this is not suitable for release.
When this is available, then PaperUI will show the current firmware, and any other images that are available, and you can choose to update.
I was just curious… I’ve seen “NO Changes” for months. But at least now the jar has changes in it! After stopping the binding, copying in the new version, and starting the binding, all of my devices came up as online in Habmin, but I was getting this for all of them (previously reported and possibly related to ESH issue 4591…
2017-11-21 04:23:47.310 [WARN ] [e.core.thing.internal.profiles.ProfileCallbackImpl] - Cannot delegate command 'OFF' for item 'DS_FurnaceRoom_Bulb' to handler for channel 'zigbee:device:9b51c72d:7ce524000012cc42:7CE524000012CC42_1_switch_level', because no handler is assigned. Maybe the binding is not installed or not propertly initialized.
After an OH reboot, all Zigbee devices came up as online in Habmin and this error did not come up after toggling all of them. This is a HUGE improvement for the GE Link bulbs… thank you!
There is a lot of logging going on in DEBUG, which is understandable. It looks like discovery might be continuously running. At one point, you had limited this, but maybe you’ve put it back in? Maybe I just haven’t waited long enough for things to settle. I also see quite a lot of Sent queue larger than window [1 > 1].… is that expected?
I’ve noted the odd UI behavior, not only when dimming but also when toggling switches. I’m sure you’re aware of this, but thought I’d mention it for others.
Would new channels just show up for devices, or would the Things need to be deleted and rediscovered? Specifically, I’m hoping for power monitoring in the CentraLite/ST outlet. I also have a CentralLite remote (sitting in a draw w/o batteries) that I could test, if there were any clusters added that it uses (currently only has temperature).
As you know, the build was broken for months. I submitted the PR to fix this maybe 6 weeks ago and I think it was merged last week. I’ve now tidied up the repo to merge all the changes back in so this is the first build since the build was fixed…
I don’t know exactly what cloudbees uses for it’s list of changes so I’m not sure how accurate it is.
I don’t think it’s discovery is it? It’s probably the mesh update which is different. I think it’s set to 60 or 90 seconds at the moment (I might make this configurable, but for now it’s included in the binding so that data gets updated).
Yes, of course it is related to all channels but I used dimmer as an example.
New channels should just show up - no need to delete etc…
This is not supported right now, but I might add it soon.
I don’t know what it uses so hard to comment. I’ll likely add an XML dump of the network shortly so I can get some of this information (similar-ish to ZWave, but all in one file).
I always get these confused… It’s mesh updates. That explains the amount of logging I’m seeing. Can you comment on Sent queue larger than window [1 > 1].… what does it mean, especially if frequent at times?
It’s a CentraLite 3400-X Keypad. All I know about it is from a ST device handler. Having a list of clusters supported by the binding will be very helpful.
The bundles build is aggregating all openHAB 2 bundles from the different repos by using git sub-modules.
Unfortunately Jenkins is not able to retrieve the changelog from sub-modules. There is a critical issue open since 2010 in the Jenkins issue tracker about it
It means that the ASH layer is trying to send a frame when it’s not allowed to. I’m not sure what would cause this but could take a look at the log if you want to send it (maybe say 20 seconds of logging prior to the logged event would be fine).
Really I prefer to speak of channels as it can get messy just talking about clusters as there’s often different functions defined in a cluster. I’ll try and add something to the readme though…
What I’d like to see is a documentation system that linked the XML file to docs - something was started a while back, but it was never completed…
So just to be clear - the issue you had previously with having to power cycle bulbs, or even remove and re-associate them is now solved (at least following this short test)? If so, I’d be happy with that as it’s something I spent some time on yesterday and I’d love to see if gone .
Correct… no power-cycling, discoveries or resetting needed to get any of them online. And no errors. That’s never happened before! I’ll try to get another restart in later today.
.
.