Cooling temperature always increment

[djrusskof]

I have an OrangePi 4 with ARMBian (22.02.1) and I just installed a Daikin reversible air conditioning at home.
I have a BRC1H box and so I looked for how to control it remotely via my OrangePi.
I successfully installed pymadoka, and I wanted to try via terminal to control the air conditioning.
The problem I'm having is when sending a "set-set-point" command (pymadoka -a XX:XX:XX:XX:XX:XX set-set-point 20 24 for example).
Then, I read the temperature setpoints via the "get-set-point" command (pymadoka -a XX:XX:XX:XX:XX:XX get-set-point for example) and I notice that the heating temperature is indeed at the value programmed in the command while the cooling temperature has been increased by 1 compared to the old programmed value.

If cooling temperature was 20°C, after setting new cooling temperature set, I will have a cooling temperature set to 21°C, no matter the value I asked in command line.

[mduran80]

Hi! I have been checking my code and it might be related to some integer rounding, although the same issue should be happening in both heating and cooling set points. Could you confirm if the same happens when using the same value for both? I just want to check it is not behaviour implemented in the thermostat. El El lun, 9 may 2022 a las 14:44, djrusskof ***@***.***> escribió:

…

I have an OrangePi 4 with ARMBian (22.02.1) and I just installed a Daikin reversible air conditioning at home. I have a BRC1H box and so I looked for how to control it remotely via my OrangePi. I successfully installed pymadoka, and I wanted to try via terminal to control the air conditioning. The problem I'm having is when sending a "*set-set-point*" command (*pymadoka -a XX:XX:XX:XX:XX:XX set-set-point 20 24* for example). Then, I read the temperature setpoints via the "*get-set-point*" command (*pymadoka -a XX:XX:XX:XX:XX:XX get-set-point* for example) and I notice that the heating temperature is indeed at the value programmed in the command while the cooling temperature has been increased by 1 compared to the old programmed value. If cooling temperature was 20°C, after setting new cooling temperature set, I will have a cooling temperature set to 21°C, no matter the value I asked in command line. — Reply to this email directly, view it on GitHub <#2>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFK3CT2SKPYL3C6NPEAADEDVJECDBANCNFSM5VOE4LNQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[djrusskof]

Hi, and thank you for your answer.

I check the following :

Read set point : pymadoka -a xx:xx:xx:xx:xx:xx get-set-point
Answer : cooling_set_point": 22, "heating_set_point": 19}

Write set point : pymadoka -a xx:xx:xx:xx:xx:xx set-set-point 19 19
Answer : cooling_set_point": 19, "heating_set_point": 19}

New read set point to be sure (I expect that both are at 19°C) :
pymadoka -a xx:xx:xx:xx:xx:xx get-set-point
Answer : cooling_set_point": 20, "heating_set_point": 19}

First, the answer always missed the 2 first bytes (I never have {" at the begining of the answer)
Next, this try the cooling temperature doesn't increment, but value is'nt 19 but 20.
Finally, it seems to always work on heating temperature.

[betonishard]

Hi, I am experiencing the same

mduran80/daikin_madoka#16

Difference is that I am working via homeassistant, however I tested also via pymadoka.

[mduran80]

I am almost sure that it is related to these lines : https://github.com/mduran80/pymadoka/blob/412daaffa77d5330b25c9d38e8e65fa441bd1ce8/pymadoka/features/setpoint.py#L36 I have to check if the protocol response from the Madoka is the same for the heating and cooling parameters when they are set to the same temperature, because the round function applies to both the same way and the values obtained should remain the same too.

…

On Sun, 17 Jul 2022 at 12:20, betonishard ***@***.***> wrote: Hi, I am experiencing the same mduran80/daikin_madoka#16 <mduran80/daikin_madoka#16> Difference is that I am working via homeassistant, however I tested also via pymadoka. — Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFK3CT5EULJG4VA2VFNHQJTVUPM47ANCNFSM5VOE4LNQ> . You are receiving this because you commented.Message ID: ***@***.***>

[mduran80]

Read set point : pymadoka -a xx:xx:xx:xx:xx:xx get-set-point Answer : cooling_set_point": 22, "heating_set_point": 19}

Write set point : pymadoka -a xx:xx:xx:xx:xx:xx set-set-point 19 19 Answer : cooling_set_point": 19, "heating_set_point": 19}

New read set point to be sure (I expect that both are at 19°C) : pymadoka -a xx:xx:xx:xx:xx:xx get-set-point Answer : cooling_set_point": 20, "heating_set_point": 19}

I have been debugging the device protocol for some time this morning and I have not been able to reproduce the behaviour (at least with my HVAC unit and my thermostat). The values obtained after querying the thermostat are the same as sent in the command. I tested with the same exact values, just in case the number rounding could affect the tests, but no luck.

My thermostat info:

"Software Revision String": "7031.05.17", "Hardware Revision String": "UEIS-15288", "Firmware Revision String": "BL C0", "Model Number String": "0.1"

However, I found an interesting behaviour I hadn't noticed previously.
Apparently, my thermostat does not handle separate heating/cooling temperatures and only uses heating point value in the set_point command.

The set-point command controls many parameters from the device. Among them, we can find the set point temperature but also the upper/lower device limits as well as some working mode and differential values in temperature that could trigger functional changes. I assume this approach is flexible enough as to support a range of HVACS without hardcoding the working parameter values.

In my case, no matter how many parameters I use, it will always use the last set-point parameter sent. When we send the set-point command, we are sending cooling_set_point parameter followed by heating_set_point parameter. So, after sending the data, if I retrieve the values, both always point to heating_set_point. That means that if you are using the CLI and your thermostat/HVAC is behaving like mine, you must only care about the heating_set_point. Anyway, I will leave the support for setting both values in case other devices behave as expected.

[betonishard]

@mduran80

Thank you for the updates, however setting setpoint results in this (or get-set point)

./usr/local/lib/python3.10/site-packages/pymadoka/connection.py:56: FutureWarning: This method will be removed in a future version of Bleak. Use thediscovered_devices property instead. DISCOVERED_DEVICES_CACHE = await scanner.get_discovered_devices() ./usr/local/lib/python3.10/site-packages/pymadoka/connection.py:163: FutureWarning: is_connected has been changed to a property. Calling it as an async method will be removed in a future version connected = await self.client.is_connected() .ERROR:pymadoka.cli:Could not send command: message could not be rebuilt

[stever29]

I know this is an old topic, but I'm also seeing this issue. While I'm not 100% certain, I'm fairly sure this was working for me previously. I've changed two things; updated the madoka controller firmware (via the mobile app), and changed bluetooth adapter. I assume the firmware is potentially the issue here?