diyHue Add-on

I’ve only discovered diyHUE today and I’m getting a very similar error.

This is what I have in the config.json file:

    "homeassistant": {
        "enabled": true,
        "homeAssistantIncludeByDefault": true,
        "homeAssistantIp": "192.168.1.40",
        "homeAssistantPort": 8123,
        "homeAssistantToken": "xxxxxxxxxxxxxxxx",
        "homeAssistantUseHttps": true

This is my configuration in Supervisor dashboard:

config_path: /config/diyhue
mac: DC:A6:32:47:FF:87
debug: false
deconz_ip: ‘’
no_serve_https: true

Out of the box - diyhue is not decting my Yeelights either.

Any help/suggestions please?

I think the gist of my issue it diyHue wants to access the HA API at http:// not https:// the way my setup works, and I thought this was relatively standard, was that http is refused when https is enabled.

My friend is going to help me set up NGINX soon which will hopefully fix this. Which is good because my node red color animations were a bit buggy this 4th of July.

Ok so after setting up NGINX diyHue wants port 443, which is what NGINX uses.
Any tips for anyone who has both running?

So after some re-jiggering to my NGINX and Router I was able to use 443 and 80.
Now I’m getting:

WARNING:root:Home Assistant Web Socket Client disconnected trying to (re)connect
192.168.1.207 - - [14/Jul/2021 21:47:46] "GET /api/hueess38e50d11ebbb600242ac1e210a/groups HTTP/1.1" 200 -
192.168.1.207 - - [14/Jul/2021 21:47:46] "GET /api/hueess38e50d11ebbb600242ac1e210a/lights HTTP/1.1" 200 -
192.168.1.207 - - [14/Jul/2021 21:47:47] "GET /api/hueess38e50d11ebbb600242ac1e210a/lights HTTP/1.1" 200 -
192.168.1.207 - - [14/Jul/2021 21:47:47] "GET /api/hueess38e50d11ebbb600242ac1e210a/groups HTTP/1.1" 200 -
{"ok"}

Is it reconnected after failing at first because something isn’t ready?
Is it happy after that?
There’s no lights available in the “Lights config” nor in the Hue Elements app.

Thanks.

You must click search/add lights to get them in app(hue or hue essentials)

How does this addon compare to emulated Hue Emulated Hue - Home Assistant?

I had emulated hue running on my HASS docker install to expose Deconz switches to my Harmony.

I’m now migrating to a dedicated Hass box (Blue), so wondering whether to ditch emulated hue for this?

Thanks of course I’m not home now.
I couldn’t find that buried in the Hue Elements menus.
I don’t seem to be able to do it over VPN.

Now after getting everything set up so I can allow the add-on to play on the ports it wants to, my lights have been discovered in Hue elements and iConnectHue, which is the real prize.
But upon commanding things, the response times are very slow.
Upon commanding a light animation to play last night I saw an attempt by it going to the first color and then the animation failing.
This morning the lights didn’t even attempt to be begin the animations.
Here is an issue I see in the logs, hopefully there’s some correlation to what I’m seeing, it doesn’t make much sense to me.

----------------------------------------
Exception happened during processing of request from ('192.168.1.160', 55589)
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/socketserver.py", line 650, in process_request_thread
    self.finish_request(request, client_address)
  File "/usr/local/lib/python3.8/socketserver.py", line 360, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/usr/local/lib/python3.8/socketserver.py", line 720, in __init__
    self.handle()
  File "/usr/local/lib/python3.8/http/server.py", line 429, in handle
    self.handle_one_request()
  File "/usr/local/lib/python3.8/http/server.py", line 395, in handle_one_request
    self.raw_requestline = self.rfile.readline(65537)
  File "/usr/local/lib/python3.8/socket.py", line 669, in readinto
    return self._sock.recv_into(b)
  File "/usr/local/lib/python3.8/ssl.py", line 1241, in recv_into
    return self.read(nbytes, buffer)
  File "/usr/local/lib/python3.8/ssl.py", line 1099, in read
    return self._sslobj.read(len, buffer)
ConnectionResetError: [Errno 104] Connection reset by peer
----------------------------------------

So all errors aside there does seem to be some light in the dark.
The lights are connected to a few Hue apps, but I’m really not feeling the viability.
The lights are very slow to respond vie the Hue apps and just give up on trying to make color animations happen.
I’m specifically trying to use iConnectHue, not sure if anybody here uses that?
If I execute color commands in HA to the same lights they respond instantly.

With the end of summer looming in my mind I might have to switch back to the Hue bridge so I can have my spooky color animations.
I was really hoping to cut out a Zigbee bridge.

Only wifi light are fast, special those with diyhue firmware

Proper Zigbee lights are slow?
I guess I’ll be firing the Hue hub back up…

you can tryout huemulator

I am embarrassed to ask the noob of all noob questions, but I’m stuck on the very first step setting up the config in the add-on.

The question: What mac address are you referring to?

Is it the mac address of the native hue bridge? Is is the mac address of the raspberry pi I’m running HA on? Is it the mac address of your mom?

As far as I can tell, none of the docs or guides anywhere explain what device’s mac address I’m supposed to put; they all assume everyone knows what it’s referring to. Go ahead, see for yourself.

The official add-on documentation:

Option: mac

The mac-address of your device.

Wow, super helpful. Looking elsewhere, @foxy82 's guide is definitely very thorough, but even there:

Once installed you need to configure the add on it as follows setting the MAC address is very important before the first run - this is the MAC address of your server.

Ok, what “server”? Again, is this HA, aka my pi? The native Hue bridge? nginx? duckdns? Again, “mac address” of some “device” is presumed known and leaves idiots like me behind.

And don’t get me started on diyhue.readthedocs.io/en/latest/lights/homeassistant.html which begins with editing the config json. There must be some creative unspoken inferences not mentioned for that guide to truly begin at the real starting point.

An obvious question to me: “Hey ManImCool, instead of posing your question here with obvious petty and bratty undertones, why didn’t you just try all those mac addresses you were able to come up with until you figured it out?”

My response: First, I acknowledge I’m being a little bitchy. I thought about trying this, until reading through all of the threads and seeing that a lot of people smarter than me mess this up even when they have the correct mac address to begin with, whether they started this add-on too early, or forgot to turn off nginx, etc. In most instances, people only seemed to fix it by starting all over deleting everything or worse, a fresh install of HA. From all these data points I’ve read, a trial-and-error approach seemed unwise.

In sum, please tell this dum-dum what (*&@&4’ing MAC address of what *&$^#@ device to enter into the add-on config so I can continue foxy82’s guide like a normal person. And maybe we add this info to all the main guides so other dum-dums like myself can avoid feeling extra dum-dum.

xoxo, -Sean

1 Like

Hey Sean,

it is the mac-address of your pi. i will add a clarification. :slight_smile:

1 Like

Yeah I run it on a server hence phrasing it that way

1 Like

Thanks! After steps 5/6 I successfully added the bridge to HUE Essentials, but when I tried to do the same to the native Hue app, it connected but then said there was a mandatory update for the bridge. Is this normal and we’re supposed to let it update? Or should we ignore for now, at least at step 5/6, because an official Phillips update will break diyHue?

Searching for “mandatory update” gave me no results. Once again I find myself being the dum-dum where the unique things either only happen to me, or are presumptions not written in any instructions that everyone but me knows.

1 Like

I had the same thing.
I think it happened when Hue updated their app.
I don’t want to speak for the diyHue dev, and definitely not the add-on creator, but I don’t think there’s a fix for that to get it to think it’s up to date yet.
I hate to burst your bubble, but I spent a lot of effort trying to get this all to work, and I finally did but the speed of color changes was extremely slow, 95% of commands failed, and I could never turn the lights off from Hue Essentials or iConnectHue.

Clearly this is all working well enough for some folks who spent all of this effort to make all of this, but for me the end result was worse than just creating animations in Node-Red, which is a pain.
I switched my actual Zigbee lights back to the real Hue bridge.

That sucks if that’s truly the case. If true though, wouldn’t more people have come in here and asked for troubleshooting? Or are you saying the issues are primarily for new diyhue users trying to get set up, and that older diyhue users that were set up before Philips changed to the new app still have their setups working just fine?

Out of curiosity, what non-Hue bulbs are you using with your real Hue bridge? Are you flashing any custom firmware or do they work out of the box? I have a few Gledopto bulbs but am not crazy about them.

Probably? I think if you had set things up before they rolled out their fancy new app they would probably keep working as they were. I think most people are using third party apps which don’t care about firmware updates like Hue Essentials. I was using iConnectHue.

No bulbs, controllers. I use the Gledopto LED controllers to take non zigbee LEDs that are cheap on Amazon and the form factor I want, splice the wires into this thing and tada, it’s in the Hue ecosystem.
Gledopto used to be a cheaper solution, but they’re kind of realizing they can charge near Hue prices for various reasons.

Hey !

I would like to inform you that the diyhue addon has now moved to the official repo and is officially supported and maintained.

https://github.com/diyhue/hassio-addon
3 Likes