Can Faiking set the demand control of the outdoor unit?

[MUN0X]

Hi!
I currently run a daikin multi-split with 4 units connected to home assistant
3 of them are running on the BRP069B4x module, the 4th one has a BRP069C4x module.
I ordered a faikin module that will replace the C-module to get rid of the cloud dependency.

However the integrated controller with an external BLE sensor makes me wonder whether I should replace my B-modules as well.
I currently have several automations running in Home assistant to change the setpoints of the daikin units based on external temperature sensors. However, it would be nice to have the standalone system of faikin in case Home assistant goes down (or my automation f*cks-up 😊). One of my automations limits the power draw of the outdoor unit depending on the outside temperature to get a smoother temperature control (essentially forcing the compressor frequency down, mostly to 15-20hz). I do this via the “set_demand_control” command in the daikin api.

Is it possible to do this via the Faikin controller as well?
I looked through the manual and the discussions but couldn't find a clear answer

[revk]

I have not made any system to link the Faikin together to do something like that - obviously it may be possible, but generally I have assumed that such integration would be done by HA or similar.

But if the Daikin API has it, it may be worth considering - do you know what that actually does in practice?

[MUN0X]

I'm sorry if I didn't make myself clear.
My goal is not to link the faiking modules together and agree that you should use home assistant for that.
Having home assistant set a desired setpoint for the automated controls of each faikin module and then letting the automated controls of the faikin modules do their (independent) thing is exactly what I'm after.

The thing is that the genuine daiking modules (BRP069B4x) allow me to send a REST command to the outdoor unit to limit its power draw.
By doing so i make the outdoor unit less "aggressive" and make the temperature control of the indoor unit much more gradual.
This is especially useful when is it for heating with only 1 or 2 out of 4 indoor units switched on. Without this restriction one active indoor unit would turn the outdoor unit off/on with 5-10min intervals where the outdoor unit would draw ~2000W intermittently. By limiting the power draw of the outdoor unit down to approx ~500W this behavior stops and the outdoor unit will stay on for 30+min at a time. This is much more comfortable and improve the efficiency of the system quite a bit.

To do this i pass the following command to my B-modules. They seem to pass it on to the outdoor unit because the C-unit, which i can’t control via the local API, respects the imposed restrictions.
http://IP/aircon/set_demand_control?lpw=&mode=0&suc=0&moc=0&tuc=0&wec=0&sac=0&en_demand=1&frc=0&max_pow=40&type=1&thc=0

Based on my own testing the parameters are the following:
-En_demand:
0 = Restrictions off
1 = Restriction on
-Mode:
0 = manual restriction
1 = unknown, but I suspect this enable the schedule set by the days
2 = automatic, not sure how it works exactly. it respects a limit at some times, does it’s own thing on other occasions (doesn’t work well)
-Max_power: max power (%) of the outdoor unit.
Any integer between 40 en 100 seems to be accepted.
-Moc, tuc,…, suc = weekdays, I guess to set a weekly schedule but I’ve never used it.
-Type = unknown, default is 1

To be clear you can also set these restriction via the app but using the REST commands via home assistant makes it much more useful.
The default demand control presets in the (old) app translate to:
OFF = http://IP/aircon/set_demand_control?lpw=&mode=0&en_demand=0&max_pow=70&type=1
LOW = http://IP/aircon/set_demand_control?lpw=&mode=0&en_demand=1&max_pow=40&type=1
MED = http://IP/aircon/set_demand_control?lpw=&mode=0&en_demand=1&max_pow=50&type=1
HIGH = http://IP/aircon/set_demand_control?lpw=&mode=0&en_demand=1&max_pow=70&type=1
AUTO = http://IP/aircon/set_demand_control?lpw=&mode=2&en_demand=1&max_pow=85&type=1

[revk]

OK, basically we need to find the S21 messages that result from this setting. If we can find that, then easy to add.

This means dumping the serial messages from that controller.

[MUN0X]

Just to illustrate what I mean:

This is with 2 - 4 units active throughout the last 24hrs. I switched the max_power value manually at certain times to illustrate the behavior.
In normal operation it would have stayed between 50% and 70%.
As you can see my heating was initially running fine at 50%. Running constantly at a power draw of ~700w with a comp freq of 25hz.
By lowering the max_pow to 40 these numbers dropped to ~500w and 20 hz. This was too low with these outside temperatures and the temperature in my largest room started to drop.
I then increased the power back to 50%, then 70% and finally to 100% by disabling the en_demand function.
As I increase the power limit you can see the power draw and frequency becoming erratic as the indoor temperatures approach and surpass their setpoint (20°C). Finally the outdoor unit switches off until the room temperatures drop below 19.5°C again.
These temperature swings and on/off behavior gets much worse with only 1 room active and mild temperatures outside (it was -8°C outside)

hope this helps to explain what I'm trying to achieve :)

[JeanOlivier]

Just to add here that this feature would be very convenient. My units tend to run the compressor slow and they can't keep up. Being able to ask the compressor to be more aggressive would be very helpful.

