Connect HUE bridge to deConz ?

[donnib]

Hi, As we discussed in https://github.com/dresden-elektronik/deconz-rest-plugin/issues/71 i'd like to use my Philips Iris light, is there a smart way to connect the Hue bridge to the deConz and gain something or should i just connect the Philips gateway in a normal way ? Also is there a downside of having two gateways on the network ? I plan only to have this light on the gateway and all Philips HUE lamps connected to the deConz.

@ebaauw maybe you have an idea ?

/donnib

[posixx]

In response to this question i also want to know; i 'm going to add a second raspbee GW to my network as some hue Taps are not in reach of my current gateway. Preparing for this i red the raspbee/deCONZ can also run in router mode. Should i use that for the lights / switches which are too distant from the current coordinator? Or should i create a new network making it a 2nd coordinator? In other words; can a router recieve Hue Tap button requests and control lights on the network? Or what does a router do?

[ebaauw]

I ran my RaspBee as router in the network created by my Hue bridge for a couple of weeks (or was it months), before deCONZ supported the Hue motion sensors and Hue dimmer switch. That worked brilliantly.
However, once sensors come into play, the two compete for bindings for attribute reporting and commands. More recently, I "accidentally" setup the ConBee as router on my RaspBee network and it broke the functionality of the sensors - you'd never know which *Bee would receive which notification.

is there a smart way to connect the Hue bridge to the deConz

In the Hue forum there was a suggestion that in the early days (way before my time there, which is close to three years now) it was possible to setup a Hue bridge as ZigBee router on a network created by another Hue bridge. If that was indeed possible, the knowledge on how to do that has been lost.

some hue Taps are not in reach of my current gateway

That shouldn't be a problem in a mesh network. The Hue tap should link to the nearest light that supports ZGP. All Hue lights do, as does my ubysis dimmer, but my OSRAM, innr, and IKEA lights don't. Not all lights are created equal... see https://github.com/ebaauw/homebridge-hue/wiki/ZigBee-Devices.

Or should i create a new network making it a 2nd coordinator?

Make sure to use a different ZigBee channel in that case. Also, the devices connected to one network cannot communicate with the devices in the other. Most Hue apps support only one gateway connection at the time, but homebridge-hue will connect to multiple gateways/bridges simultaneously, allowing you to integrate the devices from both bridges/gateways in HomeKit.

Or what does a router do?

In ZigBee terms, it's forms the mesh network, forwarding requests from nodes (e.g. a sensor) to other nodes (e.g. the gateway) that are out of reach of the sending node. Basically every mains powered ZigBee device is a router. I suppose you could use a second RaspBee for that, if you disable/remove the REST API plugin. Seems a bit of a waste to use a good RaspBee and Raspberry Pi just for that. It's much cheaper to install a couple of dimmable lights supporting ZGP to bridge the distance. You could also condider hiding a ubisys router behind a wall switch somewhere, but these don't come cheap either.

[snozzlebert]

That shouldn't be a problem in a mesh network. The Hue tap should link to the nearest light that supports ZGP.

For some old Hue lights you need at firmware update. From the Hue changelog:

Dec 3, 2014 Software version: 66013452 Related products are hue A19 and BR30 downlight bulbs and Friends of hue: LightStrips and Living Colors (Bloom, Iris and Aura) hue Tap range is extended if lamp in between Tap and bridge is powered

[posixx]

hmm strange I have 4 Hue Color lights (LCT001) connected through the gateway, running 5.23.1.13452. The Tap for controlling these sit's in front of them, about 2 meters max. But none of the buttons react. If i walk inside my house the tap buttons start to work.

I registered the tap inside the house before i went outside, should that make any difference?

[alexsporn]

In the Hue forum there was a suggestion that in the early days (way before my time there, which is close to three years now) it was possible to setup a Hue bridge as ZigBee router on a network created by another Hue bridge. If that was indeed possible, the knowledge on how to do that has been lost.

@ebaauw I was already a Hue user at that time and I looked it up recently so it was still in my browser history. I have yet to try it out. From what I read it worked with the round v1 bridges but it is not confirmed to work with the new rectangular v2 ones. https://web.archive.org/web/20150907182635/http://www.everyhue.com/vanilla/discussion/300/bridge-as-zigbee-repeater

[ebaauw]

Cool, thanks @alexsporn!

