Kumo app does work on phone.
The “+” is yellow on my install, probably because of dark mode? But no, pressing the “+” then typing “ku” only brings up Roku and Emulated Roku.
The only way I could get it to show up is by putting the repo above in custom_components/ dir in the shell. Once there, then it shows up when adding via “+” and typing “ku”.
If “+” brings up Roku and Emulated Roku (built-in integrations) you’re not on the HACS page.
Have you installed https://github.com/hacs/integration ?
No I have not! “add-on store” is not the same as “Home assistant community store”. I will install HACS and try again.
I changed Kumocloud password to something even more basic and was able to get the API test to work outside of HACS/kumo integration.
After that I setup installed Kumo integration via HACS twice before it would show up. Right now the climate entities it creates are not there but I will troubleshoot tomorrow.
Success! Thanks @parkercat
Ran into the same issue as others where the address was not populated in kumo_cache.json and thus no entities showed up. Once added, nothing happened, so I restarted ha core and again the json was populated without the address. Added the address again, set kumo_cache.json as 444, restarted ha core and then they now show up. Before any temp/mode changes would work in HA I switched perms back to 644 and now all appears to be good.
In using the Scheduler Component to try to automate my Mitsubishi mini split, I’m finding that it’s not turning on the mini split.
The author of that integration said this (source):
The schedule should to go
triggeredstate once the timer is due. The thermostat should ofcourse change the temperature setpoint + the operation mode at this time.In 9/10 cases the thermostat does change its setpoint but does not change the operation mode. So it will stay off. This is even the case for the generic thermostat .
The scheduler sets thehvac_modewhen calling theset_temperatureservice, it is often ignored by integrations.
I can’t tell if this is something to do with this KumoJS integration or something else in the pipeline. Looking at the climate.py file on github, i can’t see why this would be due to this integration if you are just passing commands through.
As I commented on GitHub, if Scheduler wants to change the HVAC mode it should call climate.set_hvac_mode. 8 off the 76 climate (thermostat) integrations that ship with HA do not set the HVAC mode in a call to climate.set_temperature.
I’m caught in the middle on this one. @neliss, why do you think the thermostats should automatically set hvac mode just because set point was set?
Also @parkercat I assume you meant “68 of the 76” since you mentioned that number in your GitHub comment:
I’m honestly not sure which is the correct behavior here. It did initially strike me as odd that the scheduler card implementation assumed that setting the set point should be combined with setting hvac mode. However, given its an additional parameter, I don’t necc see harm in being able to support this in the kumo integration.
For two reasons:
User-friendliness
Usually you change the temperature setpoint because your intention is to warm up (or cool) the room. Not for sake of randomness.
This is not just for the scheduler integration, it would also apply to the standard Thermostat card (as well as automations etc).
Once you move the slider, a smart thermostat would sense that it needs to warm up to achieve the target setpoint.
Compliance
If you take a look at the set_temperature service definition, you see that there is an optional parameter hvac_mode here.
This is exactly intended for the purpose of avoiding heating up a room to be a two-step process.
Currently, this integration completely ignores this parameter, so it is not compliant with the HA climate definition.
Note that it is not defined by the supported_features whether or not a climate integration supports setting the hvac_mode together with the temperature.
So, implementing this behaviour is mandatory if your climate integration has a set_temperature option as well as hvac_modes, its not a choice for the developer.
IMO there is not really a discussion here. It was initially forgotten in the implementation, so it should be added. The property is optional, so things stay 100% backwards compatible.
@parkercat What are your reasons for not supporting this option? Is there any harm to it?
Thanks for the pointer to the service definition. This definition has changed since I initially wrote the integration; Git shows that it used to read “HVAC mode to set temperature to. This defaults to current HVAC mode if not set, or set incorrectly.” At the time I interpreted this to mean “if hvac_mode is heat, set the heat setpoint(s)” and you can see that the logic in Kumo follows this pattern. And as my code survey shows, I’m not the only one.
Anyway, that’s water under the bridge now and I will fix. I’ll need to remove the errant code as well as set the setpoint, so @tmchow thanks for your PR but it’s incorrect. I wish you both luck in getting the rest of the climate entities compliant as well; maybe leading with the “compliance” argument would be more effective though.
I have pushed a new beta version of Kumo that makes this change, v0.2.3-beta. It also improves operation when one or more indoor units are not reachable. If it seems to work OK for folks I’ll promote it to stable later this week.
Thanks! I’ll try the beta once it’s avail.
@parkercat just installed the beta and restarted. Set a scheduler card schedule to turn one unit on and it threw an exception. Here is relevant snippet from logs:
2020-11-22 16:12:00 ERROR (MainThread) [homeassistant.core] Error executing service: <ServiceCall climate.set_temperature (c:91db30dc0f81db82011d169514348399): hvac_mode=heat, temperature=69.0, entity_id=['climate.attic']>
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/core.py", line 1467, in catch_exceptions
await coro_or_task
File "/usr/src/homeassistant/homeassistant/core.py", line 1486, in _execute_service
await handler.job.target(service_call)
File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 204, in handle_service
await self.hass.helpers.service.entity_service_call(
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 499, in entity_service_call
future.result() # pop exception if have
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 664, in async_request_call
await coro
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 536, in _handle_entity_call
await result
File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 544, in async_service_temperature_set
await entity.async_set_temperature(**kwargs)
File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 404, in async_set_temperature
await self.hass.async_add_executor_job(
File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "/config/custom_components/kumo/climate.py", line 528, in set_temperature
self._set_hvac_mode(target_mode)
AttributeError: 'KumoThermostat' object has no attribute '_set_hvac_mode'
Argh, typo, sorry. New beta; try again.
Seems to work!
I have finally promoted v0.2.3-beta2 to release-0.2.3. No changes.
I’ve also pushed a new beta beta-0.2.4 that adds 3 new attributes:
This beta also is less aggressive at setting the indoor units to “Unavailable” if they’re not reachable: it takes 3 consecutive failures in order to do so.
@parkercat: I’ve got a minor issue and was wondering if you can replicate it. I’m creating a scene with the thermostat turned off. Once I turn on the scene, the home assistant log gives the following error: ERROR (MainThread) [homeassistant.components.script.test_restore_scene] test_restore_scene: Error executing script. Invalid data for call_service at pos 1: expected float for dictionary value @ data[‘temperature’]
I can’t find any documentation on the forums of a similar issue. I’m wondering if it is an issue with this integration. I’m running version 0.2.2 + 2020.12.1. I’ve attached the script I’m using - you just need to replace the climate entity_id to see if you can replicate it.
test_create_scene:
sequence:
- service: climate.turn_off
data:
entity_id: climate.office
- service: scene.create
data:
scene_id: test_office
snapshot_entities:
- climate.office
test_restore_scene:
sequence:
- service: scene.turn_on
data:
entity_id: scene.test_office
I’ve never seen snapshot_entities before. But a turned-off Kumo entity has attribute “temperature: null” which is indeed not a float. I’m pretty sure you can’t set the setpoint of a Kumo unit when it’s off; the unit won’t accept the change. So I’m afraid that Kumo is probably just not compatible with snapshot_entities at the moment.
To validate, what does ‘scene.test_office’ look like once it’s been stored? You can probably look at it in the template editor.
I’m not sure how to dig into the heart of an already created scene ( this thread doesn’t give me a lot of confidence that it can be done: WTH State of scene? ).
Just to confirm - the temperature cannot be set by the kumo integration once it is in a power off state? I haven’t looked at the code, but is it possible for the integration to return temperatures with code that does something like this: If Termperature IS NULL Then 0 ELSE Temperature END
If not, this feels like something that I should submit as a defect within Home Assistant itself. If integrations have to allow for NULL temperatures, snapshotting/restoring thermostats should allow for this as well. Let me know what your thoughts are. Thanks.
I did a little digging in the HA code to see what’s up with snapshot_entities and restoring states from a scene, and I want to revise my appraisal of what I think is wrong here. When you create a scene with snapshot_entities, it stores each entity’s state and attributes into the scene. Then when you go to activate the scene, it calls the integration’s reproduce_state functionality with that stored scene.
The issue here is that when a climate entity is off, its ‘temperature’ attribute (the setpoint) is None, shown on the states page as ‘null’. null/None is not a valid temperature to set (not a float) and so you get the error. I only have Kumo and Ecobee climate entities, but both those integrations show this ‘null’ behavior. I predict you can’t save a turned-off Ecobee into a scene either, which (if true) is strange because Ecobee is used as an example in the Scenes documentation.
If I was the one trying to get this working I’d be willing to hack at it for a while, but sadly for you I have no interest in storing thermostat settings in scenes in my own setup 
so it’s not an itch I need to scratch. But I’d likely start by printing out a bunch of stuff in homeassistant/components/climate/reproduce_state.py to figure out if it even gets that far, or if the null value is being rejected earlier.