Logger: pymadoka.connection
Source: runner.py:186
First occurred: 04:59:41 (57297 occurrences)
Last logged: 10:39:01
No backend with an available connection slot that can reach address XX:XX:XX:XX:XX:X was found
[org.bluez.Error.Failed] Operation already in progress
[org.bluez.Error.Failed] br-connection-canceled
'str' object has no attribute 'name'
However, we use RP3b and the integrated bluetooth. The only time this has worked without needing constant reloads was about 1 year ago but I was not sure if it was to do with the underlying OS or HA.
This is problem makes the whole integration unusable which is a shame given the effort the creator put into it.
hi Petapton,
great work!, i as able to link my Madoka thermostat to my Home Assistant.
i have one question: in my Madoka phone app, i am able to change the fan speed from automatic to 3 manual speeds. does your code support this?
Ok everyone, in the end I found some spare time to PR the component to esphome.
It is now under review.
In the meantime you can still use it from my repository.
I did fork it and made some minor changes (no dual setpoint - it doesnāt work like that on the madoka, and implemented the fanspeed). Iām testing it at home - and looks working fine.
Also, it seems that for the configuration, io_capability: display_only is sufficient and the BRC1H does not ask for code confirmation. Iāll confirm that with additional thermostat tomorrow.
edit: I did not write C++ for years - so please apologize for the code quality
Hello @blafois, many tanks for the reversing job. It was a real life saver during the whole development.
I think it depends on the actual climate device you are using. In my case (idk what device it is), there is the HEAT/COOL mode, which basically works in dual setpoint mode (though only the active one is shown on the display).
IMO the single setpoint is useless, since the dual gives more control/information, but if there is somebody (like you do) which prefers it, I think we could give users freedom to choose it in yaml settings.
As a matter of pure randomness, I added the same feature just last weekend, so it is already in the pull request. Also, I think you forgot to add the AUTO fan mode, which has value 0 in the request and is actually a thing, at least on my madoka-controlled devices.
Thereās one last point, i.e. how to manage the two fan mode settings. I found the cool one gets used in cool and fan only, while the heat one is used only in heat mode.
Dry mode has no settings for fan speed and heat/cool mode uses them both, taking the one which was in use before switching to heat/cool mode. (I made these observations by changing fan speed from physical buttons on the device and notating what it returned on queries)
I currently use this logic:
when reading from device, I check whether we are in heat mode or heat/cool, cool, fan mode. You can see I arbitrarily decided to move heat/cool mode into the cool fan mode, regardless of whether we are actually heating or cooling.
when writing to device, I set both fan modes to the same value, independently of which operating mode we are in.
These two points must be discussed and fixed in my opinion.
I remember I tried with several configurations without success. The only one which gave me positive results was the display_yes_no one. Keep in mind that ESP32 caches the pairing codes, so you might be having positive feedback because of this, even after switching to another pairing mode. To ensure this is not a false positive, I recommend performing a esptool.py erase_flash before switching pairing mechanism.
Anyway, feel free to contribute. Iām happy to see this is gaining interest also on the developing side.
I think it depends on the actual climate device you are using. In my case (idk what device it is), there is the HEAT/COOL mode, which basically works in dual setpoint mode (though only the active one is shown on the display).
Indeed its different on my device and I donāt have this mode. My understanding was (this is from 2019) that the BRC1H keeps memory of the setpoint for cooling, and for heating. So when you switch from one mode to another, it remembers the previous setpoint. I donāt remember how I implemented this for OpenHAB. I think I was tempted to always overwrite both heating and cooling setpoints (+fan speeds) with the same value, as the BRC1H cannot be bound to 2 BLE central.
If we can implement the choice with the Yaml, would be awesome (Iām not familiar at all with ESPHOME, first time I play with it).
Similarly for the FAN SPEED, my device did not offer this option. It only offers 3 levels (low/med/high), while I saw that other internal units have 5 levels, and apparently, AUTO as well. But not mine. Can we also set that in the Yaml ?
I think that once you start using the Madoka with HA, you no longer use the mobile app (requires unpair/pairā¦). So its fine to always overwrite the cooling and heating fan speeds. What do you think ?
Will make additional tests for the bluetooth pairing. Interestingly, before finding this ESPHOME alternative, I wrote an MQTT/BRC1H bridge using Micropython (which is BTW a nightmare and found it to be super unstable) and the ESP32, and I figured out that authorization was optional, and the BRC1H was accepting orders from my Micropython ESP32 without having accepted a pairing code first (which somehow makes sense, because as far as I understood, the pairing process is from genuine bluetooth - while BLE does not requires this).
I think we could let users choose which modes they want to use, but also we need a way to ask the device which capability it has.
Also here, having a way to automatically set capabilities (meaning users could not set capabilities they donāt have, avoiding false expectations) would be great.
I agree. Maybe could be interesting to know which kind of logic they implemented for fan speed and why they thought one should set different speeds for heating and coolingā¦
I remember to have struggled for a few weeks before figuring out the correct pairing setup. I would be surprised to hear otherwise. Nonetheless, I would be curious to know whether and learn why Iām wrong.
hi @Petapton thank for great job! I am able to control 2 madoka devices (on, off, heat, cold fan).
I have just problems how the entity created in HA appears
. It does not show the room temperature as per madoka display and the operation mode is always like it was off, am I missing something?
I am quite new with HA and ESP in general so perhaps it is a stupid questionā¦
Hello Petapton, this is really exciting for me!
Last year I gave up trying to integrate in HA with ESPHOME the BLE bridge with Madoka because BLE authentication was not yet supported.
Now I discovered that it is supported and is working great with all AC units Madoka connected.
Many many thanks!
Nevertheless, I have two Madoka connected with two separate Mechanical Ventilation System.
Unfortunately it does not work.
Is maybe Mechanical Ventilation System not supported?
Thank you!
Hello guys, thanks for you kind words. I think thereās something unsupported here.
On my hardware everything works (what a surprise). Would you be so kind to provide logs or, even better, a BLE network capture?
For logs, in esphome config, you need to set the logger section to the following, then compile, upload and post logs here. Then set it back to the previous value.
logger:
level: VERBOSE
For network capture, please provide a capture in which you interact with it using the official app. You will need to mess around with developer options in your smartphone. See this post as an example. Once you have btsnoop_hci.log, post it here.
Note it contains all BT packets trasmitted and received by your phone during acquisition, so sensitive data can be contained. Be sure to understand what you are doing.
Note:@Brad_Ford@ignazio.testoni@delca81 I assume you have unpaired the madoka unit from your smartphone and paired it with the ESP device. Not doing this prevents the two devices from communicating. In case you havenāt already, hereās a quick guide.
To unpair it, from the head unit, go into bluetooth settings and click on the unpair icon.
Now, once you power your esphome device, a pairing pin should appear on the display. If you feel like it, you can check it matches with the one showed in esphome logs. Otherwise, you can just confirm it on the head unit (esphome component automatically confirms it).
Now everything should work.
Hi @Petapton ,
yes, the unit was unpaired from previous connection with my mobile.
It is correctly paired with the esp32 device.
Here attached, yaml file and log as per your request.
Note that in Home Assistant the unit seems to be not available.
The defined switch to reboot the unit is not available as well.
Thank you!
Could you try with framework type esp-idf instead of arduino? Donāt know whether it is related, but just to be on the same pageā¦
When switching from arduino to esp-idf, make sure to update the device with a serial cable as the partition table is different between the two frameworks as OTA Update Component updates will not change the partition table.
I followed your suggestion.
I changed from arduino to esp-idf.
It seems now to find the unit and it works for few seconds!
I was able in fact to turn it off.
[17:15:58][D][climate:011]: 'Madoka VMC Giorno' - Setting
[17:15:58][D][climate:015]: Mode: OFF
Then it does not accept any command, the invocation service in HA fails.
After couple of minutes the esp32 goes off-line and I need to cycle the power.
Seldom it come back on lineā¦
Here attached log and HA card.
INFO ESPHome 2023.12.9
INFO Reading configuration /config/esphome/esp32-madoka-bridge-vmc.yaml...
INFO Starting log output from 192.168.1.70 using esphome API
INFO Successfully connected to madoka-bridge-vmc @ 192.168.1.70 in 0.065s
INFO Successful handshake with madoka-bridge-vmc @ 192.168.1.70 in 0.044s
[17:15:44][I][app:102]: ESPHome version 2023.12.9 compiled on Jan 27 2024, 17:07:39
[17:15:44][C][wifi:573]: WiFi:
[17:15:44][C][wifi:405]: Local MAC: C8:F0:9E:A6:CC:58
[17:15:44][C][wifi:410]: SSID: 'IGLO'[redacted]
[17:15:44][C][wifi:411]: IP Address: 192.168.1.70
[17:15:44][C][wifi:413]: BSSID: E0:28:6D:8E:F0:F7[redacted]
[17:15:44][C][wifi:414]: Hostname: 'madoka-bridge-vmc'
[17:15:44][C][wifi:416]: Signal strength: -65 dB āāāā
[17:15:44][C][wifi:420]: Channel: 5
[17:15:44][C][wifi:421]: Subnet: 255.255.255.0
[17:15:44][C][wifi:422]: Gateway: 192.168.1.1
[17:15:44][C][wifi:423]: DNS1: 192.168.1.1
[17:15:44][C][wifi:424]: DNS2: 0.0.0.0
[17:15:44][C][logger:439]: Logger:
[17:15:44][C][logger:440]: Level: DEBUG
[17:15:44][C][logger:441]: Log Baud Rate: 115200
[17:15:44][C][logger:443]: Hardware UART: UART0
[17:15:44][C][restart:068]: Restart Switch 'madoka-bridge-vmc_reboot'
[17:15:44][C][restart:070]: Icon: 'mdi:restart'
[17:15:44][C][restart:091]: Restore Mode: always OFF
[17:15:44][C][madoka:013]: madokaDaikin Madoka Climate Controller 'Madoka VMC Giorno'
[17:15:44][C][esp32_ble:374]: ESP32 BLE:
[17:15:44][C][esp32_ble:376]: MAC address: C8:F0:9E:A6:CC:5A
[17:15:44][C][esp32_ble:377]: IO Capability: display_yes_no
[17:15:44][C][esp32_ble_tracker:645]: BLE Tracker:
[17:15:44][C][esp32_ble_tracker:646]: Scan Duration: 300 s
[17:15:44][C][esp32_ble_tracker:647]: Scan Interval: 320.0 ms
[17:15:44][C][esp32_ble_tracker:648]: Scan Window: 30.0 ms
[17:15:44][C][esp32_ble_tracker:649]: Scan Type: ACTIVE
[17:15:44][C][esp32_ble_tracker:650]: Continuous Scanning: True
[17:15:44][C][ble_client:027]: BLE Client:
[17:15:44][C][ble_client:028]: Address: 68:88:A1:C0:26:7B
[17:15:44][C][web_server:168]: Web Server:
[17:15:44][C][web_server:169]: Address: madoka-bridge-vmc.local:80
[17:15:44][C][mdns:115]: mDNS:
[17:15:44][C][mdns:116]: Hostname: madoka-bridge-vmc
[17:15:44][C][ota:097]: Over-The-Air Updates:
[17:15:44][C][ota:098]: Address: madoka-bridge-vmc.local:3232
[17:15:45][C][api:139]: API Server:
[17:15:45][C][api:140]: Address: madoka-bridge-vmc.local:6053
[17:15:45][C][api:144]: Using noise encryption: NO
[17:15:48][D][madoka:189]: Got update request...
[17:15:48][W][component:214]: Component madoka.climate took a long time for an operation (0.25 s).
[17:15:48][W][component:215]: Components should block for at most 20-30ms.
[17:15:48][D][climate:396]: 'Madoka VMC Giorno' - Sending state:
[17:15:48][D][climate:399]: Mode: FAN_ONLY
[17:15:48][D][climate:419]: Current Temperature: nanĀ°C
[17:15:48][D][climate:423]: Target Temperature: Low: nanĀ°C High: nanĀ°C
[17:15:49][D][climate:396]: 'Madoka VMC Giorno' - Sending state:
[17:15:49][D][climate:399]: Mode: FAN_ONLY
[17:15:49][D][climate:419]: Current Temperature: nanĀ°C
[17:15:49][D][climate:423]: Target Temperature: Low: nanĀ°C High: nanĀ°C
[17:15:49][D][climate:396]: 'Madoka VMC Giorno' - Sending state:
[17:15:49][D][climate:399]: Mode: FAN_ONLY
[17:15:49][D][climate:419]: Current Temperature: nanĀ°C
[17:15:49][D][climate:423]: Target Temperature: Low: nanĀ°C High: nanĀ°C
[17:15:49][D][climate:396]: 'Madoka VMC Giorno' - Sending state:
[17:15:49][D][climate:399]: Mode: FAN_ONLY
[17:15:49][D][climate:419]: Current Temperature: 19.00Ā°C
[17:15:49][D][climate:423]: Target Temperature: Low: nanĀ°C High: nanĀ°C
[17:15:58][D][climate:011]: 'Madoka VMC Giorno' - Setting
[17:15:58][D][climate:015]: Mode: OFF
[17:15:58][D][madoka:070]: status: 0, mode: 255
[17:15:58][W][component:214]: Component api took a long time for an operation (0.21 s).
[17:15:58][W][component:215]: Components should block for at most 20-30ms.
[17:15:58][D][madoka:189]: Got update request...
[17:15:58][W][component:214]: Component madoka.climate took a long time for an operation (0.25 s).
[17:15:58][W][component:215]: Components should block for at most 20-30ms.
[17:15:58][D][climate:396]: 'Madoka VMC Giorno' - Sending state:
[17:15:58][D][climate:399]: Mode: FAN_ONLY
[17:15:58][D][climate:419]: Current Temperature: 19.00Ā°C
[17:15:58][D][climate:423]: Target Temperature: Low: nanĀ°C High: nanĀ°C
[17:15:58][D][climate:396]: 'Madoka VMC Giorno' - Sending state:
[17:15:58][D][climate:399]: Mode: OFF
[17:15:58][D][climate:419]: Current Temperature: 19.00Ā°C
[17:15:58][D][climate:423]: Target Temperature: Low: nanĀ°C High: nanĀ°C
WARNING madoka-bridge-vmc @ 192.168.1.70: Connection error occurred: [Errno 104] Connection reset by peer
INFO Processing unexpected disconnect from ESPHome API for madoka-bridge-vmc @ 192.168.1.70
WARNING Disconnected from API
INFO Successfully connected to madoka-bridge-vmc @ 192.168.1.70 in 0.004s
INFO Successful handshake with madoka-bridge-vmc @ 192.168.1.70 in 0.029s
[17:16:25][D][madoka:189]: Got update request...
[17:16:25][W][component:214]: Component madoka.climate took a long time for an operation (0.25 s).
[17:16:25][W][component:215]: Components should block for at most 20-30ms.
Well, I think this needs more investigationā¦ I would try to craft a purpose-made firmware without all unsupported features, to remove any possible source of error.
Unfortunately I have very few spare time at this point of my life. I will try to push updates from time to time, but no guarantee. I will let you know when something happens, so you could try (if you want) and see if it solves your issues.
