MQTT Discovery messagge [feature request]

[angeloniclaudio]

Hi mduran80,

thanks for the huge work you have done and shared with us. Really appreciated!

I opened this ticket to share with you an idea allowing faster Madoka configuration via MQTT when using pyMadoka + homeassistant. This is needed when Raspberry running HA is not close to the madoka device.

The suggestion is to configure a one-time MQTT message for the Discovery feature. It's enough to trigger the message after MQTT connection.

I've optimized the template in order to instruct HA with all features available on madoka and I would like to share it with you:

The destination topic should be:

homeassistant/climate/[root_topic]/[DEVICE_NAME]/config

and the Json payload should be something like:

{ "name": "Daikin Madoka frienly name", "unique_id": "[DEVICE_NAME]", "availability": { "topic": "[root_topic]/[DEVICE_NAME]/available", "payload_available": 1, "payload_not_available": 0 }, "current_temperature_topic": "[root_topic]/[DEVICE_NAME]/state/get", "current_temperature_template": "{{ value_json.temperatures['indoor'] }}", "fan_mode_command_topic": "[root_topic]/[DEVICE_NAME]/fan_speed/set", "fan_mode_command_template": "{% set values = { 'auto':'AUTO', 'low':'LOW', 'medium':'MID', 'high':'HIGH'} %}{{ values[value] }}", "fan_mode_state_topic": "[root_topic]/[DEVICE_NAME]/state/get", "fan_mode_state_template": "{% set values = { 'AUTO':'auto', 'LOW':'low', 'MEDIUM':'medium', 'HIGH':'high'} %} {{ values[value_json.fan_speed['heating_fan_speed']] if value_json.operation_mode['operation_mode']=='HEAT' else values[value_json.fan_speed['cooling_fan_speed']]}}", "fan_modes": [ "low", "medium", "high" ], "mode_command_topic": "[root_topic]/[DEVICE_NAME]/operation_mode/set", "mode_command_template": "{% set values = { 'auto':'AUTO', 'heat':'HEAT', 'cool':'COOL', 'fan_only':'FAN','off':'AUTO'} %}{{ values[value] if value in values.keys() else 'AUTO' }}", "mode_state_topic": "[root_topic]/[DEVICE_NAME]/state/get", "mode_state_template": "{% set values = {None:None,'off':'off','HEAT':'heat','COOL':'cool','FAN':'fan_only', 'AUTO':'auto', 'DRY':'dry'} %} {{values[value_json.operation_mode['operation_mode']] if value_json.power_state['turn_on'] else 'off' }}", "modes": [ "auto", "off", "cool", "heat", "dry", "fan_only" ], "power_command_topic": "[root_topic]/[DEVICE_NAME]/power_state/set", "min_temp": 17, "max_temp": 31, "precision": 1, "temperature_state_topic": "[root_topic]/[DEVICE_NAME]/state/get", "temperature_state_template": "{{ value_json.set_point['heating_set_point'] if value_json.operation_mode['operation_mode']=='HEAT' else value_json.set_point['cooling_set_point']}}", "temperature_command_topic": "[root_topic]/[DEVICE_NAME]/set_point/set", "temperature_command_template": "{{ int(value) }}", "temperature_unit": "C", "temp_step": 1, "device": { "manufacturer": "Daikin", "via_device": "Madoka", "identifiers": "[DEVICE_NAME]", "name": "Friendly name", "model": "Madoka: BRC1H", "sw_version": "1.0" } }

[mduran80]

Implemented in latest version https://github.com/mduran80/pymadoka/tree/0.2.8

Let me know if it works. I also updated the logic to send the available message whenever the status is updated.

[mario-tux]

I'm testing 0.2.10 version but I can't spot any discovery record in mqtt broker (homeassistant/climate/...) so HA doesn't create any climate entities. The climate entity defined above could/should be improved: the field mode_command_template should be fixed as the DRY state is missing. You can compare with my configuration (that is NOT perfect at all, but I'm working on it): https://github.com/mduran80/pymadoka/issues/13. I'm testing if the field power_command_topic is really necessary or not.

Other observation: the publishing of the discovery record (so the automatic creation of the climate entity in HA) should be optional or, at least, deactivable . As long as we don't find a perfect for all the cases, we should not force its usage.

