I have been working lately on integrating this thermostat into Home Assistant. Following the previous work by Benjamin Lafois for OpenHAB, I developed a python library to control the Bluetooth thermostat and, later, created this custom component.
This integration requires human intervention due to the pairing constraints on the device. Basically, you have to agree on the client and the thermostat by accepting the code. However, the thermostat is not visible for pairing if it is already paired with a mobile phone app. You can find more details on the requirements and installation in the python package repository or in the custom component repository itself.
By the way, the integration is lacking logo and icon (domain name is daikin_madoka, it could be symlinked to daikin). I have checked the “brands” repository, do I have to PR or is it only maintained by core developers?
It is running in docker and I think that bleak-lescan has provided a good insight:
File "/usr/local/lib/python3.8/site-packages/bleak/backends/bluezdbus/scanner.py", line 90, in start
self._bus = await client.connect(self._reactor, "system").asFuture(loop)
twisted.internet.error.ConnectError: An error occurred while connecting: Failed to connect to any bus address. Last error: An error occurred while connecting: 2: No such file or directory..
“Failed to connect to any bus address”
What I have learned afterwards is that dbus is not running inside docker, and bleak is using DBus.
To make DBus being available in docker you have to link /var/run/dbus/system_bus_socket inside the container and also run docker in privileged mode. I don’t like the latter as homeassistant is a complex system.
For the reference, I have added this to my dockerfile:
However, I didn’t have to touch anything related to my dockers, I am using the default homeassistant docker in HassOS VM. Maybe HassOS has implemented it by default.
I am also working on a command line tool to bridge the device to MQTT (so it can run in a different system without HomeAssistant), I will update the library as soon as I have it ready.
I finished version 0.2.0 of the pymadoka library. This version includes a CLI tool (pymadoka-mqtt) to bridge the device with a MQTT broker and integrate it as a MQTT climate device (in case the HomeAssistant is not within the thermostat bluetooth range, it can be installed as a daemon on raspi or somewhere else).
I have been using it since friday, and no dropouts or other problems. The BT connection from my NUC to the BRC1H controller haven’t dropped a single time.
Also updated to 2021.1.3 without any problems. I just see now that release 2021.1.4 is out.
It has been working so far, but are we polling the indoor temperature sensor? Because it has been at 19º for hours, and for sure the temperature of the room has been changing.
All the features are updated at the same time so yes, it should be requesting the temperature every 60 secs (default for HA). I have found myself that compared to my Nest, the temp sensor is much less accurate but let me know if you don’t notice any change, it could be a bug.
I have been checking it for a while this evening and as you say the problem is that the accuracy is quite low, as it is only providing an integer number, and it looks like that it rounding to the next number, at least compared with my Aqara sensors in both floors I have.
I also can confirm that it is working managing two madoka controllers at the same time.
A different issue:
Sometimes one of the devices disconnects and it becomes unavailable. The only way to make it reconnect is to reaload the integration or Home Assistant.
2021-01-17 22:33:24 INFO (MainThread) [pymadoka.connection] Connected to 1C:54:9E:87:E1:CE
2021-01-17 22:33:30 INFO (MainThread) [pymadoka.connection] Connected to 1C:54:9E:87:CB:0B
2021-01-17 23:04:21 INFO (MainThread) [pymadoka.connection] Disconnected 1C:54:9E:87:CB:0B!
Hi, with the latest version I get this recurring error:
Logger: pymadoka.connection
Source: /usr/local/lib/python3.8/site-packages/pymadoka/connection.py:176
First occurred: 18 de enero de 2021 23:54:27 (17 occurrences)
Last logged: 0:27:00
Sometimes that error is caused by the adapter not being able to connect to the thermostat due to wrong pairing or dbus failures. At first, the thermostat accepts the connection but then rejects it causing the disconnect. You can check if you can connect from the terminal using bluetoothctl:
Type paired-devices. Your mac should be listed
Type connect mac_address and check if it remains connected.
During the coding I have also come across some problems related to the DBUS. After many connection attempts, it would stop responding and I had to reboot the system.
Besides, that message can appear a couple of times before connecting successfully to the device and listing the BLE services. I don’t know if it is related to the thermostat or the dbus.
Just a heads up from me, Have been using the integration since day 1. Still no dropouts on bluetooth. Everything is now automated together with my temperature sensors at my home.
I have been operating it for one week now. Using from HA works perfectly but when I switch the device on from the controller itself, I don’t get the status updated. I am getting this error
2021-01-23 11:58:19 WARNING (MainThread) [homeassistant.components.sensor] Updating daikin_madoka sensor took longer than the scheduled update interval 0:00:30
Additionally, the temperature sensor on it is crap or the decimals are coming in the protocol and we’re not decoding these. I am using a Xiaomi aqara to get the right temperature.
I will have a closer look at the temperature as I might be rounding up by mistake. However, the device itself does not show decimals so I am not sure it it provides them.
Regarding the updates and the power status, it is obtained from polling the device when HA commands it to. So some changes in the device might not reflect immediately. But now that you suggest it, it may require an additional update for the power status as it is handled independently on the device but guessed from the user modes in HA.
I am a bit busy with meeting all the requirements (quite a few) to make this available as a core integration so it will have to wait a little bit until I can update the library version.
The message that the device sends is only one byte, so it is an integer, no decimals then. It is curious though that the get/set point sends a ‘double’ so it could have decimals. I haven’t investigated yet what happens if the temperature of operation is tried to be set to 21.5, or 20.3.
Anyway, in that case, if the internal thermoter just gives 20 or 21, won’t have much effect on the operation.
