Please run the HubspaceTest.py file in the repo, if you can. It will provide data that can be used to add those lights other functions. Or if you just send me the model number of those lights (shows in the entity details), I can try to add them.
1 Like
Here is what I bought: EcoSmart 60-Watt Equivalent Smart Hubspace A19 Color Changing CEC LED Light Bulb with Voice Control (1-Bulb) 11A19060WRGBWH1 - The Home Depot.
Cheap at $8 each…
Download the latest light.py from the repo (https://raw.githubusercontent.com/jdeath/Hubspace-Homeassistant/main/custom_components/hubspace/light.py) and replace the light.py in custom_components/hubspace/ . Restart and hopefully you’ll have RGB and maybe colortemp (color temp is tricky at may not work well)
you will need to specify the friendlyname or room name. It will not find it automatically
oops…
2022-12-29 17:01:46.637 ERROR (MainThread) [homeassistant.config] Platform error: light
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config.py", line 878, in async_process_component_config
platform = p_integration.get_platform(domain)
File "/usr/src/homeassistant/homeassistant/loader.py", line 657, in get_platform
cache[full_name] = self._import_platform(platform_name)
File "/usr/src/homeassistant/homeassistant/loader.py", line 674, in _import_platform
return importlib.import_module(f"{self.pkg_path}.{platform_name}")
File "/usr/local/lib/python3.10/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "<frozen importlib._bootstrap>", line 1050, in _gcd_import
File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
File "<frozen importlib._bootstrap>", line 1004, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'custom_components.hubspace.light'
Be sure you download the raw file and change the extension to light.py . Perhaps you saved it as light.py.txt or something.
Duh, rookie mistake on my part… I created a new text file in Windows and copied the code - .txt was the issue…
That being said, I still see only on/off and no color options with the new code. I also noticed that on the hubspace app these bulbs have another effect called rainbow that cycles through all the colors and allows you to choose the speed - this also does not show up in HA with the new light.py.
Lets move this over to the github issue
I have no plans to support effects. I may try to implement a service so you can send arbitrary commands
I added an issue to github to add support for the bulb. Thanks again for the help.
Thanks for the update. The lights seem to show up as color now just fine with the 1/1/2023 release. I will let you know if I find any issues.
Any recommendations on setting up the evil fan/light combo, “52133, 37833”?
Config block:
light:
- platform: hubspace
username: NOPE
password: ALSONOPE
debug: true
roomnames:
- 'Living Room'
I’ve tried it with full autodiscovery, with matching friendlynames, and with roomnames.
Result is always the same:
- No integration or device in the lists
- In the entity list, I have one entity for the fan component (LRFan_fan; LRFan is the device name in the app)
The debug log (linked below) implies that the light isn’t being created because the light and fan have the same device ID. In addition, the entity for the ‘fan’ appears to be a light entity in HA - which, given the inheritance I see in the code, would track?
Try manually downloading the latest light.py in the repo. Someone made some changes that I did not check well enough. See if it works
lrfan is the correct friendlyname. When it works, you will have a .light.lrfan (the light) and light.lrfan_fan (the fan) .
So, I may have gone down a rabbit hole trying to clean up some things.
In a fork I made from your code, I’ve made a fan entity implementation that uses the fan controls properly, using the 25/50/75/100. I’m now working on the light, then a combined ‘hubspace’ config stanza.
Would you be interested in a PR splitting the entity definitions into proper entities?
That would be great, I was never able to figure out how to do that! Please start from the latest version, as the new service capability I added in the last release is super helpful.
Yup - started with today’s release.
So I have the fan showing up as a fan, and the LOW/MEDIUM/HIGH/MAX settings as the app exposes:
The updated configuration stanza is:
hubspace:
username: NOPE
password: ALSONOPE
debug: true
roomnames:
- 'Living Room'
light:
- platform: hubspace
fan:
- platform: hubspace
You can see it in my forked repo at GitHub - shawngmc/Hubspace-Homeassistant
I’m not thrilled with it so far:
- Currently, it’s only using the child device name, not the parent friendlyname
- Only Fans are split out; I don’t have Locks, Outlets, etc. to test
- It’s a breaking change; the yaml config changes
- It calls Hubspace for devices twice, and if we break the other devices out, more
- There is a lot of duplicated code between the light and fan platform implementations
- YAML Config is strongly discouraged for device and service integrations (see Integration Configuration via YAML | Home Assistant Developer Docs); this prevents it from ever becoming an official config
- Entities have a weird lifecycle; ideally, setup in init.py would make a list of potential entities and light.py, fan.py, etc. would add them. However, this would need to be decoupled (ie, the actual add_entity call would need to be in setup_platform still, and init.py:setup() simply makes a list based on all the devices it found and stores that in hass.data). This is because when an Entity object is created, it auto-registers with the system at least partially.
- Not being able to config via the UI is annoying
What are your thoughts on a more substantial overhaul? Switching to config flow and loosening the coupling between the entity types further will mean UI config and still be efficient under the hood.
As an alternative, I could try forking it, implement w/o any concern for backwards compatibility, and you could decide then. If I do that, for an Minimum Viable Product I’d only handle light and fan at the start, as well as get rid of the manual listing via room or friendly name. Those might make sense to drop for UI config anyway.
Config Flow looks a bit painful though. 
Hi there, I’m trying to use this integration to get control of my “Fanelee” Ceiling fan + light. Model: 52133.
I read through this thread and it looks like it’s giving some people a hard time, but I think that I have a fundamental misunderstanding of how to get my configuration.yaml set up.
Here’s what I’ve written, following the example in the readme:
light:
- platform: hubspace
username: myemail
password: mypassword
debug: true
fan:
- platform: template
fans:
bedfan::
friendly_name: "Bedfan"
value_template: "{{ states('light.ceilingfan_fan') }}"
percentage_template: "{{ (state_attr('light.ceilingfan_fan', 'brightness') / 255 * 100) | int }}"
turn_on:
service: homeassistant.turn_on
entity_id: light.ceilingfan_fan
turn_off:
service: homeassistant.turn_off
entity_id: light.ceilingfan_fan
set_percentage:
service: light.turn_on
entity_id: light.ceilingfan_fan
data_template:
brightness: "{{ ( percentage / 100 * 255) | int }}"
speed_count: 4
And here’s my names for the fan inside of hubspace.
With this config, I run the Check Configuration in Dev Tools, and I get the following:
Invalid config for [fan.template]: invalid slug bedfan: (try bedfan) for dictionary value @ data['fans']. Got OrderedDict([('bedfan:', OrderedDict([('friendly_name', 'Bedfan'), ('value_template', "{{ states('light.ceilingfan_fan') }}"), ('percentage_template', "{{ (state_attr('light.ceilingfan_fan', 'brightness') / 255 * 100) | int }}"), ('turn_on', OrderedDict([('service', 'homeassistant.turn_on'), ('entity_id', 'light.ceilingfan_fan')])), ('turn_off', OrderedDict([('service', 'homeassistant.turn_off'), ('entity_id', 'light.ceilingfan_fan')])), ('set_percentage', OrderedDict([('service', 'light.turn.... (See ?, line ?).
I feel like I’m missing something super basic in order to get this going. Just because I saw a couple comments in here, I tried removing the quotes around the friendly_name, and changing them to single quotes. No change.
Let’s move this over to github. There already is an open issue to “implement config flow” which someone is working on. Since this is a big change (and a great one), should probably wait until stable and have a config flow until a release. Also, I want to avoid calling Huspace(user,password) for each type (this is the main reason I never broke things out in the first place) . It must be solveable. Looks like a great start!
I don’t have a fan, so can’t really help. Look likes the documentation has an error, should only be one : after bedfan.
Make sure your have a fan and a light entity working, before getting the template to work.
Download the latest light.py, as I think there was an error in the latest release.
It will only be “ceilingfan_fan” in the template if your freindlyname for your device is cielingfan, but yours is “bedfan”. So do not use bedfan for the new names in the template. Might be easier to rename it in hubspace to cielingfan, then you can use template as is, except remove the extra :
I have the same device and have had no end of issues getting it to work. At present only the fan is seem. The light is not. The error in the looks is as follows:
Logger: homeassistant.components.light
Source: helpers/entity_platform.py:536
Integration: Light (documentation, issues)
First occurred: 1:34:04 PM (3 occurrences)
Last logged: 1:34:04 PM
Platform hubspace does not generate unique IDs. ID ce7e8811-697a-4872-9c7d-0a97e5b4b608 already exists - ignoring light.dads_fan_fan
Yes, the fan is annoying. Try replacing the light.py with this file: https://raw.githubusercontent.com/jdeath/Hubspace-Homeassistant/main/custom_components/hubspace/light.py
and report back if it helps. If so, I’ll make a formal release.