Zigbee binding

[chris (Chris Jackson)]

@Andrew_Rowe

yeah but… but… I like it this way… don’t change it!!!

Well, if I can get this converter configured to allow user defined settings, then you can set it how you like

@Andrew_Rowe

the option to make it report on every change should/could be a option hopefully?

Hmmm - there’s not really such a thing. There are 3 parameters that configure reporting, and they work together - minimum period, maximum period, and delta.

The device will report at most every “minimum period”. So if it’s changing a lot, this is how fast it will report (it can be set as low as 1 second).

The device will report at least every “maximum period”. So if it never changes, it will send an update at this rate - this is set to something like 2 hours and is used to make sure the device hasn’t gone AWOL.

The device will also report if the value changes by the “delta” since the last report. This is the one that should be set to something sensible IMHO as there is no point really in having updates every fraction of a lux. However, as I said above, this is personal preference, dependant on the use case and the position of the sensor, so if I can make this configurable, then I will.

[Andrew_Rowe]

cool,

@chris

This is the one that should be set to something sensible IMHO as there is no point really in having updates every fraction of a lux.

Agreed, thanks for explaining Chris

[Kim_Andersen]

@Andrew_Rowe

Kim, getting influxdb and Grafana set up and working was not easy for a beginner

I have Influxdb and Grafana running for more than a year But I dont persist the Philips Hue devices.

[Kim_Andersen]

@chris

This issue isn’t so simple to resolve with a single setting in the binding because there is a logarithm in the conversion to lux. The binding currently doesn’t convert the illuminance data correctly - I’ve just fixed this, but given that indoors values range from 0 to (say) 200 with bright lights, and outdoors values go up to (say) 20000 (and if you have your sensor where it can significantly be influenced by the outdoor levels, then indoors can probably go up to 1000), this is difficult to set.

I know changes will occure fast for lux, specially at the time where dimmed ligth/the sun is coming up or going down. But whats toally wrong with this device is, that it reports lux with 10´th of decimals. (ie xxx.yy) I have absolutly no idea who would ever going to use this. And because of this, it sends report quite alot more than it really had to. If we could skipp the decimals for this device, it would be an start.

For the indoor outdoor question… I think there is a need of a thresshold or something simular… I have this Neo Coolcam Z-wave PIR with build in lux sensor. In it´s setting the user can set how much the lux will have to change before sending a report. It´s called “Light sensor polling interval”.
I believe something simular would be usefull for likewise Zigbee devices, if possible.

@chris

but at the moment the system doesn’t account for the calibration, so this may be rather confusing

Calibration can be overruled using a rule in openhab… Ofcouse setting a real calibration value would be the best.

[chris (Chris Jackson)]

@Kim_Andersen

whats toally wrong with this device is, that it reports lux with 10´th of decimals.

No - as I said above the calibration in the binding is incorrect - it’s not converting the data correctly. The way it’s printed is however down to you - the binding sets the default, but you can change this if you want.

@Kim_Andersen

because of this, it sends report quite alot more than it really had to.

The reporting is totally unrelated. I explained above how the reporting works.

@Kim_Andersen

Calibration can be overruled using a rule in openhab

Well, not really. The binding is incorrectly processing the data that is received from the device - so it’s not passing in the data correctly and I don’t think you can really recover from that. It’s a cut and paste error from the temperature converter, but the calculation is completely different in ZigBee.

[Kim_Andersen]

@chris

The way it’s printed is however down to you

@chris

I explained above how the reporting works.

Yes, I see what you mean

For futher use, yes the printing is up to me. But what I mean is, that it reports every changes down to two decimals. This is not something I can do anything about. And the decimals should be avoided cause it makes no sense, in my opinion though.

@chris

Well, not really. The binding is incorrectly processing the data that is received from the device - so it’s not passing in the data correctly and I don’t think you can really recover from that. It’s a cut and paste error from the temperature converter, but the calculation is completely different in ZigBee.

Hmm, okay if the data is wrong an it doesnt follow a correct step, then its not possible to rules a rule for change corrigate the calibration value.

[chris (Chris Jackson)]

@Kim_Andersen

what I mean is, that it reports every changes down to two decimals.

No - this is only a calibration issue. The device is reporting INTEGERS. The reporting is configured by the delta change configuration that I mentioned above -:

@chris

The device will also report if the value changes by the “delta” since the last report. This is the one that should be set to something sensible IMHO as there is no point really in having updates every fraction of a lux. However, as I said above, this is personal preference, dependant on the use case and the position of the sensor, so if I can make this configurable, then I will.

So the frequency of the reports is directly linked to this parameter.

@Kim_Andersen

This is not something I can do anything about.

That’s true at the moment - however as I said above I’m adding the ability to configure these reporting parameters into the binding, then you can configure the reporting as you like.

[Kim_Andersen]

Well, right now whatever changes you make, doesnt really matter. The damn device no longer respond at all. I have tried remove and re-add it a coupple of times without luck. It is beeing discovered and added allright. Also goes online allright, but after that, total silence!
I have just tried removed the device, empty the cache/tmp, rebooted my Odroid, and re-added it again. When it comes online, it updates it values. After that, total silence again.
I have no idea whats going on. But I do have the DEBUG log. Its a log after restarting openhab. Notice the start where there seem to be some errors. I have no idea if its related.

My Hue Dimmer Switch and a Xiaomi Aqara door/window sensor is working fine.

Zigbee.rar.txt (56.7 KB)

[chris (Chris Jackson)]

I’m not sure what devices are what. There are a number of errors showing from the NCP saying it failed to deliver to some devices so that is likely the issue. I don’t know what will have caused this, but it means the issue is down in the network level.

