Setting up Qivicon Stick with Zigbee Binding on Raspberry Pi with openHABian

I had problems with setting the Qivicon Stick up on my Raspberry Pi.

I plugged it in and installed the binding but it did not seem to get recognized properly.

I made sure the privileges were set appropirate according to this:

Since it still did not work I tried echo 10c4 89fb > /sys/bus/usb-serial/drivers/cp210x/new_id as desribed on the GitHub repo. Don’t know whether that is necessary, though. It did not work anyways. I had to enable the CP210X driver with sudo modprobe cp210x. Afterwards echo 10c4 89fb > /sys/bus/usb-serial/drivers/cp210x/new_id worked but had to be executed as root. Now the device is available under ttyUSB0 and was recognized by the binding at this location.

The problem now is that a Tradfri bulb from IKEA is not detected on PaperUI with this binding.

The questions are:

  • Are the described steps necessary to make the stick work properly? I thought it would run pretty much straight out of the box. I also read something about resetting the stick, might this be the problem here?
  • Do you have any clue why the Tradfri bulb does not show up on PaperUI?

Generally, yes they are required.

No - this device has customer PID/VIDs so it requires the above steps (unless maybe your OS has been updated).

Really there is very little information to go on. If the stick isn’t working, then a bulb will not join. If the stick is working, then it’s really hard to know what is up without a debug logfile.

Alright. Maybe the documentation can be updated and mention those steps to make setup easier. Also I think that the modprobe command has to be done every time after boot or a script/cronjob has to be set up to enable it automatically after boot. Is there a way to avoid this and do this automatically on binding installation? Having to set up scripts or cronjobs makes this binding not very easy to use.

I will try to create one with more information.

What steps need to be added? :confounded: Isn’t this already in the documentation?

It’s not really a binding issue - the problem is with this specific stick which is more difficult to use due to Qivicon trying to lock it down. Personally, I don’t really recommend this stick for exactly this reason, but I don’t think you can really blame the binding for what DT have done.

I have not found anything about modprobe commands, setting up scripts to automatically enable the driver at boot and also think that the echo command is not in the openHAB binding doc, only on the GitHub repo.

Alright, did not know that and it is not documented. Maybe that can be added as well.

I don’t know what this is? You never mentioned this in your first post when you said things should be added to the docs. The docs say how to add this device, but if there are things missing, then please do add them.

What github repo? The ZigBee binding README file in Github is the binding docs - it’s exaclty the same file. Or do you talk about something else on github?

I’m not going to add my personal recommendations to the official documentation. Many people use this device - it should work fine, so my personal preference isn’t really something that should go in official documentation.

I am referring to this:

I am talking about and those have different information, both don’t mention the modprobe command. So I thought it is probably not needed and there is something else wrong with my setup.

That is not that much about personal preference but more about adding information of a more complex setup.

In the meantime I managed to get the Tradfri bulb discovered, at least I think so. Unfortunately there are also problems. Log output:

2019-09-24 17:05:33.680 [INFO ] [bee.discovery.ZigBeeDiscoveryService] - 90FD9FFFFED5BC1E: Starting ZigBee device discovery

2019-09-24 17:05:33.684 [DEBUG] [bee.discovery.ZigBeeDiscoveryService] - 90FD9FFFFED5BC1E: Creating ZigBee device zigbee:device with bridge zigbee:coordinator_telegesis:9d698301

2019-09-24 17:05:33.691 [DEBUG] [bee.discovery.ZigBeeDiscoveryService] - 90FD9FFFFED5BC1E: Node discovery not complete

2019-09-24 17:05:52.546 [me.event.InboxRemovedEvent] - Discovery Result with UID 'zigbee:device:9d698301:90fd9ffffed5bc1e' has been removed.

2019-09-24 17:05:52.589 [DEBUG] [org.openhab.binding.zigbee          ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.core.ConfigDescriptionProvider}={, service.bundleid=248, service.scope=singleton} - org.openhab.binding.zigbee

2019-09-24 17:05:52.609 [DEBUG] [org.openhab.binding.zigbee          ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.core.thing.type.DynamicStateDescriptionProvider}={, service.bundleid=248, service.scope=singleton} - org.openhab.binding.zigbee

2019-09-24 17:05:52.630 [DEBUG] [org.openhab.binding.zigbee          ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.core.thing.binding.firmware.FirmwareUpdateHandler}={, service.bundleid=248, service.scope=singleton} - org.openhab.binding.zigbee