@MUN0X if you can debug this that'd be great.

[revk]

Today has been mental, so will look tomorrow.

[Raspdomo]

@MUN0X : "If you have a multi-split, the outdoor unit appears to respect the LOWEST max_pow value set by any of the internal units."
That is exactly the opposite of what Daikin documents: "if one indoor unit is set on 80% and another is set on 50%, then the outdoor unit will work on 80% capacity" (free translation from Dutch :-).
Also, in my experience the Daikin Onecta app does not set the max_pow on all units that are registered in the app. I have to set both en_demand and max_pow separately on each unit.

I tend to believe your real life observations more than the often incomplete and unclear Daikin doc, but still: are you sure ?

Me too I have one cloud-only indoor unit on my multisplit, and it would be so nice if it would just "follow" the units that I can control through LAN (kind of slave mode) - or at least not impose its demand control settings over the other units. Otherwise there's no use of implementing this in my home automation system (Domoticz on Raspberry) - though I'd very very much like to !

[MUN0X]

I'm pretty sure that how it used to work. However, your "vrije vertaling" might be correct in the meantime.
You see back when i set up my system the Onecta app was brand new. Back then the onecta app was used to setup the new cloud-based units while the older local controllable could be set up via the now obsolete "Daikin online controller" app.

The old app had demand control as a global setting in the app. Upon changing it the app would send a command to every unit that was registered in the app. Of this I'm 100% sure, I determined this by snooping the wifi traffic when toggling the setting. That's how i got the urls/commands that I gave in one of my initial posts.
The onecta app didn't even support the demand control functionality at that time.
So your last question was also my concern at the time. But yes, when you turn off "demand control" for the cloud unit it will respect the limit that is set by the LAN controllable units. In fact that's how I've been running the system for years now. (from my experience one of the LAN units must be briefly switched on for a change to the demand control, sent to the LAN controllers, to be applied when only the cloud-based unit is running)

This lead me to believe that the units would respect the lowest setting. (I remembered i tested this back then and that theory held up as far as I remember). In the end I kept using the logic of the old app via home assistant and just applied the demand control on all LAN controllable units simultaneously.

In the meantime a lot has changed. The Onecta app now contains the option to change the demand control. And the older LAN controllers have received multiple firmware updates making them compatible with the Onecta app. In the onecta app you can now change the demand control of the old units individually. Perhaps these firmware updates changed the behavior of the LAN controllers when setting demand control?

[Raspdomo]

Thanks for your elaborate answer ! I'll test it for myself and report back.

In my home automation system it's the only missing functionality - after that I can get rid of Onecta. I don't want to lose the local LAN API so I don't want any further firmware updates (these come via Onecta).

Anyway, Faikin seems to be a great alternative whenever needed. @revk: many many thanks to share Faikin with the rest of the world !!!

[Raspdomo]

