Homebridge-hue: Philips hue: warning: ignoring unknown bridge/gateway

[suhajda3]

Hello,

I am using the Sonoff Tasmota firmware and thought why not use the built in Hue emulation with Homebridge. It works perfectly with Alexa so it should work with homebridge-hue. Right? :)

Sonoff Tasmota is probably based on the ESP8266HueEmulator since their bridgeid is the same. I have set up the config.json according to a v1 (round) bridge and set the bridgeid accordingly:

{
"platform": "Hue",
"users": {
"600194FFFExxxxxx": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"600194FFFEyyyyyy": "yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy"
},
"nativeHomeKitSensors": false,
"excludeSensorTypes": ["CLIPPresence", "Geofence"],
"lights": true,
"nativeHomeKitLights": false,
"wallSwitch": false,
"host": "192.168.1.10"
}

When starting homebridge-hue it recognizes the bridge but ignores it:

Philips hue: warning: ignoring unknown bridge/gateway {"name":"Philips
hue","mac":"60:01:94:CC:60:03","dhcp":true,"ipaddress":"192.168.1.10","netmask":"255.255.255.0","gateway":"192.168.1.1","proxyaddress":"none","proxyport":0,"bridgeid":"600194FFFECC6368","UTC":"2019-08-12T20:12:27","whitelist":{"cc6368":{"last use date":"2019-08-12T20:12:27","create date":"2019-08-12T20:12:27","name":"Remote"}},"swversion":"01041302","apiversion":"1.17.0","swupdate":{"updatestate":0,"url":"","text":"","notify":false},"linkbutton":false,"portalservices":false}

Please help me how I can make homebridge-hue work with Tasmota.

Thank you!

[ebaauw]

When starting homebridge-hue it recognizes the bridge but ignores it:

It correctly recognises that it's _not_ a Hue bridge. I hadn't seen this project before. Looking at the Wiki, there are some subtle differences with the Hue API. homebridge-hue would likely choke on these, if it wouldn't ignore the emulated bridge:

1. Missing attributes from the /config, notably modelid and apiversion;
2. It still exposes pointsymbols in the /lights;
3. state is missing from the /groups resources;
4. The /sensors resource seems to be missing.

[s-hadinger]

Hi, I'm one of the maintainers of the Hue portion of Tasmota. It is not based on ESP8266HueEmulator but was probably inspired at some point.

It's primarily designed to be recognized by Alexa devices. It's not in our plans to support all features from a Philips Hue, that would have too much impact on ESP8266 code size and RAM. However we can see what's missing to have homebridge-hue working.

1/ modelid is advertised as LCT007 but indeed apiversion is missing. What is your minimal version supported?
2/ I don't know what pointsymbols are and I don't see anything close to it being sent
3-4/ /groups and /sensors are not implemented and there is no short term plan for it. What would be the minimal requirement? Is just having an empty response for /groups and /sensors be enough?

[ebaauw]

It is not based on ESP8266HueEmulator but was probably inspired at some point.

Could some-one please capture the full state (GET /api/_username_) of Tasmota to a file and attach the file here, so I can double-check?

However we can see what's missing to have homebridge-hue working.

That would be great!

1/ modelid is advertised as LCT007

I think LCT007 is the modelid of a light (in /lights/xx/)? The bridge's modelid resides in /config (same as swversion). This is BSB001 for the gen-1 (round) bridge and BSB002 for the gen-2 bridge. I would actually prefer a different modelid, to positively identify Tasmota.

but indeed apiversion is missing. What is your minimal version supported?

Probably easiest to stick to 1.16.0, which is the last version supported on the gen-1 bridge.

2/ I don't know what pointsymbols are and I don't see anything close to it being sent

Cool. It's long been removed from the Hue API.

Is just having an empty response for /groups and /sensors be enough?

Yes, returning {} would be great! Not sure about /groups/0, though (this special group isn't returned in the full bridge state, so homebridge-hue queries it explicitly). I probably need to make an exception for Tasmota. Do you expose /resourcelinks? If not, an empty object here would be great as well.

[s-hadinger]

Here are come captures. I realize I gave you wrong information.

Also keep in mind that Tasmota doesn't care about username. Any value works.

GET /api/username

{"lights":{"108732049":{"state":{"on":false,"bri":254,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"LED1","modelid":"LCT007","uniqueid":"b4:e6:2d:67:b1:e9:00:11-1","swversion":"5.50.1.19085"}},"groups":{},"schedules":{},"config":{"name":"Philips hue","mac":"B4:E6:2D:67:B1:E9","dhcp":true,"ipaddress":"192.168.1.28","netmask":"255.255.255.0","gateway":"192.168.1.1","proxyaddress":"none","proxyport":0,"bridgeid":"B4E62DFFFE67B1E9","UTC":"2019-08-16T19:01:57","whitelist":{"67b1e9":{"last use date":"2019-08-16T19:01:57","create date":"2019-08-16T19:01:57","name":"Remote"}},"swversion":"01041302","apiversion":"1.17.0","swupdate":{"updatestate":0,"url":"","text":"","notify": false},"linkbutton":false,"portalservices":false}}

GET /api/username/config

{"name":"Philips hue","mac":"B4:E6:2D:67:B1:E9","dhcp":true,"ipaddress":"192.168.1.28","netmask":"255.255.255.0","gateway":"192.168.1.1","proxyaddress":"none","proxyport":0,"bridgeid":"B4E62DFFFE67B1E9","UTC":"2019-08-16T19:04:30","whitelist":{"67b1e9":{"last use date":"2019-08-16T19:04:30","create date":"2019-08-16T19:04:30","name":"Remote"}},"swversion":"01041302","apiversion":"1.17.0","swupdate":{"updatestate":0,"url":"","text":"","notify": false},"linkbutton":false,"portalservices":false}

GET /api/username/groups

{}

GET /api/username/groups/0

{"name":"Group 0","lights":["1"],"type":"LightGroup","action":{"on":false,"bri":254,"alert":"none","effect":"none","reachable":true}}

GET /api/username/sensors

{}

GET /api/username/resourcelinks (actually any unrecognized suffix will give the same result)

{"lights":{"108732049":{"state":{"on":false,"bri":254,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"LED1","modelid":"LCT007","uniqueid":"b4:e6:2d:67:b1:e9:00:11-1","swversion":"5.50.1.19085"}},"groups":{},"schedules":{},"config":{"name":"Philips hue","mac":"B4:E6:2D:67:B1:E9","dhcp":true,"ipaddress":"192.168.1.28","netmask":"255.255.255.0","gateway":"192.168.1.1","proxyaddress":"none","proxyport":0,"bridgeid":"B4E62DFFFE67B1E9","UTC":"2019-08-16T19:07:59","whitelist":{"67b1e9":{"last use date":"2019-08-16T19:07:59","create date":"2019-08-16T19:07:59","name":"Remote"}},"swversion":"01041302","apiversion":"1.17.0","swupdate":{"updatestate":0,"url":"","text":"","notify": false},"linkbutton":false,"portalservices":false}}

[s-hadinger]

@ebaauw do you think that responding {} for resourcelinks is enough?

[ebaauw]

Yes.

[ebaauw]

v0.11.35 should recognise the Sonoff Tasmota, based on the missing modelid in /config. It won't try and create a username, and simply uses homebridgehue. With an empty object for /sensors, /resourcelinks, and /groups I don't foresee any issues for these. Not sure what happens if you try and expose group 0, schedules, and/or rules.

[s-hadinger]

Good. The change for /resourcelinks was merged on Tasmota side.

[ebaauw]

I received word that it's working, closing the issue.