It looks like they used the old Living Colors remote to (sort of) touchlink (avant la lettre) the second bridge to the network by the first bridge. Unfortunately I don't have any such remote, so my two old gen1 bridges remain useless...

[ebaauw]

hmm strange I have 4 Hue Color lights (LCT001) connected through the gateway, running 5.23.1.13452.

According to the documentation, these are the 1st-gen A19 bulbs. They're Extended color lights (also supportingct). I have some 2nd-gen A19 bulbs (LCT007) on 5.50.1.19085. I never understood the Philips firmware version numbers (sometimes with sometimes without dots), but my guess is you could be on rather old firmware. How long since you last hooked them up to a Hue bridge?

If you check in de deCONZ GUI, you can easily see whether a light supports ZGP: the Philips light on the left does (0xF2 endpoint with 0x0021 clusters); the ORSAM to the right doesn't.

[snozzlebert]

I've 3 Hue 1st-gen A19 (LCT001, December 2012) on firmware 5.23.1.13452. This is the latest firmware for this bulb. I had a firmware update once. I think it was the "66013452" from the changelog. Don't know what Philips means by 66013452, but at least the last 5 digits are the same as the "swversion". I've no problems with my Hue Tap, but maybe it is still in range my ConBee (3 walls, 12 meter?).

[posixx]

The lamp on the left (Tuinhuis 1) is one of the 4 lights located within range of the Tap. So it should work?

[ebaauw]

Yes. You might want to try and reset the Hue tap in your tuinhuis. Open the ZigBee network and press and hold the button corresponding to the channel for 10s. Button 1 for channel 11, 2 for 15, 3 for 20, and 4 for 25. And check that the tuinhuis lights are reachable.

[posixx]

Tried with 2 Taps (one old and one new out-of-the-box) but i cannot get them registered. I will install another gateway in the tuinhuis creating a new zigbee network. Currenly the lamps located in tuinhuis work, but sometimes skip a command i guess because of the distance between my house and tuinhuis. I think a new gateway is the best option

[posixx]

I have temporarily moved my raspbee gateway to another area and one of the taps working earlier stopped working. So i'm not convinced Hue Taps use the mesh network for signalling. This was inside my house with over 60 lamps mostly hue white ambiance GU10 so 'meshing' the buttonpress shouldn't be any problem:

Are there any options in recovering/retrieving the signal path of these Tap devices?

[wvuyk]

The taps are not visible in the intrface, but here I do see also the motion sensor as well as the dimmer switch. I have 5 motion sensors and one dimmer switch. All sensors seem not to mesh in the deConz overview. That would make the sensors quite dependant on their connected neighbour?

[ebaauw]

All sensors seem not to mesh in the deConz overview.

Only ZigBee routers (read: mains powered devices) form the mesh network. End-devices (read: battery powered) only connect to one router. The Hue tap, or other ZGP devices aren't visible in the deCONZ GUI.

That would make the sensors quite dependant on their connected neighbour?

In case the neighbour is unavailable, they blink red and find another neighbour.

Are there any options in recovering/retrieving the signal path of these Tap devices?

I did some sniffing on my deCONZ network while pressing a Hue tap button. On each button press I see up to three ZGP broadcast messages, from the tap's mac address to 0xffff on PAN 0xffff. The command depends on the button pressed; the command code in decimal is in fact the value for buttonevent (hence those odd values).

So i'm not convinced Hue Taps use the mesh network for signalling.

The Hue tap is fairly dumb, looking at the sniffing log: it doesn't "use" anything; it just broadcasts (in retrospect, my earlier suggestion to try and pair the tap in your tuinhuis is bullshit). The intelligence should come from ZigBee routers acting as ZGP proxies.
I vaguely remember reading somewhere that ZGP proxies who receive a ZGP broadcast should re-transmit that into a unicast message to the ZGP sink (which would be the RaspBee or Hue bridge). However, I haven't seen any such messages, which is consistent with your observations.

I also vaguely remember reading that a ZGP proxy needs to be configured for the ZGP sink (i.c. the gateway). In the capture log I made the other day when pairing the Hue light to the Hue bridge, I see three regular broadcast messages (on the PAN of the Hue bridge network) to endpoint 0xf2, cluster 0x0021, profile 0xa1e0 (ZGP) and ZCL command 0x02, GP Proxy commissioning mode, when opening the network (i.c. pressing the link button). But nothing specific configuring the light. Then again, I didn't have a Hue tap connected at that time.