I can confirm that my cloud-only unit with demand control set to off does not impose its setting on the whole system. I have to add that my cloud-only unit is switched off (don't know what would happen when it is switched on) - but that doesn't bother me as I rarely use it. The demand control setting on the non-cloud units are taken into account by the outdoor unit ! For me that unblocks the last step of my automation - thanks to @MUN0X !

Just for information
Whilst testing the demand control automation I bumped into the following. In Onecta the demand control can be set manually in steps of 5%.
The set_demand_control max_pow parameter allows any value (within range), the indoor unit accepts it as can be demonstrated with get_demand_control. However if the value is not a multiple of 5 (e.g. 77) the demand control setting of the indoor unit simply disappears completely in Onecta (I admit I that this got me got a little worried :-) ! It reappears when a multiple of 5 is set (e.g. 75) with a set_demand_control.
To me this seems a quirk in the Onecta user interface.

[turbolooser]

That sounds awesome. Great work

[revk]

Change your otahost, e.g. setting/Faikin/otahost excalibur.belmont.cymru and upgrade, to get the test version. I should have one to try in a few minutes.

[revk]

OK, test release ready for people to try.

[revk]

We do "powerful".

You may need to set debug or dump mode to see what messages you have. You only get the option if your unit responds to that message.

[JeanOlivier]

If you recall I'm the one that can "read" powerful, but apparently can't send the command.

[MUN0X]

No, the unit doesn't respond to “demand” via mqtt

[revk]

I'll look in the morning...

[revk]

OK I have added demand with argument 0-100 - new code in a few minutes.

[apos-t]

Hi,

thank you for adding this feature. Now I can disable the Daikin Wifi Modules in the future.
It would be great, if you I can publish the demand control in home assistant as a SelectEntity

There is also an off and auto mode in the app for demand control and also in the cloud integration. A screenshot attached, how it is looking right now in home assistant - with this integration: https://github.com/jwillemsen/daikin_residential_altherma

A second point is, in my opinion the values for demand control could be different for different outdoor units. Is it possible to debug which values are accepted by the outdoor unit? I could set my 4MXM80 to 30% via the web gui and the power consumption is much lower as typically at 40%, which was the minimum at the cloud implementation.

[apos-t]

sorry, I was at a business trip...

{
"name": "Demand Control Office",
"unique_id": "demand_office",
"command_topic": "homeassistant/select/demand_office/select",
"options": ["30", "35", "40", "45"] -> and so on
}

with the options you publish the values for the select field which you can update with the command_topic from faikin and home assistant. In the app you can select only 5% steps, I think this should be enough. Maybe a couple of the units can go lower than 40%. Therefore I would suggest to start with 30% and go up to 100% in 5% steps like in the screenshot above.

Here is another Json sample from the HA Forum:

https://community.home-assistant.io/t/solved-how-to-get-mqtt-select-in-discovery/349328/2

[revk]

So does it just send the topic with the option as the payload?

And no way to report current value back to HA

[apos-t]

With this json you create a select field with the options

homeassistant/select/demand_office/config

{
"name": "Demand Control Office",
"unique_id": "demand_office",
"command_topic": "homeassistant/select/demand_office/select",
"options": ["30", "35", "40", "45"]
}

When the config is done, you can use the topic "homeassistant/select/demand_office/select" to sync the state. When the Value in HA changes you will receive an update at this topic

[revk]

I am confused, surely I should be telling it the topic to set it in the Faikin, not homeassistant/select/demand_office/select.

Sorry if I am being thick here.

I'll issue a beta in a moment that has something, see if it is any help (github being laggy so will be a few minutes).

[turbolooser]

Could you share what the mqtt topic/payload should be to set demand control on the faikin?
I am still wondering which mqtt command should set the demand control on the faikin..or is it a setting? like the advanced settings?

[turbolooser]

From my site I would love to see demand control as a sensor here.

[turbolooser]

To me it looks like that when I select an option in the List in HA there is no command issues to the faikin module. I do not see anything on the mqtt broker debug logs on HA...so I assume that no command is being sent from HA to the Faikin

When I run the mqtt command directly I do see the command on the topic correctly BUT.... it seems that the value gets reverted to the older value after a couple of seconds. So I set it to 30... and then it reverts back to the previous value of 65 after 8-10 seconds

[turbolooser]

Any idea on why there is no command send to the Faikin?

[revk]

I don't know enough about HA. Others have reported this working I believe.

[turbolooser]

I have not seen any confirmation from HA. Pure mqtt works but value gets reverted (maybe by cloud integration).
Anyone has this working from HA select entity?

@MUN0X ?

[MUN0X]

Setting the demand via mqtt works for me. (At least it did a few fw versions ago, havent checked recently.) Does setting it via the web interface work for you?

[revk]

Values reverted means the S21 is not confirming back the setting. It may be that it does not allow some values, or even allow the setting.

[apos-t]

Hi,
I was away for a couple of days and could now do some testing, it's not working at the moment.

I forgot one point in the json, the state_topic... to receive updates from faking in HA

{
"name": "Demand Control Office",
"unique_id": "demand_office",
"command_topic": "homeassistant/select/demand_office/select", -> this is the topic faikin needs to subscribe for updates from HA, when the value changes.
"state_topic": "homeassistant/select/demand_office", -> ** this topic is for faikin to send / set the Value in HA**
"options": ["30", "35", "40", "45"]
}

[revk]

What are we waiting for at the moment, I thought we had it working.

[thomaslunze]

I can only set the deman control using mqtt messages like:

"command/faikin-wohnzimmer/demand" = 50 (payload)

but I cannot get it working with any select in HA using the sensor which is

It just does not do anything for me in HA

[revk]

Are you on latest code?

Can you log MQTT messages that HA sends?

Can you see anything wrong with the HA config we are registering?

[thomaslunze]

When I select "85" it goes like this

but it does not do anything on the webgui of the faikin

when i run the mqtt command which sets the demand correctly its like this

[revk]

That first one should work. Let me double check.

Ah, I may see it. One sec. I'll do another beta.

OK, try latest beta.

[apos-t]

you set the command topic to:
jo_stringf (j, "cmd_t", "%s/demand", revk_id);

that's the topic HA is sending the updates

In my case the message from HA looks like this:

Topic: 0C8B9596ABC0/demand
Value: 50

[revk]

Yes, I have changed it now in the latest beta, hence suggesting you try it, 16 minutes ago.

[apos-t]

Sorry, I was too slow. On the latest beta it's working. Thank you!

[revk]

There are some people that file bug reports just after I have issued a fix... So well done getting it in the right order :-)

[thomaslunze]

I can confirm its working now. awesome

[eupesco]

Hi,
I just came across a strange thing: when I change the demand control in Faikin, it obviously works (because the power of the HVAC is increasing/decreasing). But when I look in the Onecta app, the demand control value does not change. Has anyone seen this behavior?
I remember that the HA Daikin integration (in HACS, not the official one) was able to change the demand control (before it was changed because of the cloud change at Daikin) and the value was synchronized with the Onecta app.

[wurmtal868]

The Onecta seems to push the demand value but is not able to read it back. That's my experience with my two multi split systems.
You can always see the demand value on the Faikin GUI