Support HitachiAirToAirHeatPump (hlrrwifi:HLinkMainController) in Overkiz integration #85781
Comments
|
Hey there @iMicknl, @vlebourl, @tetienne, @nyroDev, mind taking a look at this issue as it has been labeled with an integration ( Code owner commandsCode owners of
(message by CodeOwnersMention) overkiz documentation |
|
You have a very complex device unfortunately. I started porting the device a while ago (#81743), but wasn't able to test and finish it yet. |
|
@home-assistant rename Support HitachiAirToAirHeatPump (hlrrwifi:HLinkMainController) in Overkiz integration |
home-assistant
bot
changed the title
|
Woot, just found out about this issue. I'm still using the custom_component ha-tahoma (deprecated as I saw the recent notice) just because I need this support, so I look forward to see it merged. Keep up the good work, thank you @iMicknl :). |
|
OVP {
"typeId": 1099513069579,
"subsystemId": 0,
"localPairing": true,
"commands": [{
"commandName": "getName",
"description": "Refresh the device internal name\n",
"nparams": 0
},
{
"commandName": "identify",
"description": "Ask the device to identify itself by doing a slight movement or blink or beep\n",
"nparams": 0
},
{
"commandName": "setAutoManu",
"prototype": {
"parameters": [{
"optional": false,
"sensitive": false,
"valuePrototypes": [{
"type": "STRING",
"enumValues": [
"auto",
"manu"
],
"description": "string value (auto, manu)"
}]
}]
},
"description": "Set device mode to auto or manual mode\n",
"nparams": 1
},
{
"commandName": "setHolidays",
"prototype": {
"parameters": [{
"optional": false,
"sensitive": false,
"valuePrototypes": [{
"type": "STRING",
"enumValues": [
"off",
"on"
],
"description": "string value (off, on)"
}]
}]
},
"description": "Set holidays mode\n",
"nparams": 1
},
{
"commandName": "setName",
"prototype": {
"parameters": [{
"optional": false,
"sensitive": false,
"valuePrototypes": [{
"type": "STRING",
"description": "string value"
}]
}]
},
"description": "Change the device internal name. Name length may be subject to restrictions depending on the device and underlying protocol.\n",
"nparams": 1
},
{
"commandName": "globalControl",
"prototype": {
"parameters": [{
"optional": false,
"sensitive": false,
"valuePrototypes": [{
"type": "STRING",
"enumValues": [
"On",
"Off"
],
"description": "string value (On, Off)"
},
{
"type": "STRING",
"enumValues": [
"off",
"on"
],
"description": "string value (off, on)"
}
]
},
{
"optional": false,
"sensitive": false,
"valuePrototypes": [{
"type": "INT",
"description": "integer value"
}]
},
{
"optional": false,
"sensitive": false,
"valuePrototypes": [{
"type": "STRING",
"enumValues": [
"auto",
"hi",
"med",
"lo",
"silent"
],
"description": "string value (auto, hi, med, lo, silent)"
}]
},
{
"optional": false,
"sensitive": false,
"valuePrototypes": [{
"type": "STRING",
"enumValues": [
"auto",
"heating",
"dehumidify",
"cooling",
"fan",
"circulator"
],
"description": "string value (auto, heating, dehumidify, cooling, fan, circulator)"
}]
},
{
"optional": true,
"sensitive": false,
"valuePrototypes": [{
"type": "STRING",
"enumValues": [
"timer",
"manu",
"holidays"
],
"description": "string value (timer, manu, holidays)"
}]
}
]
},
"description": "Manage device\n",
"nparams": 5
},
{
"commandName": "setMainOperation",
"prototype": {
"parameters": [{
"optional": false,
"sensitive": false,
"valuePrototypes": [{
"type": "STRING",
"enumValues": [
"On",
"Off"
],
"description": "string value (On, Off)"
},
{
"type": "STRING",
"enumValues": [
"off",
"on"
],
"description": "string value (off, on)"
}
]
}]
},
"description": "Set device main operating mode\n",
"nparams": 1
}
],
"states": [{
"name": "AutoManuModeState",
"type": "DiscreteState",
"eventBased": false,
"persistent": false
},
{
"name": "HolidaysModeState",
"type": "DiscreteState",
"eventBased": false,
"persistent": false
},
{
"name": "NameState",
"type": "DataState",
"eventBased": false,
"persistent": false
},
{
"name": "StatusState",
"type": "DiscreteState",
"eventBased": false,
"persistent": false
},
{
"name": "TargetTemperatureState",
"type": "ContinuousState",
"eventBased": false,
"persistent": false,
"prototype": {
"valuePrototypes": [{
"type": "FLOAT",
"minValue": 12.0,
"maxValue": 30.0,
"description": "float value between 12.0 and 30.0"
}]
}
},
{
"name": "DiagnosticCodeState",
"type": "DataState",
"eventBased": false,
"persistent": false
},
{
"name": "FanSpeedState",
"type": "DiscreteState",
"eventBased": false,
"persistent": false
},
{
"name": "FilterConditionState",
"type": "DiscreteState",
"eventBased": false,
"persistent": false
},
{
"name": "FilterResetState",
"type": "DiscreteState",
"eventBased": false,
"persistent": false
},
{
"name": "HLinkVirtualOperatingModeState",
"type": "DiscreteState",
"eventBased": false,
"persistent": true
},
{
"name": "MainOperationState",
"type": "DiscreteState",
"eventBased": false,
"persistent": false
},
{
"name": "ModeChangeState",
"type": "DiscreteState",
"eventBased": false,
"persistent": false
},
{
"name": "OutdoorTemperatureState",
"type": "ContinuousState",
"eventBased": false,
"persistent": false
},
{
"name": "RemoconControlState",
"type": "DiscreteState",
"eventBased": false,
"persistent": false
},
{
"name": "RoomTemperatureState",
"type": "ContinuousState",
"eventBased": false,
"persistent": false
},
{
"name": "TemperatureChangeState",
"type": "ContinuousState",
"eventBased": false,
"persistent": false
},
{
"name": "ThermoStatusState",
"type": "DiscreteState",
"eventBased": false,
"persistent": false
}
],
"controllableName": "ovp:HLinkMainController",
"uiClass": "HitachiHeatingSystem",
"uiProfiles": [
"ThermostatTargetReader"
],
"uiWidget": "HitachiAirToAirHeatPump",
"controllableType": "ACTUATOR",
"protocolType": "OVP"
}HLRRWIFI {
"allResult": true,
"devicesTypes": [
{
"typeId": 655360,
"subsystemId": 0,
"localPairing": false,
"commands": [
{
"commandName": "globalControl",
"prototype": {
"parameters": [
{
"optional": false,
"sensitive": false,
"valuePrototypes": [
{
"type": "STRING",
"enumValues": [
"off",
"on"
],
"description": "string value (off, on)"
}
]
},
{
"optional": false,
"sensitive": false,
"valuePrototypes": [
{
"type": "INT",
"description": "integer value"
}
]
},
{
"optional": false,
"sensitive": false,
"valuePrototypes": [
{
"type": "STRING",
"enumValues": [
"auto",
"high",
"low",
"medium",
"silent"
],
"description": "string value (auto, high, low, medium, silent)"
}
]
},
{
"optional": false,
"sensitive": false,
"valuePrototypes": [
{
"type": "STRING",
"enumValues": [
"auto",
"circulator",
"cooling",
"dehumidify",
"fan",
"heating"
],
"description": "string value (auto, circulator, cooling, dehumidify, fan, heating)"
}
]
},
{
"optional": false,
"sensitive": false,
"valuePrototypes": [
{
"type": "STRING",
"enumValues": [
"both",
"horizontal",
"stop",
"vertical"
],
"description": "string value (both, horizontal, stop, vertical)"
}
]
},
{
"optional": false,
"sensitive": false,
"valuePrototypes": [
{
"type": "STRING",
"enumValues": [
"off",
"on"
],
"description": "string value (off, on)"
}
]
}
]
},
"description": "p1: Main operation => on|off\np2: Temperature in Celsius\np3: Fan speed => auto|high|medium|low|silent\np4: Mode => auto|heating|dehumidify|cooling|fan|circulator|leaveHome\np5: Swing => stop|vertical|horizontal|both\np6: Leave home => on|off\n",
"nparams": 6
}
],
"states": [
{
"name": "FilterConditionState",
"type": "DiscreteState",
"eventBased": false,
"persistent": false
},
{
"name": "ProductModelNameState",
"type": "DataState",
"eventBased": false,
"persistent": false
},
{
"name": "RSSILevelState",
"type": "ContinuousState",
"eventBased": false,
"persistent": false
},
{
"name": "TargetTemperatureState",
"type": "ContinuousState",
"eventBased": false,
"persistent": false,
"prototype": {
"valuePrototypes": [
{
"type": "FLOAT",
"minValue": 12,
"maxValue": 30,
"description": "float value between 12.0 and 30.0"
}
]
}
},
{
"name": "DiagnosticCodeState",
"type": "DataState",
"eventBased": false,
"persistent": false
},
{
"name": "FanSpeedState",
"type": "DiscreteState",
"eventBased": false,
"persistent": false
},
{
"name": "LeaveHomeState",
"type": "DiscreteState",
"eventBased": false,
"persistent": false
},
{
"name": "MainOperationState",
"type": "DiscreteState",
"eventBased": false,
"persistent": false
},
{
"name": "ModeChangeState",
"type": "DiscreteState",
"eventBased": false,
"persistent": false
},
{
"name": "OutdoorTemperatureState",
"type": "ContinuousState",
"eventBased": false,
"persistent": false
},
{
"name": "RemoconControlState",
"type": "DiscreteState",
"eventBased": false,
"persistent": false
},
{
"name": "RoomTemperatureState",
"type": "ContinuousState",
"eventBased": false,
"persistent": false
},
{
"name": "SwingState",
"type": "DiscreteState",
"eventBased": false,
"persistent": false
},
{
"name": "TemperatureChangeState",
"type": "ContinuousState",
"eventBased": false,
"persistent": false
}
],
"controllableName": "hlrrwifi:HLinkMainController",
"uiClass": "HitachiHeatingSystem",
"uiProfiles": [
"ThermostatTargetReader"
],
"uiWidget": "HitachiAirToAirHeatPump",
"controllableType": "ACTUATOR",
"protocolType": "HLRR_WIFI"
},
{
"typeId": 8589934592,
"subsystemId": 0,
"localPairing": false,
"commands": [
{
"commandName": "getName",
"description": "Refresh the device internal name\n",
"nparams": 0
},
{
"commandName": "setName",
"prototype": {
"parameters": [
{
"optional": false,
"sensitive": false,
"valuePrototypes": [
{
"type": "STRING",
"description": "string value"
}
]
}
]
},
"description": "Change the device internal name. Name length may be subject to restrictions depending on the device and underlying protocol.\n",
"nparams": 1
}
],
"states": [
{
"name": "LocalModeState",
"type": "DiscreteState",
"eventBased": false,
"persistent": false
},
{
"name": "NameState",
"type": "DataState",
"eventBased": false,
"persistent": false
}
],
"controllableName": "hlrrwifi:HLRRWifiBridge",
"uiClass": "ProtocolGateway",
"uiProfiles": [
"Specific"
],
"uiWidget": "HLRRWifiBridge",
"controllableType": "PROTOCOL_GATEWAY",
"protocolType": "HLRR_WIFI"
}
]
} |
|
Hi Mick, What is the status of this change? When can I start using it? Best regards, Chris |
|
@Chris-NL no ETA. I currently don't have time. |
|
Ok, no worries. I'll wait. Thanks for the support. |
|
@chabou-san which device do you own? I am looking for users of the |
|
I believe I have the HLRR version. How can I be sure ? |
|
@chabou-san on your device page, it should list 'hardware'. You can there also download your diagnostics. |
|
@iMicknl Thanks for the info, I can confirm that I have |
|
Do we have anyone here with the ovp hardware version? @Chris-NL, do you want to help testing some stuff? |
Hi there, I have 4 units with hardware name "ovp:HLinkMainController" |
|
Hi iMicknl, I have a test-instance of HA where I can install something like this. Can you please tell me the steps on how to download and install your testversion in my test-instance? P.S. I don't use discord. |
|
Perhaps you can use https://github.com/alandtse/pr_custom_component (see instructions) and use |
|
I've installed the PR Custom Component and added an integration with the PR link. I can't seem to find where it asks me for my Tahoma username and password, only configuration items are Binary Sensor enabled, Sensor enabled and Switch enabled. Am I missing something? |
|
@Chris-NL, if you remove your current Overkiz entry, you should be able add a new one which is called something like I haven't used this method myself, but many other did use this with success. |
|
That was the last step was missing. Thanks it works. I can also now see the airco's with all options. But clicking on one of the options (eg. cooling icon for example) gives me the following message: |
|
@dotvav FYI |
|
Great, thanks for testing this. I will look into that error it this week. Could you download the logs of the component and share? |
|
config_entry-overkiz-89823676d993f69d576c3e9340ae1ec4.json.txt Attached file contains the downloaded diagnostics of the "Custom Overkiz PR#95706" integration. |
|
The error message is confusing:
Testing with my device I find that API error responses are not reliable: when an unexpected value is passed to one of the parameters, the API may complain about another parameter which was correct. So I am not too worried about point 1. Point 2 might similarly be a bad error reporting from the remote API. @Chris-NL when you operate your AC unit from the remote controller or mobile app, do you see the state change in HomeAssistant? Can you put it on and, then, test the HomeAssistantcontrols one by one until you find which one is having a bug? Otherwise, what may help is if you use the hi-kumo web app and record the network traffic with your browser's developer tools so I can compare it with what HomeAssistant is producing. |
|
Hi Dotvav, Thanks for your investigation. I did some tests as you requested. All changes to the AC with the remote are reflected in HomeAssistant except for the Auto mode (the one I onle use ;)). Trying to change something to the AC via HomeAssistant at any stage gives me the same error message (or at least they look the same). I don't have the hi-kumo app. I'm using these AC's on the Somfy Tahoma box with the Somfy App. Hope this helps. Let me know if I need to test more. |
|
OK, that's helpful. Comparing your diagnostic and mine is showing something that is aligned with what you say. It looks like the operation mode on the OVP protocol (your device) has one less possible value than on the HLLRWIFI (my device) and the ones in common have slightly different spellings. OVP: HLLRWIFI:
I am going to double check the rest of the parameters and then I'll update the CR in the coming days. I will need you to test again when I am done. |
|
There are a lot of options on the device, most of them I don't really use. So I've seen that the Somfy App for the Tahoma Box that currently drives the Airco units do have a Timer and Holiday function, but they don't seem to work. The remote (Hitachi RAR-6N2) is very complex (see pictures on https://nl.aliexpress.com/item/32813227923.html) and we only use them to turn airco on (on auto mode at certain temperature) of off again. In winter sometimes on heating mode. So to answer your questions:
Maybe an option to leave the holidays function out of it? What should that do anyway? Any logic related to holiday would come from HA right? Just as the timer. Als long as I can turn the units on and off, set the mode,, set the temperature, maybe also control the swing and strength of the blower I have all I need. Hope this helps. |
|
It does help. Though, Hitachi/Overkiz have made things extremely confusing. I've got pretty much the same remote controller. It has 2 swing mode buttons, 1 for horizontal and 1 for vertical. If your unit does only vertical, then I wonder what the horizontal button does. Also, your diagnostic file says nothing about swing mode. If you enable the swing mode, does it reflect on HomeAssistant? |
|
See below a photo of my remote. I only have a swing button. The unit does have something to direct the air horizontal, but that seems to be fixed inside the airco. Don't see any option to change the horizontal airflow. Don't see the swing reflected in HA when I turn it on or off. These are the attributes according to HA (dont know what supported_features: 25 mean) This is a photo of my remote. |
|
Hi @Chris-NL, I feel like I have a fix. If it works, the code will probably need a clean-up before it is merged into HomeAssistant, but at least we will know. Feel free to refresh the PR again and test whenever. Thanks. |
|
There's some serious improvement! Hopefully we're getting closer each time :) When I clicked the auto mode button I got the error (I included the details from the log below): But clicking on cooling, dehumidify, fans, heat or off all work now. I also tested the fan speed: also works. There's also a function called "preset" with the values none or holiday mode. I can select holiday mode and I can also see a change in the Somfy app. I turned it on while the airco was cooling, nothing else happened, so I don't know what this function does. So if you could get the auto mode to work I think we're there. One other minor thing I wanted to mention is the screenshot below. Don't know if it has anything to do with testing, but the labels for the fields are some placeholders: From the logs: [140240945708224] {'errorCode': 'UNSPECIFIED_ERROR', 'error': 'Managed action group is invalid : When setting auto ModeChangeState, TemperatureChangeState should be an integer, included in [-5;5]'} |
|
It is encouraging and enraging at the same time. It looks like one of the parameters is the "target tempereature" in most of the modes, but when you swith to auto, this parameter becomes "temperature change" and needs to be an integer between -5 and +5. Do you have any idea what this value range could mean, is there any operation property that you can set to something beween -5 and +5? I think I can find a way to keep the current operating "temperature change" hidden, but I wonder if this is something that can/should be controllable in HomeAssistant. |
|
I know I'm kind of intervening from nowhere but I'm actually following actively this PR. :) This "temperature change" range kind of makes sense regarding the behaviour we're getting from the remote controller @Chris-NL mentioned (that I also have). As a side note at home, I have 2 kind of remotes :
So I guess the behaviour you seem to try to understand is based on old devices from Hitachi where the range was different. Regarding your last question, I have my opinion on this, but I'm not one to decide : HomeAssistant may not have to mimic exactly the behaviour of the devices it controls. |
|
Excellent @chabou-san. Thanks for commenting, that helps a lot. I have just pushed an update that may (or may not) fix the issue. I am curious what HomeAssistant is going to show in the temperature gauge in case it works 🤞 |
|
When I look at the Somfy App, there is a difference in temperature range between the auto mode and the other modes. The auto mode allows me to select a temperature between 22 and 28 degrees. The other modes (except fans only mode, no range there) have a range between 16 and 32. Hope this helps. What I also don't understand in the Auto mode is this: let's say the room temp is around 23 degrees and I want to cool it around this temperature. It could happen that the Airco switches itself into heating. I can turn the temperature down, but the airco doesn't switch from heating to cooling (only indicator for me when this happens is that the Somfy App shows me a red dot instead of a darkblue dot). To resolve this issue I have to switch the airco off. Set a lower desired temperature (21 degrees for example), turn is back on in auto mode and increase the temp back to 23. I think this defeats the whole idea of auto function, but apparently this is how Hitachi designed it. And it's even worse if another one of the split units is still on, then I have to turn them all of first to switch the unit from heating to cooling. But I'm so used to set it to auto, don't know why though :) For your update. Still doesn't work. No functional change, still an error on the Auto function. The logs give me: [140620537931200] {'errorCode': 'UNSPECIFIED_ERROR', 'error': 'Managed action group is invalid : When setting auto ModeChangeState, TemperatureChangeState should be an integer, included in [-5;5]'} |
|
Apologies, I had not properly synced my change. You can try again now. |
|
No luck, same status. Logbook: [140538794265408] {'errorCode': 'UNSPECIFIED_ERROR', 'error': 'Managed action group is invalid : When setting auto ModeChangeState, TemperatureChangeState should be an integer, included in [-5;5]'} |
|
OK. I am not able to debug this here. It would help if you (@Chris-NL or @chabou-san) could join the Discord server and/or ping me there (username dotvav). I can let you know how and what http traffic to capture with your browser and then share with me, and we can make a few tests. That would allow me to observe the real command parameters instead of trying to guess (and failing). |
|
I could, but I’m on hlrr protocol, not ovp. So I can’t reproduce the errors @Chris-NL is having. |
Alright. I have hlrr too and I can test my own devices. Don't hesitate to test yours too and let me know if you find any bug. I have talked with @iMicknl and we think these 2 protocols are too different, after all, and they don't belong together in the same class file. It makes development and support unnecessarily complex. We can deliver support for hlrr earlier without clubbing it with ovp, and we can work on ovp support shortly. I'll keep this thread informed on the progress, but it might take some time (because I need to travel for work) and I don't think it will be done in time for the October release of HA. @Chris-NL if Discord doesn't work for you, please let me know if there is a medium (instant messaging, bulletin board) where we can connect privately to share information that don't belong in this thread. |
|
All sounds plausable. I had to create an account with discord and I've send you a friendship invite through it last Sunday, no response yet. Not familiar with Discord, maybe I'm doing something wrong. |
|
Updating this thread. @Chris-NL and I have made a lot of progress "offline". I think we have the protocol almost figured out, and a version of the component that doesn't crash. But it is still missing an important feature: changing the temperature in HA when the mode is AUTO. In particular, we might be able to figure out what the "pivot" temperature is on his device (seems to be 23), but I don't know if it is the same on all the (OVP) devices. |
|
Hi @Chris-NL. When you have a moment, please test this integration again on your device and let me know if you find an issue. |
|
Hi, thank you to all which are actively working to solve or better, add some additional features to the "overkiz" implementation for HA. |
|
Thanks for the feedback @jkrasinger. The difference that you are observing is totally unintentional from my part. It is hard to tell right now if one option is better than the other, or if there are solid expectations. It makes me curious so I'll have a look and see if that could be the sign of a hidden bug. Regarding the HA integration, I'd love to have it in the next release cycle. I'm pretty confident about HLRR so I'll try to get that out. OVP needs more work and if I don't finish it in the next few days, I will extract it from this PR and submit it again later when it works. |
|
@dotvav : Thank you for the quick reply. I am curious if the code will be implemented in the next release cycle, would be very nice, then I could remove the add-on again and use overkiz. As for the difference between overkiz and aasivak it would be good for me personally if the behavior was the same, but is not really important. I would then have to change a little code in my ESP32 remote control (via MQTT and HA) for the air conditioning. Thanks again for your work! |
|
@jkrasinger I have found the root cause of the discrepancy. The code is a little bit more consistent with the fix, so it's a good thing. @Chris-NL I have refactored the code and possibly elminated the bug you have encountered. Feel free to test again. |
|
@dotvav I agree with you that this is a good thing. But there is one more question to this behaviour: if the heater is off and i change the target-temperature, what (mode) will be switched on, the "heater", the "cooler" or the "dryer"? Is there a specification for this, is this depending on temperature (like any automatic state) or whatever? Do you have an answer? As i'm only using the heater and never the cooler this is of real interest for me. Thanks |
|
Hi @jkrasinger, there is no specification. And there is no reason that the unit should change state (ON/OFF) or mode (cool, heat, dry...) when someone changes the target temperature. There was a bug in the overkiz integration that was forcing the unit to ON when one would change any other value. I have fixed it. Now, there is a major difference between the way HA and Overkiz are managing climate entities. Overkiz allows the main operation state (ON/OFF) and the hvac mode (cool, heat, dry...) to be managed independently, while HA considers both a single sate (off, cool, heat, dry...). But that doesn't force us cut too many corners, and changes to the target temperature, fan speed or swing mode should not turn the unit ON anymore. |
|
Hi @dotvav thank you for the good news, sounds perfect. I will again take a closer look for me on the behavior with my ESP32 Box and my "pyscripts" 👍 |
|
Hi there, The first PR, that will bring support for HLRRWIFI devices, is in review here: PR 95706. Hopefully, we manage to get it in the next release. I have also been working on the OVP protocol on a separate branch: https://github.com/dotvav/home-assistant-core/tree/overkiz-hitachi-air-heat-pump-ovp . It still requires some testing, but I should be able to make another PR soon out of it. |
The problem
I'm using the overkiz integration to integrate my Somfy Tahoma Pro box (firmware 2018.24.4.7). This has 2 positionable horizontal awnings, 2 sensors and 4 split unit air conditioners of Hitachi connected to it.
The overkiz integration adds the airco units as HitachiAirToAirHeatPump devices, but I only see one disabled entity for each airco (button.airco_1_start_identify). I can't seem to use them on any of the dashboard or automations.
I'm not sure if I'm doing something wrong, maybe there is a solution for the problem.
What version of Home Assistant Core has the issue?
2023.1.2
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant OS
Integration causing the issue
overkiz
Link to integration documentation on our website
https://www.home-assistant.io/integrations/overkiz
Diagnostics information
config_entry-overkiz-9a960f4ff17ee791f14ce8da40a9d67d.json.txt
Example YAML snippet
No response
Anything in the logs that might be useful for us?
No response
Additional information
No response
The text was updated successfully, but these errors were encountered: