@sburke781 - So... just talked to Mitz about the temp change not working via web browser.
They say that they no longer support the web app. The ecosystem has evolved but the web code has not been updated so will become more and more unstable. Use one of the supported apps they say.
The "good news" is they have an API in the plans for the someday future.... a year or two out... 
In the meantime, Google and Amazon have access to their internal calls, so reviewing/reverse engineering one of their integrations may be a good place to look (they say that, not me!)
Just in case... I did stumble on this from a few years ago. A dude trying to get an Arduino to be the control interface... not directly relevant but theres a bunch of temp control packet discussion in this thread. Doubt it's useful, but sharing is caring! https://github.com/SwiCago/HeatPump/issues/25
Hmmm... That does make things more "interesting".... Not sure how I can intercept the calls Google making. I'll have to think about it.
The one think that springs to mind is whether working towards the ultimate goal of sending the commands locally is still a valid option..... Their cloud-based system may get phased out or replaced, but I couldn't imagine they would update the local firmware on all the systems....
Thanks for thinking of the implications for this project and reporting back.
Actually... Do you know if one of the supported apps us still their Android App? Which was where you could update the temp. That would mean my next steps of hooking the mobile app up to Postman to intercept the temp change just needs to be expanded to include all the other API calls I looked at in the web...
The android/apple apps still work and will continue to be supported (they say).... So that should be a safe dev. route. But...
As for local or not, Can't speak for anyone else, but for me local is still the ultimate goal, (isn't that why most have chosen hubitat? local/not cloud I mean.)
Mitz aren't really a tech company, they seem to change plans and direction like a basic manufacturer, which is fine for a do-hicky maker, one sale then done, but not so much for a product life that evolves with software dev patterns. They don't seem to have any IT sophistication to their development.
I have read, in several places, that the handshake/key generated by the app's first use (via cloud service) is what exposes the local card to effectively listen to local commands without needing to be hooked up to Kumo. In fact (I've read) don't need to have them registered/active in KumoCloud at all. Once the key is in hand,... sounds easy, don't it?
I agree it's extremely unlikely the local card with evolve and any development based on what the local card is expecting to get should be safe from future changes by Mitz. But I'm not a coder, so I'll sit down, shut up and accept whatever I get... gratefully.
Cheers.
1 Like
I have two of these units and would love to try this, but when adding the parent I get an error at line 52 column 4, unexpected token: const
Let me see what I can work out....
Not sure why that code is there. Can you please try commenting out lines 52 to 55 inclusive. If you are unsure about how to do this I will sort it out in a few hours and post back here.
And thanks for testing the code, appreciate the feedback.
Unfortunately commenting out the code wasn't enough, and my brain is not functioning as well as it needs to in order to debug it (been a long day....). If I don't get to take a look over the weekend, I plan to take another look at this late next week.
Sorry for the delays in getting this going....
Simon
The section starting at line 48 in the code from @sburke781 post on Feb 28 is:
def refresh() {
debugLog("refresh: Refresh process called")
// const dict = {};
// const command = {'power':1, 'operationMode':1};
// dict['2456a456c4356']=command;
// debugLog("${dict}");
// Authenticate with KumoCloud Service and
// record Authentication Code for use in future communications
setAuthCode()
createChildACUnits()
The code that I grabbed after that from I'm not sure where is missing a few lines (But I don't get the error and things seem to be 'working' as far as it goes)...
def refresh() {
debugLog("refresh: Refresh process called")
// Authenticate with KumoCloud Service and
// record Authentication Code for use in future communications
setAuthCode()
//createChildACUnits()
1 Like
After that change, I see logs with all the current info for both units!
1 Like
Thanks @bikesquid. I thought I must have commented out the creatChildACUnits and so re-introduced it, but looks like that was not the case
For anyone very keen on testing, I have posted a very early, and most likely buggy, version of the Kumo drivers than can submit some commands to an air conditioning unit, though I haven't actually submitted a command myself.
For those willing to test, please be nearby the unit so you can assess the outcome of various commands, and respond, if needed, using more traditional methods if anything goes wrong.
To test:
You should see child devices linked to the parent device representing each air conditioning unit, shown in the table at the bottom of the Device Edit Page under Component Devices.
- Click on one of the child devices you want to use for testing.
The various buttons shown at the top of the Device Edit Page represent the various commands you can run, however I have only implemented some of these.
- Try any of the Auto, Cool, Heat, On or Off commands, reviewing the Current Logs and the physical response (if any) on the air conditioning unit.
I am particularly interested to know if the physical unit turns on / adjusts the operating mode, what the set temperature displayed on another control mechanism is and does the unit stay on.
- Adjust the mode using the Set Thermostat Mode command, changing the mode to heating or cooling.
- Use either the Set Heating Set Point or Set Cooling Set Point command, in line with the mode set above, to adjust the set temperature. Again, check the logs and the physical unit.
Apologies for the long-winded process. I will post back if I make any changes in the meantime.
Simon
1 Like
@sburke781 Working thu test steps.
- I see no turn off automatic polling option in the parent device. Just on child.
- Followed instructions and got the child devices expected. (did NOT adjust logging from default... explains some of the below blanks.
Drilled down and set a unit to heat. - Unit started heating.
-Tried set Heating setpoint... shows nothing in logs and does nothing to unit.
-Tried a refresh and got"
[dev:581](http://192.168.XX.XX/logs#dev581)2021-04-17 10:36:09.283 am [error](http://192.168.XX.XX/device/edit/581)java.lang.NullPointerException: Cannot invoke method toInteger() on null object on line 160 (refresh)
-Tried setting to Cooling - got nothing from logs but device did enter cooling mode.
- Tried Set Speed - nothing for fan, logs show
[dev:581](http://192.168.XX.XX/logs#dev581)2021-04-17 11:01:59.797 am [error](http://192.168.XX.XX/device/edit/581)java.lang.NullPointerException: Cannot invoke method trim() on null object on line 534 (setSpeed)
- Off, Got Off.
Nice job!
Wanted to get some basic testing back to you....
I can adjust logs if more words helps and rerun whatever you need.
1 Like
Excellent. That is a very good sign to see the commands sticking. Also shows that I don't follow my own test process 
Thanks for working through the testing @bikesquid.
I'll probably next have a chance to take a proper look later tonight, 16 hours or so.
Before you try to set the heating or cooling set points, can you make sure you adjust the mode using the command with the drop down list for mode? You should see a thermostatMode attribute appear on the device page. Laziness on my part to try and rush out the code for testing, all this will be much slicker in the final drivers.
Thermostat mode does seem to work for heating(only thing I had time to test atm) debug log PM sent.
1 Like
Thanks again @bikesquid. I'll go through the results in more detail and do another version later today.
Ok, so based on the results from @bikesquid I feel like I have got the commands correct for adjusting the operating mode, i.e. for cooling, heating and on/off.
I have adjusted the child driver to hopefully address the following:
Adjusting the heating or cooling set temperature - I have capitalised the thermostat mode attribute value so the command sent is now spHeat or spCool. Hopefully this is all that was wrong...
Adjusting the fan mode for auto, low, medium-low and medium will hopefully work. I need to work on the mapping of the fan speeds for the US, they seem to be different once you get higher. The final driver will present these correctly.
I still need to work some more on the refresh process to get status updates, but I am confident of getting this going relatively quickly once I tackle it.
Would be interested to hear any testing feedback.
I know this may seem a little hap-hazard, but at the moment I mostly want to focus on getting the formatting of the commands right and the status updates, then I will move on to a more formal driver that is much more polished and complete.
Thanks again,
Simon
1 Like
@sburke781 - Question - update the child driver based on link in post #73? (I ask cause change history date hasn't changed ni that file). Do we need to delete the device(s) and rebuild,... or what process do you want to see for updating driver(s)?
Hi @bikesquid,
Yes, please use the same link from post 72. I didn't bother updating the change history given I will be throwing this driver away once I am done with this testing and transferring the code I need to another driver, sorry for the confusion.
Simply copy the text displayed when you open the link and paste it into the existing driver on your HE hub. There's no need to re-create devices.
