Fails to work with "Mozilla IoT Philips Hue Adapter" about gateway-docker HOT 22 CLOSED

@Air-Global Thanks for reporting!

• Did you encounter this issue with the 0.4.1 image, or with one you built yourself?
• x86_64 or ARM?
• Are there any obvious errors in the log? You can check log/run-app.log inside the profile directory you mounted to the container.

from gateway-docker.

@mrstegeman
Ah yes, could have been more inclusive of details there:

This was with the 0.4.1 image pulled with Docker.
On x86_64 using a CentOS7 host with Docker CE (sounds weird but I noticed different behaviour before between OS versions and different Host OSes)

Ill check the logs when I get home, but couldn't remember seeing anything obvious in there.

from gateway-docker.

I just ran the image myself and installed the Hue add-on, but I don't see any obvious errors. Unfortunately, I don't have any Hue devices to test with, so I have a couple more questions:

• Is your Hue bridge running with a non-standard configuration?
• Did you run the container in host networking mode?

from gateway-docker.

@mrstegeman

• As far as I am aware no, just a standard install of the Philips Hue Bridge
• I tested both Host networking and macvlan

from gateway-docker.

Ok, we'll see what the logs have to say, but this sounds like more of an issue with the Hue add-on. I'll move this to the appropriate place if the logs don't reveal anything.

from gateway-docker.

@hobinjk Can you think of anything obvious that would prevent the Hue add-on from working within a Docker container?

from gateway-docker.

I can't think of anything obvious but the sequence of steps I'd try is:

1. See if curl https://www.meethue.com/api/nupnp works within the docker container and outputs the expected address of the bridge
2. Using the ip address of the bridge, try curl http://ip-address-of-bridge/. This should output html

If both of those work then I'd try pressing the bridge pairing button multiple times before starting pairing on the gateway. Otherwise I'm not too sure what could be going on but could make a debug version of the adapter if it's still misbehaving.

from gateway-docker.

2018-06-28 16:40:20.555 Loading add-on: philips-hue-adapter
2018-06-28 16:40:23.016 philips-hue: Opening database: /home/node/.mozilla-iot/config/db.sqlite3
2018-06-28 16:40:23.089 philips-hue: Loading add-on for philips-hue-adapter from /home/node/.mozilla-iot/addons/philips-hue-adapter
2018-06-28 16:40:49.909 About to call startPairing on PhilipsHueAdapter
2018-06-28 16:41:49.914 Pairing timeout
2018-06-28 16:41:49.915 Thing was not added
2018-06-28 16:41:49.915 addNewThing cancelled

This is on addon version 0.6.0 with the button pressed before accessing. Without pressing the button it logs that the button is not pressed.

from gateway-docker.

@Air-Global Did the 2 curl commands above work for you?

from gateway-docker.

@mrstegeman Ah yes, they do. (thought that was a bit redundant as the bridge responds or that the button was pressed)

from gateway-docker.

Interesting! If it's logging without the button pressed that means it's capable of seeing the bridge at the very least which is quite strange.

Could you replace philips-hue-adapter.js in ~/.mozilla-iot/addons/philips-hue-adapter with this https://gist.github.com/hobinjk/7acfab8d8d43b22183b7d79d21f2bc33, create a fake ~/.mozilla-iot/addons/philips-hue-adapter/.git directory (to disable the gateway's checksum verification), then see what log output it has?

from gateway-docker.

@hobinjk How much do you want, at the very least it lists all devices connected to the bridge:
2018-06-28 19:03:05.041 Listening on port 8080 2018-06-28 19:03:05.131 Not checking SHA256SUMS file for philips-hue-adapter since a .git directory was detected 2018-06-28 19:03:05.162 Loading add-on: philips-hue-adapter 2018-06-28 19:03:05.326 philips-hue: Opening database: /home/node/.mozilla-iot/config/db.sqlite3 2018-06-28 19:03:05.343 philips-hue: Loading add-on for philips-hue-adapter from /home/node/.mozilla-iot/addons/philips-hue-adapter 2018-06-28 19:03:05.706 philips-hue: updateDevices 2018-06-28 19:03:05.740 philips-hue: lights, sensors { '1': 2018-06-28 19:03:05.740 philips-hue: { state:

Edit:
There is a total of 654 times of the log listing "updateDevices" followed by all devices.

from gateway-docker.

Oh, that is very strange. Do other adapters (like the virtual-things-adapter) work?

from gateway-docker.

@hobinjk It used to work on 0.4.0
@mrstegeman Restarting (and also on recreating) the Docker it now lists:
WARNING in ./src/addon-manager.js 40:9-16 Critical dependency: require function is used in a way in which dependencies cannot be statically extracted @ ./src/addon-manager.js @ ./src/app.js
in the logs during startup. And seems to list no Addons on the add addons page.

from gateway-docker.

That warning is normal. If you open your browser console, do you see any errors being logged? There should be no reason for the add-on list to not load, unless there are connectivity issues.

from gateway-docker.

@mrstegeman There is internet access, using curl to download google.com for instance works perfectly. Ill have a look again tomorrow, in the past loading addons sometimes took long as well.

Thanks to you both for being so responsive @mrstegeman & @hobinjk

from gateway-docker.

Is the IP address that the docker container is using on the same subnet at the Hue Hub? I'm not super familiar with docker, but I know that VMs can be NATed or bridged and a NATed setup would behave differently than a bridged one.

from gateway-docker.

@dhylands When running in host networking mode, the container gets its own IP on the same subnet.

from gateway-docker.

2018-06-29 04:06:49.441 About to call startPairing on VirtualThingsAdapter
2018-06-29 04:07:49.493 Pairing timeout
2018-06-29 04:07:49.493 Thing was not added
2018-06-29 04:07:49.493 addNewThing cancelled
2018-06-29 04:07:49.494 virtual-things: Adapter: VirtualThingsAdapter id virtual-things pairing cancelled

It seems virtuals also no longer work, so that seems to point in another direction.

(host and macvlan provide the docker with its own outside access, so the host systems firewall is not in the way)

from gateway-docker.

@Air-Global Those logs are normal. Nothing else should really be logged from virtual-things-adapter, and pairing times out after some period.

It seems to me that things are probably working fine in the gateway, but that you may have some UI issues.

• What browser are you using?
• Are there any errors in the browser console?
  • Firefox: Menu -> Web Developer -> Web Console
  • Chrome: Menu -> More tools -> Developer tools, then click Console

from gateway-docker.

@mrstegeman Wow, that is something i should have done a long time ago...

Well, the issue itself does not exist. That is the good news. Looking at the console output in the browser it listed it couldnt connect to wss://domainhere/newthings.... etc.

All my dockers connect through a proxy from the outside (that provides the certificates) but when using a proxy there is no proxying of the wss protocol.

Using the http connection directly to the docker interface devices get added without issue.

Now its just solving the proxy issue. At least now we know.

from gateway-docker.

Glad we found the root issue here!

from gateway-docker.