[RELEASE] Unified Thermostat Driver - MELCloud, MELView, Kumo Cloud* and more if you want

Sorry another post. I should have waited until I did more diagnostics.

Seems this problem with temperature not updating in the app (after setting tempersture in hubitat) is only for auto mode. If I set the mode to heat or cool the temperature updates as expected.

Edit: If I just switch to heat mode the temperature doesn't necessarily change in app, I need to change to heat and then change the temperature setting in hubitat for the app to update.

Unfortunate part for me is this application I'm doing needs auto as I'll be ramping temperatures up then down so don't know the exact location where it transitions from cool to heat.

So a work around for now.

As I increment the temperature roughly 1 degree every hour...

Send a heat mode command at the temperature I want. Then shortly follow with the auto command at that temperature. So on the next hours temperature change, the temperature target updates as I'm sending the heat command first. Then closely follow with the auto command. This way the temperature changes due to the heat command temperature change. Assuming the ac is at target temp then the short heat command won't do anything to the room temperature as it's only on for say 30 seconds.

Now I may need to explain below better but I best leave for work ha ha.. So rushing this out.

Perhaps this isn't ideal for long term though as the ac could be changing from heat to cool. I could look at shortening the gap to really short between issuing the heat and auto as I think it's more about hubitat thinking the state has change to heat and temperature changed for this to work. It's not relying on feedback from polling.

Side note: I think you're experiencing something similar that bugs me between the mobile app and the controller I have on the wall in my hallway. The controller allows for a change in temp when I am in Dry mode, but the app does not, the same happens with Auto mode. In the app I have to do you're workaround, change the mode temporarily, change the temp and then change back to Dry mode. Given the delay I mentioned previously, I am expecting changes like that are probably applied together and sent to the unit.

In terms of your testing and at least the first log you posted, using Auto, calling the setHeatingSetPoint..... It's complicated, particularly on a Friday :slight_smile: But I'll take a stab at explaining it....

The way the code currently works is that if you set the heating set point, it first sets it in the heating set point state variable (on the right hand side of the device edit page). Then it checks whether you are in HEAT mode, if you are, it sends a command to MELView / the unit to adjust the set temperature, otherwise it is left unchanged. Equivalent logic is used for COOL. If you switch between modes, the set temperature would also get adjusted on MELView / the unit based on the set point for that mode.

This was the way I interpreted what Hubitat was expecting and what I had to work with on MELView. From what I could see MELView didn't have the notion of a stored heating or cooling set points, you just had a set temperature and the mode. Hubitat gave us the option to keep these separate set points, and when you switched modes, you would switch to the last set point for that mode.

Somewhat selfishly I did include Dry mode in the criteria when wanting to adjust the coolingSetPoint, but in the end I rarely take advantage of it because the dashboard tile doesn't provide that option, I tend to just do it through the wall controller or open the MELView app on my phone.

In terms of Auto... I'll need to think about it, including understanding a bit more about how the units actually operate in Auto mode and how the temperature comes into it.... But I may be able to offer another command for you to call in a rule to adjust the set temp.... But a bit more thinking involved....

On that note, I would question why you are using Auto but then adjusting the temps yourself... If you are wanting to gently decrease or increase the temperature, I would have thought you would want to let the unit operate in the mode to move the temps in that direction, with the assumption that they tend to dial back their compressor when they are around the set temperature...

Ok that makes sense... Sort of. I'll need reread it ha ha.

Hmmm. Re auto.. I was thinking that as we also have a small heat source in the room then I needed to use auto. But now you mention it it got me doubting.. So talking out loud here.

Edited.

At 16 degrees set point, the heat source in the room will raise the temperature faster than we want so we actually need cool mode to stop it raising too fast. As we go past ambient temperature, say let's call it 22 degrees outside, then at that stage we actually need to heat the room to get the rate increased as the small heat source won't be enough and needs the ac heat. Coming from peak to low always needs cooling (no transition). The transition point heating the room will change depending on ambient temperature so can't really predict when to change over unless we have an external sensor and trial and error to see at what stage to transition from cool to heat.

Edited above.

Happy to have prompted the re-think, but might leave you to ponder the logic you want to use while I look at the driver and how I may want to tweak it. Might be a while before I get something updated, there's a few other features I have promised for some time that I should really release before something new like this.