[Kim_Andersen]

0017880102139d00 is the SML001 (Philips Hue motion sensor)…

[chris (Chris Jackson)]

It looks like the link to the device is poor. I see some responses, and some errors at the network layer.

[Kim_Andersen]

hmm, it´s sitting aprox 1.5 meter from the Em357 dongle.
And it worked fine earlier today… Weird!

[chris (Chris Jackson)]

Another possible option is interference from other devices using the frequency?

[Andrew_Rowe]

Really Kim… you are chasing ghosts here
start a new thread

[Kim_Andersen]

@Andrew_Rowe

you are chasing ghosts here

What exactly do you mean by that?

Let us assume, Chris is right. There is network issues maybe interference…
What good would it do to start a new thread? Or should I ask - WHY do a network/interference issue not qualify for questions in the thread of the Zigbee binding?

Let me remind you, network/interferences issues are VERY hard to tell for sure or to fix, unless you can totally isolate 2.4GHz and the channel.
I have isolated the channel the best I can. I can NOT isolate the frequency, cause I cant switch off all 2.4GHz equipment everywhere around my place. (I´ve got neighbors using 2.4GHz. I also got a microwave oven. I got WiFi equipment as well, like probably all others). I´m not really that special! But I know how to deal with wireless networks. I know how to set up using different channels etc. to minimize the chances of interferences… (Maybe thats my main problem - I know!!)).

I´m getting sick and tired of trying to deal with, struggle, finding causes and fixes, and even trying to help reporting issues with Zigbee. And then see someone telling me, I´m chasing ghosts and should start a new thread, because a device which worked and communicated fine a few hours before, suddenly stopped all communication.
It simply makes no sense starting a new thread from that situation

I have been struggling with Zigbee for quite a long time. I even bought a second coordinator to be able to help with sniffing communcation. All because I have a personal interest, and I care for the development! (Chris should be able to confirm that).
I personally dont NEED Zigbee. Its not part of my production system anyway, mainly because it is, and have been totally unreliable all the time. Changing hardware, software and binding doesnt seem to do much differences, except for the worse.

I DO believe all questions/issue/problems/ideas etc. about Zigbee is qualified in this thread, no matter what level and software/binding the user is using. With my experiences, I would say Zigbee needs whatever help it can get! This is a thread regarding all possible stuff about Zigbee. Chris/moderator should correct me, if I´m wrong!

I got to be honest with you… Your comment makes me rather pissed. I find myself spending alot time on Zigbee every time I decide to give it just another try, only to discover things hasn´t changed, and if it has changed, its for the worse. It is/should have been quite simple. It´s not!
I dont consider myself as beeing totally stupid, or a “newbee” in this matter. I´m a human like everyone else which means, I can make mistakes, and even jump to the wrong conclusion as well (as you just saw about the reporting frequency). I dont mind beeing wrong, (thats whats makes me human). I do apologizes when I´m wrong. But I certainly DO mind listening to a stupid suggestions like your comment, knowing I have struggled with this for a very VERY long time…
Enough is enough. I´m done!!

[chris (Chris Jackson)]

@Kim_Andersen

I DO believe all questions/issue/problems/ideas etc. about Zigbee is qualified in this thread, no matter what level and software/binding the user is using.

I do agree, and am happy to answer questions here, however I do think that sometimes it’s best to start a new thread. This thread work fine for the occasional question, but it starts getting messy when multiple people start asking different questions at the same time, and the responses for the different “threads” get interleaved.

The problem is people often ask a “simple” question expecting a simple answer and not intending to get into a big discussion, so I understand it’s difficult to know when asking a question.

I do however think that in general it’s probably better to start a new thread - simply as it’s more likely that people can find things again. This thread has 2250 messages at the moment and has run for 3 years - maybe I should actually just close it?

@Kim_Andersen

What good would it do to start a new thread?

My only real answer here is that it would make it easier to find and reference at a later date. I completely agree that there is nothing really wrong in posting your question here.

@Kim_Andersen

This is a thread regarding all possible stuff about Zigbee. Chris/moderator should correct me, if I´m wrong!

Yes - agreed. As above though, I think it is better for the community to try and split discussions into separate threads, just to make it easier to manage. Taken to its extreme, we could say this whole forum is about openHAB, and therefore we only need one thread where we just discuss everything .

[sesuncedu (Simon Spero)]

@chris

Yes, the 1.2 version of the libraries will not work with openHAB at the moment. This is not a simple maintenance release (hence the version number change) and has a number of breaking changes.

Minor, er, Major note:

If changes are made to version 1.1 of a package that mean that code compiled against version 1.1 won’t work with the new version, the package version number should be changed to the next major revision - e.g. 2.0.0.

Package versions can be picked up by bnd based build tools automatically by adding @Version annotations to package-info.java, and can be checked by adding a baseline task / execution.

[chris (Chris Jackson)]

Yes, but what I said above is how it has been implemented.

[NoneWhereTo (None)]

Hi @chris,

I tried adding an Innr FL 130 C lightstrip. The strip was found by the binding, though the name remains the mac address. Unfortunately the binding can only find a dimmer channel called “level control”. But this one changes nothing when played with.

I’m currently running the 2.5M1 milestone build. Other zigbee devices like Osram plugs & bulbs and Ikea Tradfri bulbs work flawlessly. I just can’t find any color channels on the Innr light strip. Can I add them somehow?

[chris (Chris Jackson)]

You can’t add channels yourself - these need to be added by the binding.

This probably means that there is an issue detecting the device information. I would strongly suggest to use the snapshot version as the M1 binding is quite old and there have been a lot of changes. I would also need to see a debug log during the initialisation to know what is happening.