Hue Tap's not identified correctly after v1.7

[ianfretwell]

After upgrading from v1.7 to 1.8 (and also v1.9) it seems that that component cannot distinguish between my two Hue Tap switches. In HA I see only one, but with the sensor name reversed from the friendly name - i.e. 'sensor.bathroom_switch' has a friendly name of 'Kitchen switch'.

Reverting to v1.7 and both switches re-appear as expected.

[robmarkcole]

This indicates a bug since #155 Can I request @elmigbot take a look?

[elmigbot]

@robmarkcole I think the issue hints that is was the commit before mine, since the issue occurs on 1.8.

If I had to guess, maybe its this bit:

  @property
   def unique_id(self):
       """Return the ID of this Hue sensor."""
       return self._hue_id[+4:][:-3]

[biver0]

I don't know if this is the place to add a me too, but me too. If I can be of any assistance in testing, I'm happy to. The two Taps seems to get combined into one.

[elmigbot]

I'm still convinced the above mentioned code is the issue. My guess is that the substring: self._hue_id[+4:][:-3] is not unique for Hue Tap (ZGP).

I don't have a Tap to confirm, and my particular sensors seem to be unique.

To test my theory, navigate to your config/custom_components/huesensor/sensor.py file. Delete the code above: lines 340 - 343. Restart HomeAssistant.

I believe your issue will be gone at this point. However, the real fix would be to change the unique id to something else, so that the entities get registered. Perhaps just self._hue_id, as I'm not sure I understand the intent of the substring.

[biver0]

@elmigbot That worked! It did, however, come up with all the sensor entities, include the two taps, with _2 after them (see below), so I had to update them in my lovelace cards. The taps didn't have a _2 I'm assuming because they didn't exist previously.

eg. What was previously sensor.living_room_hue_remote showed up as invalid and I had to update to sensor.living_room_hue_remote_2

I didn't know what you meant about unique_id #160. Where would that go?

[elmigbot]

Sounds right. The changes I had you delete are responsible for creating a permanent entity in HASS. With them deleted, the entities will be recreated every time you restart HASS. The permanent ones will be there until you delete them, the temp one will keep recreating as _2 (unless you delete the permanent ones).

What I was trying to say is that, the permanent entities are good, but the ID used to create them was not unique, which caused your issue. I am hoping that the code is altered to make unique ID in the future.

I think it could be as easy as adding back that code, and deleting just the Bold:

  @property
   def unique_id(self):
       """Return the ID of this Hue sensor."""
       return self._hue_id**[+4:][:-3]**

But, maybe not. I am hoping to find out in #160.

[biver0]

Dining Room Tap: 00:00:00:00:00:47:97:4d-f2
Master Bathroom Tap: 00:00:00:00:00:47:9b:f9-f2

[elmigbot]

@biver0 Thanks! I found some online too, but this definitely backs it up. I have already fixed the issue and waiting for the PR to be merged.

[biver0]

Thanks for staying on top of this! You rock!

[robmarkcole]

Should be resolved by #165

[ianfretwell]

I don't think this should be closed just yet - 2.1 has actually made things even worse for me. It now no longer detects any TAPs and I've lost one of my three dimmers. Upgrading to 2.1 being the only change!

[ianfretwell]

The console constantly shows the output attached - many times - and then the HomeAssistant docker container crashes completely.

[robmarkcole]

looks like a bug. Should really include:

def parse_hue_api_response(sensors):

    for sensor in sensors:
            modelid = sensor["modelid"][0:3]
            if not modelid:
                continue

Ping @elmigbot

These things happen when:

1. We are reverse engineering an API
2. There are no tests

:-)

[ianfretwell]

No problem!

I'll admit to not following the coding element of this - but - why was the code changed after 1.7 anyway - it works just fine in that version ?

[elmigbot]

Hey guys I think the only problem is I can't spell modelid properly... See the error says modlid. I will fix soon.

[ianfretwell]

Many thanks.

Can anyone explain to me how I get all the created sensors to revert back to not having, e.g. '_3' on the end of their names. Presumably the previously named ones are there somewhere but I can't find then to delete/remove them.

[elmigbot]

#166 should fix it, sorry.

[elmigbot]

go to entity registry in the configuration tab. Then sort by integration, and delete all the huesensors

[ianfretwell]

Excellent, thanks...pretty sure I'd even looked there but obviously not hard enough!

[elmigbot]

No problem!

I'll admit to not following the coding element of this - but - why was the code changed after 1.7 anyway - it works just fine in that version ?

1.8 Added the new hue button and it added the uniqueID that is giving us so much trouble. But with the uniqueID we get the benefit of HA creating actual entities that persist reboot. (Not much of a benefit right now since you have to delete a bunch of botched entities :-) )

1.9 Added support for the new Hue dial.

[elmigbot]

looks like a bug. Should really include:

def parse_hue_api_response(sensors):

    for sensor in sensors:
            modelid = sensor["modelid"][0:3]
            if not modelid:
                continue

Ping @elmigbot

These things happen when:

1. We are reverse engineering an API
2. There are no tests

:-)

I'm actually reverse engineering your reverse engineering :)

...I have no Taps, so my tests were about worthless.

[elmigbot]

@ianfretwell if you want to test it out and make sure it all works you can drop this file into your config/custom_components/huesensor folder

(right-click link and save link as... sensory.py)

[ianfretwell]

Many thanks - yes - that all looks to be working as expected now. And thanks to your previous point my config all looks a bit 'cleaner' again.

Much appreciated - thanks.

[biver0]

Yeah, thanks a lot. Things are working perfectly now.