UPDATE: now I can spot the published record in madoka/ID/config: it looks the wrong place.

[mduran80]

I'm testing 0.2.10 version but I can't spot any discovery record in mqtt broker (homeassistant/climate/...) so HA doesn't create any climate entities. The climate entity defined above could/should be improved: the field mode_command_template should be fixed as the DRY state is missing. You can compare with my configuration (that is NOT perfect at all, but I'm working on it): #13. I'm testing if the field power_command_topic is really necessary or not.

Other observation: the publishing of the discovery record (so the automatic creation of the climate entity in HA) should be optional or, at least, deactivable . As long as we don't find a perfect for all the cases, we should not force its usage.

UPDATE: now I can spot the published record in madoka/ID/config: it looks the wrong place.

Will fix with the available=0 push

[mduran80]

Pushed new version 0.2.11.

Fixed destination topic and Dry mode. Discovery message is optional, only sent when configured in the MQTT config file.

I am not an user of MQTT climate myself, so I have no idea how this is going... I am just updating and testing that nothing breaks (when I can find some time :S). Let me know if you need anything else.

[mario-tux]

Pushed new version 0.2.11.

Fixed destination topic and Dry mode. Discovery message is optional, only sent when configured in the MQTT config file.

At first glance it is not working: I need more time to investigate.

I am not an user of MQTT climate myself, so I have no idea how this is going... I am just updating and testing that nothing breaks (when I can find some time :S). Let me know if you need anything else.

I understand your position but it is a pity: an MQTT thermostat defined by mean of a (not straightforward) configuration like the one above and by the behavior of pymadoka-mqtt is a quite complex system. My actual configuration has many glitches (often the request of mode change is delivered to the broker but not detected by the agent; set-points are not correctly managed; ...) but it is difficult to detect the bug to report/correct without a direct testing.

If I can ask: are you personally using the HA component to manage your Madoka controllers? I've not tested it for two reasons: as long as it remains an PR/unofficial it could break on any future HA update; my NUC lacks of bluetooth adapter (but I could install one) and the distance with my (4) remotes could become an issue.

[mduran80]

Yes, I am using the HA component with my controller, so whenever there is an HA update, I will keep it working. I will not support updates to the controller firmware itself though. I am using a NUC with an external adapter and it is working fine, but it is in the same room as the thermostat. I don't plan to submit the PR again, it remained in the limb for so long and took so much time to write the tests and code to be compliant that I lost interest, tbh. I may submit it to HACS, but again.. requires some time.

I tried to replicate the template you provided. In my tests, I could check that the device would send the discovery message, available message when connected/disconnected, reconnect and all that stuff, but I haven't checked if the messages are accepted by HA. In the future, i will set the thermostat as a MQTT following your config and test it myself, but I will appreciate any feedback you can provide in the meantime.

On Tue, 21 Feb 2023 at 12:17, Mario @.***> wrote:

Pushed new version 0.2.11.

Fixed destination topic and Dry mode. Discovery message is optional, only sent when configured in the MQTT config file.

At first glance it is not working: I need more time to investigate.

I am not an user of MQTT climate myself, so I have no idea how this is going... I am just updating and testing that nothing breaks (when I can find some time :S). Let me know if you need anything else.

I understand your position but it is a pity: an MQTT thermostat defined by mean of a (not straightforward) configuration like the one above and by the behavior of pymadoka-mqtt is a quite complex system. My actual configuration has many glitches (often the request of mode change is delivered to the broker but not detected by the agent; set-points are not correctly managed; ...) but it is difficult to detect the bug to report/correct without a direct testing.

If I can ask: are you personally using the HA component to manage your Madoka controllers? I've not tested it for two reasons: as long as it remains an PR/unofficial it could break on any future HA update; my NUC lacks of bluetooth adapter (but I could install one) and the distance with my (4) remotes could become an issue.

— Reply to this email directly, view it on GitHub https://github.com/mduran80/pymadoka/issues/12#issuecomment-1438304522, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFK3CTZ7UXN226BWNESOWC3WYSP4ZANCNFSM6AAAAAAUKKGLD4 . You are receiving this because you commented.Message ID: @.***>