Argh, typo, sorry. New beta; try again.
1 Like
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:
- runstate: I’m actually not sure what this is reporting; seems to always be “normal” for me.
- rssi: WiFi signal strength for indoor unit
- sensor_rssi: signal strength for attached sensor
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.
Thanks for looking into it @parkercat. I wish I had the time to actually dig into it… but with a 10 month old and my expertise in other languages, it’s just not in the cards. I’ve documented the defect and have submitted it here.
@parkercatsuddenyl having issue with one of my thermostats being “unavailable” in HA. Tried restarting integration, HA itself and no luck. My other unit is just fine.
Oddly, I can control it from Kumo Cloud app which is what I had to revert to once I couldn’t control it anymore from HA.
I’m on the latest integration.
Any ideas?
Verify that you can ping it from the machine running HA. Is it possible its IP address has changed?
Nope, I have a fixed IP assigned to it and I confirmed it was ping able.
I decided to restart HA again, and this time it now works. I have no idea what happened and why it was in that state for hours
Prior to 0.2.3, network connectivity outages would just result in Kumo spamming the logs with error messages and consuming HA worker threads. I really do suspect you had some network problem that the old version would have just papered over. The network stack on these WiFi interfaces seems fragile & buggy in my experience.
0.2.3 notices that an indoor unit is unreachable and goes into this “unavailable” state using a pattern that a lot of other integrations are using. It will retry – once – on the next polling interval (usually 5 minutes). This change greatly reduces Kumo’s negative impact on HA as a whole if the indoor unit is offline, even for a long time – seasonal shutdown, for example.
0.2.4 (beta) requires a few consecutive failures in order to go “unavailable”. But it sounds like that wouldn’t have helped in your case.
@parkercat fantastic work on the latest release.
My standing problem of having to delete cache / restart to get all my units back seems to be resolved.
My kids disconnect stuff, a lot…
So my internet goes down more than it should which was always a larger effort to get everything back up and running.
Now it just comes back after a bit.
Thanks again for all the work you put into this.
1 Like
To be honest the changes were not altruistic. I like to turn off the breaker to the whole mini-split system when it won’t be in use for at least a week (dead of winter, pleasant-weather stretches) because there’s a heating coil in the outdoor unit that draws ~0.5 kWh per day when the unit is idle. Kumo is now much better behaved in that situation.
Hi All,
I recently got a set of PAC-USWHS002-WF-2 adapters to add to my four zone system. Since setting up hass-kumo I’ve noticed that when I set the temperature for a zone via Home Assistant that the official kumo cloud app seems to completely lose the current setpoint (notice the --º).
In practice this might not be a real issue (I don’t plan to actually use the kumo cloud app), but I still found it rather odd and wanted to better understand what is going on here. Anyone have any thoughts?
I believe this has to do with how Kumo deals with Celsius and Fahrenheit conversions. It appears to just be a display bug in the Kumo app and doesn’t appear to affect the functionality from my experience. I have found that if I set the temperature via HASS to a value in F that converts to C with more than one decimal place of precision, you get the display issues you are seeing, but if the conversion only results in one decimal, it will display properly. For example, if you set to 68.9 F, which converts to 25 C, the Kumo UI will display 69. But setting 69 F which converts to 20.555…C will result in the dashes showing up.
I suspect there is a lookup table inside the KumoCloud app that converts C to F and vice versa like Greg is describing. I never use the app so am uninterested in figuring it out. But I would accept patches that improve the situation.
I have got the kumo integration setup with HA however when looking in the log the IP address for all the devices are old when i first set up the system to use DHCP. I used postman to see the raw response and that also has the wrong IP address for my units devices. They are all static IP addresses assigned from my router and I pinged them all to confirm they are indeed using the the assigned IP. How can i get the cloud to re obtain the current IP addresses? (I have attempted refreshing the units settings, and restarted the whole system.) Is there a “Put” command that i can manually change the ip address for the cloud for get it to refresh the IP addresses OR do i just that to delete from from the Kumo app and re-add them?
It’s a huge mystery when & how KumoCloud service updates its IP addresss. You can try force-quitting the KumoCloud app on your phone (or reboot the phone) then go back into KumoCloud. And/or give it some time.
You can also set the “prefer cache” option in HA and edit the kumo_cache.json file to contain the correct IP addresses.
Thank You, editing the Json did the trick for now. Maybe one day the cloud will update the IP’s. Only other issue I am having is the set points don’t match by one degree. I think i saw someone else mentioned that above. My set point is 65 but HA says its 64. I know its just because of the conversion of the C to F, not sure if there is a fix for it or not just something i will have to live with.