Sure. I know that. It's just the VRF units like these make a lot of decisions on the delta-T between ambient temp and target temp. It has no good way to know what the temp in a bedroom is with closed doors compared to the air inlet temp when coming from a hallway. That's why they sell the kumo sensors to deal with this.
Those sensors are $50 plus, so pricey, esp if you have existing sensors in the room anyway.
Thanks for looking into this!
Maybe I ain't understanding the setup u have, but even if the unit knows the temp in the room, with the doors closed to the return, and no clear path for the air to return to the unit your killing any gains in efficiency the unit can provide with pump stages and fans. The whole system (other rooms in the zone) will provide competing #'s or air. Mitz units like to be ticking over nearly at idle for best efficiency. Just a gut response, but it feels like letting the unit manage as best it can with unit internal temp sensor and just switching the whole unit off when the "target" room is reporting back to HE (with the sensors you already have) via a rule is likely just as efficient. Of coarse you can add a cheap door sensor and have one logic for door open (leave it up to unit) and when door closed set your rules accordingly to turn it on/off as the room demands. An alternative (this is how I solved the issue in my similar setup) put return ducts in each room instead of hall. Sorta a DIY project that's sounds scarier than it is... in some cases. 
P.S. @sburke781 Dude, U me newest hero! A couple weeks in and nothing weird yet. The temp #s (in the correct units, F) are funky decimals, but thats just a format isssue... units responding impressively quickly. Are you testing for/getting confirmation messages from Mitz that command accepted, etc? i.e. how do you know they done did hear ya? I ask because it looks instant on dashboard display and I'm wondering if that's an assumption it went through...
These units are the big ducted ones that serve hallways and rooms. Agree if it's just one room with the intake somewhere else you have pressure problems, though the doors in our rooms usually have an inch of space at the bottom to prevent that problem.
In this case, there is a ducted unit (like this one: Mitsubishi PVA-A36AA7 - 36k BTU - P-Series Multi-Position Air Handler) that serves my office as well as a couple bathrooms and laundry room. Given the computers I have in the office and that I am working from home for an extended period of time, I care very much that the office temp is the temp the system is adjusting for. 
Yup, understood the unit you reference. Problem is that as soon as you close the door you stall most of the airflow. The idea that forcing the unit to see that rooms temp instead of the whole system average (return sensor) wont make it any more efficient as its still (an assumption) getting the air from the other rooms with doors likely open?. The average air the unit is actually heating/cooling will not be what its expecting from a thermostat in the closed room. It will run pretty inefficiently with lots of starts/stops, likely over heating or cooling often due to minimum run times to protect the compressor, etc. I suspect it would be more efficient to use your zwave temp sensor to on/off the unit based on your comfort, and let the internal temp sensor manage the rest.
These Mitsubishi units are not like normal systems. The indoor units generally never go completely off fan wise, to keep airflow fresh, and they don't do on/off - they have variable refrigerant flow via a scroll inverter, so the compressor can run at 10% load and then spool up if multiple indoor units all have large delta-T to try and handle.
And the indoor units are 220V units wired from the outdoor unit from a power supply POV. There is no outlet these things plug into, at least not mine - they are wired into a bus with it's own set of breakers.
I do this already with Mitsubishi thermostats, but they are a pain to program. I am hoping the Kumo system will make that programming easier, and give me nice HA integration as well.
Having installed such units in the past myself, I do understand their basic operations.
Just trying to give some info to help you out. The discussion is probably more fitting in an hvac forum. 
I'm no HVAC guy, so can't comment on the pro's and con's for what you are wanting to do in terms of it's affect on performance / efficiency, I'll leave that for those who have experience in that aspect.
In term of the tech side of things, I haven't seen anything for feeding in temp reading in other examples that people have developed on other HA platforms. My understanding is that the API is not documented and so many developers monitor the traffic from the Kumo app / web site to reverse engineer the calls required. Given that I have not seen anything in the Kumo app / site for this, I wouldn't think there is an option available for us to add to the drivers.
Just on my question / suggestion for using temp sensors in HE rules as an alternative, I would add a minor warning on using battery powered sensors. If the battery runs out or comm's are lost, then you would need to account for this in any logic implemented in rules. I know this isn't where you were
heading, more so for anyone else who may consider this option.
So my unprofessional opinion suggestion would be to look at the Mitz sensors, I think... Sorry, I'm just the programmer....
Simon
Thanks mate, glad you had a good start. Things were a little rocky for some, I think you judged the wave well!! (Don't get too excited, I'm no surfer, even though I live on the coast....)
Yeah, for a U.S. focused platform was a little odd how they still chose to operate in Celsius, so the conversions are a little ugly. Would like to tidy it up at some point, but not high on the list at this stage.
It feels like I had half a dozen goes at how to tackle this... at least in my head...
You are right, the local representation of the commands you issue are represented in HE immediately (I think) in all cases (in device attributes and on dashboards), but there can be a lag in that taking effect on the unit. In the last round of issues / fixes I was doing, for temperature in particular, I introduced a check for a timestamp returned with the periodic status updates you can configure in HE, if the status info is dated before the last command I do not apply the updates. That was looking successful in many cases, but there was one instance where it didn't, so can't say for certain it works every time, but I decided to leave it in.
All that said, I do want introduce more checks for comm's being maintained and commands taking effect. But there is little feedback from what I can see, apart from checking the status of the unit. I'm probably at the point of getting things working, tick, dealing with issues people have, tick , plus adding a few key features, lcoal control, vanes, etc, then I'll look at refining the drivers down the track with better error handling and other minor tweaks.
Simon
Simon, thanks for looking! Is the protocol used to the Kumo similar to the serial protocol used off the CN105 connector? If so there is a way to set the temp, as that's how the Mitsubishi thermostats communicate with the unit.
The other approach I was thinking about is to use an ESP32 and this code base; https://github.com/SwiCago/HeatPump . The kumo wireless adapter does allow a hardwired thermostat be plugged into it via the CN105, so I could use an ESP32 to pass the ambient temp that way. It's a lot more work, but would definitely accomplish what I am looking to do.
Of course, I could just buy the Kumo wireless sensor and be done with it too.
Wow, I thought I would have seen this comment come through, apologies @mbm881, I'm only 3 months late....
I can't say I am familiar with the U.S. hardware... hopefully others can comment on this....
I have done the hard work (I think) on the local control for those using the Kumo app, I just need to integrate it into the drivers, so hopefully I might have an early Christmas present...
Ooh! Ooh! In. Count me in. Thanks, and hope you're well. Emphasize having a nice holiday more than this, though. The Kumo Cloud is at least far more reliable than most, I've found. But if you do develop it and want a US tester, I'm happy to give it a whirl.
Was worried I would enccourage interest..... 
Glad your interested... hopefully in the next week or two I will push aside some of my distractions and finish what I started
Now that things are heating up in the states, I'm wondering if there is any hope of revisiting this. I don't know if it helps at all but the URL I can log into using my app credentials is https://app.kumocloud.com/#/login which gives me full control of the mini-split through a web interface. Thanks!
@tomw if you're looking for another opportunity to make a driver based on HTTP protocols, this might be up your alley 
Thanks for the shout-out, but I am currently working on a different thing. Maybe @sburke781 would be willing to pick it back up.
I thought I had posted a link to my driver's here ... I developed drivers for Kumo (US), MELCloud (Europe) and MELView (Aus / NZ).
The drivers work with the Kumo Cloud service, and I have made a start on local control. They are available for install on HPM (at least on the old version of HPM, I haven't looked at the new one yet).
Let me know if you decide to give the drivers a go and how it turns out.
I’m so sorry, I didn’t see those! I will install them and check them out ASAP! Thank you so much!
I can verify that the driver created by @sburke781 is a useful addition to HE for those who use Kumo Cloud. It doesn't allow for as much control as the Mitsubishi app (which, for a cloud-based app, is excellent) so I don't really use HE to make changes very often, but Simon's work certainly allows one to turn the unit on and off and set basic temp changes, which can be handy. Simon has done some great work in this area and local control would be a huge advancement.
Can confirm - the drivers worked great!
Download the Hubitat app