1 Like

Sure. Thanks for your efforts. There's the work around for now anyway.

1 Like

KUMO LOCAL CONTROL..... Preliminary Testing....

That should get some peoples attention :slight_smile:

I have made a start in getting something together that people can test. At this stage It is largely untested by me, and requires some very manual steps to operate, but I wanted to get something out to see how it behaves, before polishing it any further. I'll do some testing myself over the next few days, but if anyone else wants to make a start they can.

The steps that I expect will need to be performed are:

  • Manually copy and update the Parent and Child drivers (not through HPM, let me know if you need notes on doing this):
  • Click the Refresh command at the top of the parent device page
  • Scroll to the bottom and click on one of the child unit devices
  • You should now see W, C and Address entries in the State Variables (just below the commands) - looks like I have thing wrong.... I will looks at this and post back when it is fixed.
  • You can ignore the new Local Control preference setting for now
  • You should see a new command called "unitCommand_Kumo_Local", which we will use for testing
  • Paste in any of the follow text into the command parameter and click the "unitCommand_Kumo_Local" button to test different commands. For the last two, replace "value" with the temperature value you want. Temperature values need to be in Celsius.... I'll eventually do the conversion in the driver.
    • {"mode": "auto"}
    • {"mode": "heat"}
    • {"mode": "cool"}
    • {"mode": "auto"}
    • {"mode": "off"}
    • {"mode": "dry"}
    • {"fanSpeed":"auto"}
    • {"fanSpeed":"superQuiet"}
    • {"mode":"vent", "fanSpeed":"superQuiet"}
    • {"spCool":value}
    • {"spHeat":value}

Let me know if you have any issues. I'll be working on doing some basic testing myself and starting to incorporate the triggering of the local commands into the existing mode change and temperature change commands, making use of the Local Command setting. I also need to work on things like status updates and a few other bits and pieces to make use of all the options made available locally.

Simon

3 Likes

On topic, but off topic.. Kumo is the American cloud service for the wifi modules used in Mitsubishi systems (and some others?)

Can we register Aus delivered ones to the servers there (vpn?) and then use local commands?

Yes I should be doing more reading before asking questions....

It's never stopped me :slightly_smiling_face:

Yes, Kumo is the U.S. service. I wouldn't think we could register, but have never tried. But if you are wanting to do it to get the local control, I would expect that is dictated more by the wifi adaptor than the platform. You're welcome to take a look...

Excellent! Thank you, Simon!

I've got a busy day today but will certainly try to test this. Nice work - more a bit later.

1 Like

Thanks. Later suits me :slight_smile: It's taken me this long, no complaints for me for those who have other commitments compared to testing.

I'll keep working on moving it towards something resembling a completed update, but didn't want to delay it any more than I needed to....

Simon,

I think it may be a few days until I can get to this, between work and spring duties on the property. It's the start of our fifth (and only undesirable) season here in Maine (mud). I spent most of the weekend on the tractor trying to deal with it (soooo much expensive gravel). My wife blew out a strut on the old Volvo SUV, and my Tundra 4WD is getting a workout. She has a new vehicle we won't even back out of the garage for at least a week or two. Worst in 20 years according to the old timers. Anyway, I'll get to it soon, and apologize for not being able to test sooner. I love where I live, but we're seriously thinking of spending March in a warmer climate in the future.

No worries mate, sounds like you have more important things to deal with.

I'm certainly one of those people who is EXCITED to see this update coming to fruition!!!

Quick dumb question before I start... do I need to remove the old drivers (parent and child) before I manually add the new drivers or just simply overwrite the existing ones.

thanks again for all your work on this.

You can just overwrite them. I'll make sure I post here before I release anything via home, in case people have auto updates on.

One thing to note, 'm not sure if the w and c values I talk about are actually being populated, which will cause issues, but still go through the steps, it could be something I am doing...

yea... I'm a bit confused with were these w and c values are ... I updated the drivers, did the refresh, click on a child... and this is now what I have:


Does this look correct to you?

I tried anyway to issue a local command to change the heat point but it doesn't look like it took...

Let me look into it. Thanks for giving it a go

OK... FYI, I noticed I had a syntax error in the command... missing a ' ... I corrected the syntax and still the change didn't happen.