I just added 2 mitsubishi wireless sensors to my setup. I wonder if it’s possible to expose these sensors as devices and entities through this integration? Would make for some great automation capabilities to read all the remote sensors temp and/or humidity.
I tried adding another Kumo integration, but it only read the 2 thermostats. Presumably because it’s only looking for those, but my guess is the underlying APIs it’s accessing gives info for the sensors as well. I’m happy to run some tests it that helps, just need to know what you want me hit.
At least in my setup the sensors are tied to indoor units. The temperature reading replaces the unit’s reported ambient temperature and the humidity reading is exposed as a device attribute, which you can extract with a template sensor. Sensor battery level, too. See current_humidity and battery_level in the following:
It would be nice if the unit still reported its own temperature reading when hooked up to a remote sensor, yes. But it doesn’t; there’s no spot for it in the returned JSON. The sensor’s temperature reading is present in the data returned, but its value also replaces the unit’s own reported temperature.
It looks like if there were up to 4 sensors on one indoor unit it would report them all, but:
I’m not sure what the unit would do with that extra info (choose the one furthest from the setpoint? Average them?),
I’m sure there are more cost-effective ways of getting another reading, and
My pykumo library doesn’t support multiple sensors, always reporting on the first one.
Tons of trouble with this integration on hassos 4.14, home assistant 0.116.4
Cannot find this integration in the Kumo store
Had to install from github.com/dlarick/hass-kumo despite note on the repo “As of January 2020, Kumo is available in the HACS default store, and I consider it feature-complete and stable.”
Credentials aren’t accepted in homeassistant kumo integration web interface even when using simple creds
When submitting API call manually to geo-c.kumocloud.com/login per the github integration, the only response ever received is “null%”
Dumb question: Does the KumoCloud app work on your phone?
As far as HACS: Press the big red “+” at the bottom right and search for mitsubishi or kumo. If they’re not showing up something is wrong with your HACS install.
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”.
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.
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 triggered state 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 the hvac_mode when calling the set_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.
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.
@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'
I’m caught in the middle on this one.