Zigbee binding

zigbee
beginners
Tags: #<Tag:0x00007f014c60a2a8> #<Tag:0x00007f014c609dd0>

(Kim Andersen) #1445

Which files Chris?? The two zsmartsystems ??


(Chris Jackson) #1446

Yes - you should remove all manually installed files and just install using PaperUI.


(Kim Andersen) #1447

Hmm… wouldn´t that bring me back to 2.3.0 stable ??


(Chris Jackson) #1448

Are you running 2.3 stable? I thought you were on the snapshot version? If you are using 2.3, then yes, you will need to install everything manually.


(Kim Andersen) #1449

Yeah stil on openhab 2.3.0 stable. But I manually installed the zigbee binding in August to 2.4.0 snapshot… Now I´m trying to updating this to the latest snapshot.
So I need both zsmartsystems files as well?


(Chris Jackson) #1450

Yes.


(Kim Andersen) #1451

Arrgh…
cant seem to find those two zsmartsystem files . I´ll never get used to Cloudbees :frowning:


(Chris Jackson) #1452

They aren’t on cloudbees. Use the update script from @5iver. Alternatively, just stick with the current version, or change to the snapshot version (or 2.4 M4).


(dbadia) #1453

My versions are a few days old not sure how to tell if they are the latest or not

259 x Active   x  80 x 2.4.0.201810010846     x org.openhab.binding.zigbee	
250 x Active   x  80 x 2.4.0.201810010846     x org.openhab.binding.zigbee.cc2531
251 x Active   x  80 x 2.4.0.201810010846     x org.openhab.binding.zigbee.ember

I uninstalled and reinstalled the zigbee binding via PaperUI, but it loaded the same version before vs after.

My OH build is 2.4 snapshot, just a little before M4 was released. I can upgrade that to M4 if you think it would help?


(Chris Jackson) #1454

Can you check the versions of the libraries as well please? These need to be updated, and unless the runtime is updated, they will likely be old (needs to be 1.1.2).


(Kim Andersen) #1455

Got the latest bindings as well as libs installed now, with great help from @5iver and his great script…

The good Stuff:
My Ember coordinator as well as my devices are up running.
All devices were discovered in first go, and very fast as well. I have set the Ember coordinator to use High Power as well Boost… I have no idea if thats the reason for the quick discovery.

The bad stuff:
The Trust motion sensor no longer has a BatteryLevel channel
It still doesn´t release the trigger.
It´s Intrusion channel still doesn´t seem to do anything.

The Philips Hue motion sensor no longer have the Battery Voltage channel.
It´s switch on/off channel is gone. But it probably didn´t do anything after all. So this may be good stuff :slight_smile:

While writing this, (and keeping an eye on the tail log).
The trust motion sensor went offline, as well as the Philips Hue Dimmer Switch. My Osram Plug claim it´s online, but it does no longer respond when switching.
It seems like the Ember coordinator stopped updating as well. I have not seen any updates in the last 20 minutes aprox. I cant really figure if thats the reason why the devices stop working, or if they stop working due to the coordinator no longer updates. There seem to be a connection with this…

I´ll reboot my Rpi tomorrow, and if they dont return to work, I´ll try some debug logging.


(Chris Jackson) #1456

Nothing has changed, so probably there was an issue communicating with the device

I have not looked at this.

That is not uncommon. The binding will provide all “channels” that the device says it can support. Unfortunately, for a motion sensor, this is always 2 channels and most of the time the second one does not do anything.

Again, nothing has changed so this is likely caused by communications issues.


(Kim Andersen) #1457

I know, you mentioned that before. And I agree, this channel might be just an unused one…
But how does a user tell? (continue read below).

Regarding these communication issues…
It´s rather unreliable. If a device can be added with success, and seems to be working, but is missing channels… How would a user ever be able to tell? In the above situations, I wouldn´t have known, if I havn´t had them added before and knew about these channels.
I would rather have an error, telling me the device did not success. But maybe thats not possible?


(Chris Jackson) #1458

They can’t - again, the binding is just presenting the capabilities that the device reports. This is an automated process - the same as with ZWave, and users will need to have a play to see what does what. In most cases, it will be very obvious - for more exotic devices, there will be some differences that need to be considered by the user.

We can also define devices statically, which allows devices to be specifically designed. However, I’m not in favour of doing this too much as it is a lot of work to maintain (as we see in ZWave).


(Kim Andersen) #1459

Which lead me to this quote…

Communication issues, without notifying… In this case, it´s a missing batterylevel channel…
How to “play to see what it does”, when a channel is missing?
If I didn´t knew, I would probably have thought, this device don´t have a batterylevel channel. And probably not even have mentioned it.

I understand and agree with your concern for the same work as with z-wave. But if a devices can be added with success, yet missing an rather important channel. The “play to see what it does” dont seem like a good advice, in my opinion.
It´s a lot worse missing channels, than getting “unused” channels.
It´s a disaster not knowing, if or when a channel is missing from a device which has been added with success, unless it´s a obvious channel missing ofcouse.
I would say this could lead to alot of frustrations, “work” and trouble shooting as well.

(I need to learn how to get openhab to filter and log into seperate files, so I can start debug logging. Perhaps it could show something).


(Chris Jackson) #1460

If you run in debug mode, you will have all the notifications. This is a tough issue as if there are comms failures, what do you suggest? The binding can’t really show what it doesn’t know.

Why? The binding presents the data that a device provides - you need to work out what it does - surely? I can’t continue to purchase devices to support everything - I have already spend thousands of pounds to support people by purchasing devices for testing etc - there is a limit I’m afraid and there are too many devices in this world for me to purchase them all to add the support that you are asking for.