I'll see if I can find some time to capture the setup of the Hue bridge with two Hue lights and a Hue tap and then pressing some tap buttons.

[manup]

The ZGP devices are indeed very simple since they tend to run on very low energy requirements. The ZGP proxy functionality is to my knowledge available in Philips hue bulbs and ubisys devices. I have no experience if or how they need to be configured to re-transmit ZGP commands. So either sniffing or study of the ZGP specification need to be done. Beside the Hue Tap and Lagrange switches there are no ZGP devices available yet, which resulted in not the highest priority from our side. Volunteers welcome :)

[posixx]

@ebaauw: that would be awesome. Hopefully this is resolved quickly so I can reliably use my 5 tap devices. If I can test or help something / somewhere let me know!

[ebaauw]

I vaguely remember reading somewhere

http://www.zigbee.org/zigbee-for-developers/network-specifications/zigbeepro/

[posixx]

A quick update which doesn't address the Tap proxy but solves my poor connection to the Tuinhuis lights; i have added a lightstrip to my Tuinhuis as these devices did have the strongest connections inside the house. Now i have solid green lines to this Lightstrip from multiple lights in the house. So the Philips LightStrip 2 is a strong routing device!

[ebaauw]

So the Philips LightStrip 2 is a strong routing device!

Yes, but I doubt it would be stronger than the Hue bulbs. It could also be related to your physical setup. It's been suggested that placing the bulbs in metal enclosures might hinder (somewhat) the ZigBee radio signal (Faraday cage). The control box for the lightstrip is made of plastic and probably in plain (radio wave) sight.

[posixx]

Ah i guess that's the reason indeed; the e27 lights are located inside armatures made of steel.

Did you find some time sniffing for the tap proxy messages?

[ebaauw]

Some, but then the postman rang and delivered some new toys from China ;-)

Even with only the Hue tap and one IKEA bulb connected to the Hue bridge, the bridge retransmits the ZGP broadcast from the Hue tap as a ZCL GP Notification (what I would expect, reading the ZGP documentation). The source address of that broadcast is a new NWK address, that matches the last two bytes of the tap's mac address. I assume the ZGP proxy bit of the bridge uses that as a proxy address for the tap.

Upon opening the network, the Hue bridge broadcast a ZCL GP Proxy Commissioning Mode command, apparently to tell any ZGP proxies to accept commissioning requests, before broadcasting the ZDP Permit Join Request. Then, I see a ZGP Commissioning broadcast from the tap, followed by the ZCL GP commissioning notification from the proxy, followed by a ZDP Device announcement by the proxy. Then the bridge (from its own NWK address) broadcasts a ZCL GP Pairing command.

I've yet to compare this to pairing a Hue tap to deCONZ, but I suspect it might neglect to broadcast the GP Pairing command. Also, I still need to sniff what happens when adding a light (with ZGP proxy capabilities) to the Hue bridge.

[posixx]

@ebaauw did you manage to sniff some more? I will receive a (spare) raspbee gateway today, and have a hue bridge with some lights available to sniff, but unfortunately don't have a sniffing device..

[ebaauw]

Some, but I'm not sure I understand what I see. I will have to setup some more structured tests, which will have to wait till the weekend.

[posixx]

Hello @ebaauw did you make any progress with the proxy messages?

[posixx]

Any progress on the proxy support guys? Having 7 Taps of which 3 working not reliable i'm hoping for a solution soon to keep the wife happy:-)

[lcorsini]

Sorry to hijack an old issue, but putting raspbee as router inside Hue hub network could allow me to use tradfri remotes? (not inside hue app obviously, but from deconz)

[mariusmotea]

Not the answer that you expect, but you can use my emulator to control the existing Hue Bridge and also to use the tradfri remotes to control hue lights. There are multiple modes available for Tradfri remote: Hue Dimmer switch (because of different layout center button is ON, left and right are OFF), Hue Tap Switch, CT switch (original behaviour for ct bulbs), scene switch (original behaviour for color bulbs. Basically the Hue bridge emulator will have all remotes and lights paired in deconz plus all lights imported from Hue Bridge and is able to control all of them, you will only need to configure them from Hue Application paired with hue bridge emulator (for emulated hue dimmer and tap switches) or from {ip}/deconz for other two modes. Marius.

[manup]

Closing the oldest issues for know to tidy up the tracker and duplicates in newer issues.