2019-09-24 17:05:52.640 [hingStatusInfoChangedEvent] - 'zigbee:device:9d698301:90fd9ffffed5bc1e' changed from UNINITIALIZED to INITIALIZING

2019-09-24 17:05:52.641 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 90FD9FFFFED5BC1E: Initializing ZigBee thing handler zigbee:device:9d698301:90fd9ffffed5bc1e

2019-09-24 17:05:52.648 [hingStatusInfoChangedEvent] - 'zigbee:device:9d698301:90fd9ffffed5bc1e' changed from INITIALIZING to UNKNOWN

2019-09-24 17:05:52.648 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 90FD9FFFFED5BC1E: Coordinator status changed to ONLINE.

2019-09-24 17:05:52.651 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 90FD9FFFFED5BC1E: Coordinator is ONLINE. Starting device initialisation.

2019-09-24 17:05:52.676 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 90FD9FFFFED5BC1E: Node has not finished discovery

2019-09-24 17:05:52.690 [hingStatusInfoChangedEvent] - 'zigbee:device:9d698301:90fd9ffffed5bc1e' changed from UNKNOWN to OFFLINE: Node has not completed discovery

2019-09-24 17:05:52.817 [nt.FirmwareStatusInfoEvent] - Firmware status of thing zigbee:device:9d698301:90fd9ffffed5bc1e changed to UNKNOWN.

2019-09-24 17:08:01.184 [DEBUG] [nal.ZigBeeNetworkStateSerializerImpl] - Saving ZigBee network state: Start.

2019-09-24 17:08:01.191 [me.event.ThingUpdatedEvent] - Thing 'zigbee:coordinator_telegesis:9d698301' has been updated.

2019-09-24 17:08:01.223 [DEBUG] [nal.ZigBeeNetworkStateSerializerImpl] - Saving ZigBee network state: Done.

2019-09-24 17:12:59.591 [me.event.ThingUpdatedEvent] - Thing 'zigbee:coordinator_telegesis:9d698301' has been updated.

2019-09-24 17:12:59.589 [DEBUG] [nal.ZigBeeNetworkStateSerializerImpl] - Saving ZigBee network state: Start.

2019-09-24 17:12:59.632 [DEBUG] [nal.ZigBeeNetworkStateSerializerImpl] - Saving ZigBee network state: Done.

I disagree - this was a personal preference as to which device I prefer, but of course if you want to improve the documentation it would be appreciated.

I was involved helping @Philip_J to get this stick to run, unfortunately we had to do some additional steps as described in the first post that were not documented. So we were wondering whether those additional steps are needed or whether we had some other problem with the setup and only what is already documented is needed.

We were rather talking about those (maybe not needed) additional steps for that device, which makes it harder to set it up. Adding that to the documentation would help others knowing that this particular stick is harder to use.

I want to, indeed. However, first I wanted to make sure that those additional, currently undocumented steps are really needed. Maybe we also made mistakes when setting it up and figured some unusual workaround that works, but is not the correct way to go. So I’d like to ask for some additional details before adding something that might be wrong to the documentation.

After some digging I also found the thread where I have asked about the Qivicon stick and you told that on Linux there should not be additional steps needed (that made me think we were doing something wrong):

The following quote seems to only apply to Windows and Mac, so Linux should be fine probably:

Also ping to some users, who apparently got the stick to work on their devices:

@algo4711, @PresidentDoener, @mwick83, @gck303

Ok, but I was responding to the fact that I said that “personally, I don’t recommend this stick” - I will not document this in official documentation.

It is hard for me to document everything for every system and every stick. I personally use the Silabs chipsets, and most of the people I support commercially are using this. However, I can’t really help with every stick that is out there that someone might use as I don’t have them. I also don’t know all the different operating systems that people might use. I’m sorry I can’t help more, but the reality is that sometimes others also need to help here!

Ok, so probably some misunderstanding. I never wanted to document that you personally don’t recommend this stick, but always was talking about documenting the reasons for that.

No problem. I can also add a PR after I figured out how this should be set up ideally.

Understood, no problem. I thought you had some more info based on what you were replying in the other thread where I asked about the Qivion Stick and a Raspberry Pi and got the reply that it should work pretty much straight away without further actions needed.

So let’s hope some of the other users having this Stick running can shed some more light on this.

@clel I do not use the Qivicon stick anymore, I switched to the CC2531 which could be setup easily

@algo4711 Thanks for getting back to me. Have you had similar problems using the Qivicon stick? Or did it rather work straight out of the box for you?