There is a move to try and improve the tolerance to these sort of issues, and I apologise that you are unhappy but these things do take time. There are other things to work on other than just your issues and I already spend a LOT of time each week working on openHAB.

Yes - please do try as it would help. It would be very much appreciated.


(Antonio Jose) #1461

I have added one zigbee device but I can only see 2 channel (batery level and batery percentage missing). Is there any way to look for these two missing channels?. I have tried excluding and including this device some times but still doesn’t find them.


(Chris Jackson) #1462

It may be that the device doesn’t have these - or they are supported in a way that the binding doesn’t know. Can you provide a debug log, and also tell me what the device actually is? The XML from {userdata}/zigbee may also be useful here as it should say what clusters the device supports.


(Kim Andersen) #1463

I´m not suggesting anything, as I dont have the knowledge. I´m wondering, and trying to understand how to deal with it in some way.

I´m not suggesting you should purchase all kinds of devices…
I was kinda hoping there would be some kind of check in the communication specially to avoid the issue with missing channels… I guess there isn´t, or perhaps there is in the debug logging. Time will tell. (Just need to figure out, how the heck these seperate logfiles is done).
You shouldn´t be doing this alone. We should all provide informations somehow. But I cant provide informations, if it isnt realiable… I hope you understand that. Then I can only provide feed backs from my experiences.

I know Chris. But I fear you misunderstand.
I wasnt trying to be harsh or stressing you. My informations is meant to be feed-backs, not complaints. I know you have others things to do as well.
I doubt I´m the only one experience these issues though. But if I´m the only one, I´ll accept and try to find the reason why, somehow.

As I have mentioned before. I want to participating in getting this to work, because I care. Not because of my own system build, (it´s a test build, not a live system regarding the Zigbee devices. So I dont mind destroying it every day, if I have to). I care in general, cause I believe what I experience, others could experience as well. If I dont provide feed back, there really isn´t any point in trying to get anything changed or fixed.

I will… I just have to read the docs for god knows how many times now, or get some help from the community in this matter.


(Scott Rushworth) #1464

Here’s an example for putting the logs into separate files. Modify your org.ops4j.pax.logging.cfg file. Mine is in /opt/openhab2/userdata/etc/ (manual OH install). You will need to change the paths (I’m sending zwave logs to an external archive directory). And I think the rolling appender is broken (you’ll get more than the max) due to the name formatting I’m using.

# ZWave
log4j2.logger.ZWave.name = org.openhab.binding.zwave
log4j2.logger.ZWave.level = WARN
log4j2.logger.ZWave.additivity = false
log4j2.logger.ZWave.appenderRefs = ZWave
log4j2.logger.ZWave.appenderRef.ZWave.ref = ZWAVE

# Zigbee
log4j2.logger.ZSmart.name = com.zsmartsystems.zigbee
log4j2.logger.ZSmart.level = WARN
log4j2.logger.ZSmart.additivity = false
log4j2.logger.ZSmart.appenderRefs = ZSmart
log4j2.logger.ZSmart.appenderRef.ZSmart.ref = ZIGBEE

log4j2.logger.Zigbee.name = org.openhab.binding.zigbee
log4j2.logger.Zigbee.level = WARN
log4j2.logger.Zigbee.additivity = false
log4j2.logger.Zigbee.appenderRefs = Zigbee
log4j2.logger.Zigbee.appenderRef.Zigbee.ref = ZIGBEE

# Zigbee
log4j2.appender.Zigbee.name = ZIGBEE
log4j2.appender.Zigbee.type = RollingRandomAccessFile
log4j2.appender.Zigbee.fileName = /opt/openhab2/userdata/logs/zigbee/zigbee.log
log4j2.appender.Zigbee.filePattern = /opt/openhab2/userdata/logs/zigbee/zigbee.log.%d{yyyyMMddHHmmss}
log4j2.appender.Zigbee.immediateFlush = true
log4j2.appender.Zigbee.append = true
log4j2.appender.Zigbee.layout.type = PatternLayout
log4j2.appender.Zigbee.layout.pattern = %d{yyyy-MM-dd HH:mm:ss.SSS} [%-5.5p] [%c] - %m%n
log4j2.appender.Zigbee.policies.type = Policies
log4j2.appender.Zigbee.policies.size.type = SizeBasedTriggeringPolicy
log4j2.appender.Zigbee.policies.size.size = 10MB
log4j2.appender.Zigbee.strategy.type = DefaultRolloverStrategy
log4j2.appender.Zigbee.strategy.max = 10

# Rules
log4j2.appender.Rules.name = RULES
log4j2.appender.Rules.type = RollingRandomAccessFile
log4j2.appender.Rules.fileName = /opt/openhab2/userdata/logs/rules/rules.log
log4j2.appender.Rules.filePattern = /opt/openhab2/userdata/logs/rules/rules.log.%d{yyyyMMddHHmmss}
log4j2.appender.Rules.immediateFlush = true
log4j2.appender.Rules.append = true
log4j2.appender.Rules.layout.type = PatternLayout
log4j2.appender.Rules.layout.pattern = %d{yyyy-MM-dd HH:mm:ss.SSS} [%-5.5p] [%c] - %m%n
log4j2.appender.Rules.policies.type = Policies
log4j2.appender.Rules.policies.size.type = SizeBasedTriggeringPolicy
log4j2.appender.Rules.policies.size.size = 10MB
log4j2.appender.Rules.strategy.type = DefaultRolloverStrategy
log4j2.appender.Rules.strategy.max = 10