I haven’t messed with homeassistant for a while so not really making much headway but the idea was to add a list of units to the Options form with their corresponding ip addresses that are returned from kumo and allow the user to edit it. That way if an ip address changes and hasn’t been updated on kumo servers or if kumo returns a blank ip address the user will have the ability to edit the IP address all in the homeassistant GUI without messing with json and the cache file. Something like this:
I’m a bit slow on this and am only working with the one unit I have so it would have to be revised for those that have more units but does this seem like a proper solution?
@parkercat Thank you for the lengthy response! I know, life gets in the way sometimes
I definitely know it worked for me before, as I never had to manually update anything until it broke when I reset everything. In fact pulling my original (from backup) cache file was how I found how it was configured before, and I had never manually edited that file before this issue. To be fair, since then I’ve tried so many different things to test, I’ve lost track. Yes, I currently have them on a separate 2.4G network, but same subnet, just different AP. However for the first month I was running it on my main network. No, I’m not in any blocked local access mode, wide open here. I know the network side well, it’s the kumo side I can see into. As for my situation, I’m not too worried, I don’t need to debug it necessarily, nor do I think you have access to the internals of the kumo software or system to even know why they don’t have my IP address, or how they discover it. I hear what you are saying about the adapters themselves sending it, but it just doesn’t seem like that too me. No worries, I really appreciate all the work you have done on this, and how helpful you have been to the community assisting people.
My main goal here is to continue to investigate, and to try to get answers to some of these questions, outside the scope of this integration necessarily, just in general the kumo architecture. I’m going to keep digging. I agree updating the UI to allow editing the IP is a good idea. I might even take a quick look at that myself to see if I can help. I do think that an auto scan would be fantastic though too. Seeing as how enough other people have commented on this thread and the one in github, we know this affects other people too. I would love to know how many and why! What makes us different? As for the code, would you be willing (if I create a pull request) to actually include it right in your code as a feature for auto discovery, or where you think just as a separate tool to help assist people in finding their IP addresses to then manually update? I think the former is what I would prefer, but it is your code
@omriasta, as per @spurpura’s comments it might be nice if the name and the MAC address (from the initial API request to kumo) are displayed here too. That information does not appear to be available in the app anywhere. I’ve seen other integrations do this (like honeywell) when it pulls all the thermostats, it shows them all with a drop down to select and save the room they are in.
@parkercat sorry, I misread your message. Disregard my comments then about including code in your integration, it sounds like you would not be interested in that. My code doesn’t really do anyone any good stand alone, since probably anyone that could figure out how to run it already has enough tech savvy to just fix the problem. I was thinking of this as more of a solution for folks to automatically fix it on setup, with no technical knowledge.
One other thing of note. Since our system install, the app would load very quickly. Now when it loads, it is very slow, and this screen just sits here while it tries to find the units. This to me indicates it can find the devices on the network (since it definitely can’t reach them all via bluetooth, and I believe bluetooth is only used for setup anyway, not controlling).
Yep, I saw that when I was proxying the android app. It’s basically trying to connect locally and when it fails it uses the cloud. The controller itself checks in with the cloud and can receive commands from there as well although much slower. So if the app can’t connect over local network, it queues a message on the cloud server, then once the controller checks in, it gets that message from there.
That is why it continues to work even if it doesn’t communicate over the local network or doesn’t have a record of the internal ip.
kumocloud.cmp.js:19 No IP address known for 9534P0085100069F
kumocloud.cmp.js:19 Sent command to Greatroom Kumo via cloud.
kumocloud.cmp.js:22 Asking cloud for any news about devices: 9634P0086100122F,9534P0085100069F,9634P0086100123F,9634P0086100131F
kumocloud.cmp.js:22 Device updates received: (2) [Array(4), Array(1)]
I guess I might have to come around to the opinion that no scan is happening. At least that let’s me focus my efforts on the controllers now to see if I can force them to report their darn IPs
@spurpura@dgoepp@parkercat
I changed the config flow to allow users to assign IP addresses to each detected unit if the cache file returned from Kumo does not include IP’s. The users will need to select the “prefer cache” option as the config flow only edits the cache file and I tried to keep it minimal so we don’t have to change the rest of the integration and/or store unit ip addresses in the config entry.
If you guys want to test it out real quick you can check out my fork here:
I haven’t done a pull request yet as I wanted to see if we could also pull more values into device properties like serial addresses and macs. Also because this just affects the cache file, if your ip is missing you still won’t receive the “discovered devices” window when the integration is initially setup but once you assign the ip addresses and reload you should be able to see the devices and assign them to rooms… Let me know how it looks…
@omriasta I am able to test this, and it does work. A little awkward, but better than manually editing a JSON file I honestly still think the best thing to do here is add a scan and match. However at a minimum I believe the MAC address should be displayed in the configuration to allow for matching devices in a router admin interface.
Good to know, I’ll work on it a bit more over the weekend. I will try to get all that mapping done before the integration gets setup so you would enter a user/password, then you would get a list back of units without ip addresses to fill in and then the integration would get setup. This way you will also get that screen that you showed for Honeywell.
Responded on GitHub, this probably more related to my fork as I changed the grabbing the cache in the setup rather than after the setup. It’s definitely not ready for primetime, just wanted to get a sense that it works on your end…will polish this up a bit and try to get a better setup flow to catch those users which aren’t getting ip addresses.
Just onboarded a 9-unit system with not an IP address to be found with the danielgoepp repository. Worth noting that this seems to be a fairly normal way for Kumo to operate - this system was installed and configured only a couple hours beforehand.
One suggestion - On the address prompt screen, you likely want to make the unit names and mac addresses into labels, so they’re still visible once the text box has been populated so the user can check their work and detect mistakes.
(I do also have the kumo system on a separate wireless network, vlan and subnet with the ability to do complete packet captures if there’s a need)
Thanks for the feedback here. To be clear, the work here was @omriasta, I just did some reformatting for the pull request. The integration does no discovery. All that this repository or the original does is get the profile from the kumo cloud service (via an API call). You are correct thought that seemingly increasingly the cloud service is not getting or saving the unit IP addresses and providing them back. I have a ticket open with them to try to discover why. The kumo app is the same, it’s updating your units via the cloud, not locally, and hence likely shows a long delay on startup.
I agree on the prompt, and I believe that will get sorted out. I know @omriasta looked into that, but did not yet find a way. More to come on that I think. But for now, the focus was on just providing the ability to set the IP addresses manually without editing files directly.
Yep, I looked at setting them as labels but at this time, homeassistant does not allow to dynamically generate labels. There was a pull request to allow this but it was not accepted.
I have just pushed v0.2.7-beta with the work by @omriasta and @dgoepp to allow supplying or editing IP addresses through the GUI. Many thanks to those two! Those who’ve had issues discovering their IP addresses, please test & report back, and if all is well I will make a non-beta release.
Thanks for all your work on this integration. I am new to HA but thanks to reading these posts and some of the code I have my mini-splits implemented and a decent automation working to keep things comfortable. My installation is complex with 2 outdoor units and 7 indoor units. I also have the kumo station which attempts to optimize the use of auxillary heat. The aux heat is oil and it has 4 zones controlled by nest thermostats. Looking at my detail card may give a better picture of how its organized.
The top 2 thermostats are virtual group thermostats. I would like for them to be the only ones with mode controls. I have looked at the other thermostat styles but none seem to completely fit the bill or to work entirely correctly with the kumo integration. I am not even sure if the individual units need their own temperature controls since the bedrooms are in one group and the living areas in the other. I mostly want to know the current state of each room. I would love to hear any suggestions on where to go with this. I am a retired software engineer, willing to drag myself up this learning curve. My questions are:
what direction should I go for the lovelace customizations?
has anyone else dealt with ‘changeover groups’ or plan to?
has anyone dealt with the kumo station or plan to. (if HA is in charge of aux heat it’s superfluous)
any interest in separate heat and cool set points? (it would be nice if automations only had to change the mode)
any solutions to units frequently going off-line (separate 2.4 network, all rssi below 55, they still drop)
my current automation chooses mode and temperature based on outside temperature, time of day, presence of people and whether the area is bedroom or living. It also chooses the source of heat (electric or oil) based on outside temperature. I am curious how others have set this up.
I am willing to help support the integration in whatever way I can. I know I just dumped a lot. Partial comments would be more than welcome.
what direction should I go for the lovelace customizations?
dg> I look forward to hearing where you go with this. I would love to see improvements in the interface side of the default climate controls. For example, the options to remove all options other than heat / cool / off.
has anyone dealt with the kumo station or plan to. (if HA is in charge of aux heat it’s superfluous)
dg> Pulled it out immediately once I got a better understanding of it. Completely pointless and annoying. I love not having it
any interest in separate heat and cool set points? (it would be nice if automations only had to change the mode)
dg> We tried auto mode with min/max - complete fail, especially this time of year. The outside unit can only do one thing, and having the inside units compete was not fun. We gave up and went back to explicitly setting heat and cool separately. I might be missing what you asking here though. I don’t see the auto button on your interface, which makes me think you have not enabled this on the kumo side.
any solutions to units frequently going off-line (separate 2.4 network, all rssi below 55, they still drop)
dg> Mesh? Like Eero, Google or UniFi? They say the don’t support it. I’ve had mixed luck. I’m back to dedicated 2.4 also, but just on a single AP, not mesh.
my current automation chooses mode and temperature based on outside temperature, time of day, presence of people and whether the area is bedroom or living. It also chooses the source of heat (electric or oil) based on outside temperature. I am curious how others have set this up.
dg> Very cool, I can see how doing this would (with experimentation) provide some better results than what we get. We just have basic time of day rules, and if we feel like adjusting it, we do manually to suit our current sense. I find this inspirational to perhaps explore more advanced logic.
I myself have a much simpler setup: 3 zones of mini-split, 3 zones of Ecobee controlling a gas boiler. For heat, in this house the mini-split is really only good until it actually gets cold (130 year old house outside Boston). Controilling 6 thermostat entities directly is, as you’ve said, a bit of a drag. So I wrote a simple Python Script component that has seasonal modes (Hot Summer, Normal Summer, Warm Shoulder, Cold Shoulder, Winter) each with its own schedules that control what each of the 6 zones should be doing. So, for example, in Warm Shoulder and Cold Shoulder the 3rd-floor zone is heated by mini-split (it’s one big room at the top of the house so doesn’t need much heat) but in Winter it’s on the hot-water radiators. I’ve thought of automating season switches but have found it sufficient to set them manually, even on a day-to-day basis.
The code (which I call “Seasons”) is not much to look at but it is on GitHub if you’re interested: https://github.com/dlarrick/seasons . It’s triggered on a 15-minute timer automation, and also when the main home/away sensor changes state, and when certain windows/doors open or close (see next paragraph). It controls the Kumo modes & setpoints directly, but lets the Ecobees run their own schedules and occupancy sensors.
Seasons can also shut off certain zones if certain window/door sensors are open. For us, this means we rarely adjust the actual thermostats; just set the overall mode, and potentially open/shut those windows if we want outside or climate-controlled temperature.
For your specific situation, I might try setting up template sensors from the attributes of the individual “small” thermostats, and use gauge / glance cards with those sensors rather than thermostat cards. That way the only real control is at the Group level but you can still see what’s going on with the individual units.
