eq3btsmart looses connection very often

[FaserF]

Home Assistant release with the issue: Currently using v 101.2, but the issue exists already since a longer time

Last working Home Assistant release (if known):

Operating environment DietPi Debian on a Tinkerboard in a Python venv

Integration: eq3btsmart

Description of problem: HomeAssistant looses the connection very often. If I want to change the temperature on one of my two eq3bt Thermostats I have to try it multiple times until it works.

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

  - platform: eq3btsmart
    devices:
      wohnzimmer:
        mac: !secret eq3btsmart1
      schlafzimmer:
        mac: !secret eq3btsmart2

Traceback (if applicable):

Additional information: I get a log info quite often for my thermostats like this: Log Details (WARNING) Thu Nov 07 2019 07:34:33 GMT+0100 (Central European Standard Time) Updating the state failed: Failed to connect to peripheral [MACADRESS], addr type: public

Log Details (WARNING) Thu Nov 07 2019 07:34:11 GMT+0100 (Central European Standard Time) Updating eq3btsmart climate took longer than the scheduled update interval 0:01:00

Log Details (WARNING) Thu Nov 07 2019 07:33:22 GMT+0100 (Central European Standard Time) Update of climate.wohnzimmer is taking over 10 seconds

[probot-home-assistant[bot]]

Hey there @rytilahti, mind taking a look at this issue as its been labeled with a integration (eq3btsmart) you are listed as a codeowner for? Thanks!

[bazyl78]

Same issue with EQ3 bluetooth. After sometime (hours / days) they got unavailable. You need to restart host (raspberry) not hassio and then they get available again. I think it is a general problem with BLE disconnecting.

[ene-rgy]

I have the same problem, and it really looks like a gerneral error with the BLE function. It simply stops working after few hours. The log shows that a connection request is sent, but there is no response.

[Nils3311]

I have the same problem and only restarting Home Assistant is a solution so far...

[bazyl78]

Failed to connect to peripheral 00:1A:22:13:C1:12, addr type: public Traceback (most recent call last): File "/usr/local/lib/python3.7/site-packages/eq3bt/connection.py", line 36, in enter self._conn.connect(self._mac) File "/usr/local/lib/python3.7/site-packages/bluepy/btle.py", line 445, in connect self._connect(addr, addrType, iface) File "/usr/local/lib/python3.7/site-packages/bluepy/btle.py", line 439, in _connect raise BTLEDisconnectError("Failed to connect to peripheral %s, addr type: %s" % (addr, addrType), rsp) bluepy.btle.BTLEDisconnectError: Failed to connect to peripheral 00:1A:22:13:C1:12, addr type: public

During handling of the above exception, another exception occurred:

Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 133, in handle_call_service connection.context(msg), File "/usr/src/homeassistant/homeassistant/core.py", line 1235, in async_call await asyncio.shield(self._execute_service(handler, service_call)) File "/usr/src/homeassistant/homeassistant/core.py", line 1260, in _execute_service await handler.func(service_call) File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 205, in handle_service self._platforms.values(), func, call, service_name, required_features File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 336, in entity_service_call future.result() # pop exception if have File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 360, in _handle_service_platform_call await func(entity, data) File "/usr/src/homeassistant/homeassistant/components/climate/init.py", line 519, in async_service_temperature_set await entity.async_set_temperature(kwargs) File "/usr/src/homeassistant/homeassistant/components/climate/init.py", line 380, in async_set_temperature ft.partial(self.set_temperature, kwargs) File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run result = self.fn(*self.args, **self.kwargs) File "/usr/src/homeassistant/homeassistant/components/eq3btsmart/climate.py", line 128, in set_temperature self._thermostat.target_temperature = temperature File "/usr/local/lib/python3.7/site-packages/eq3bt/eq3btsmart.py", line 245, in target_temperature self._conn.make_request(PROP_WRITE_HANDLE, value) File "/usr/local/lib/python3.7/site-packages/eq3bt/connection.py", line 71, in make_request with self: File "/usr/local/lib/python3.7/site-packages/eq3bt/connection.py", line 40, in enter self._conn.connect(self._mac) File "/usr/local/lib/python3.7/site-packages/bluepy/btle.py", line 445, in connect self._connect(addr, addrType, iface) File "/usr/local/lib/python3.7/site-packages/bluepy/btle.py", line 439, in _connect raise BTLEDisconnectError("Failed to connect to peripheral %s, addr type: %s" % (addr, addrType), rsp) bluepy.btle.BTLEDisconnectError: Failed to connect to peripheral 00:1A:22:13:C1:12, addr type: public

[bazyl78]

Well it seems it is a general problem with BLE Bluetooth. Common guys. At least give us access to restart bluetooth (not whole rasspberry pi/ host) and it gives us workaround to use in automations. Command for restarting bluetooth: /etc/init.d/bluetooth restart

[rytilahti]

@bazyl78 if you want to expose shell commands to homeassistant, you could use this: https://www.home-assistant.io/integrations/shell_command/

[garret]

I also experience exactly the same issues that have to reboot hassio for having the valves recognized again. If I connect to them with my phone they are always detected instead (by standing next to the raspberry 3b+ with hassio 0.104).

However, now since some days (I think actually when I updated just the host through the hassio interface (so not hassio itself)), the valves are not anymore recognized, even after continuous reboots. I can always see them immediately with the eqiva app on the phone.

Do you know how to solve this issue which seems related? Eventually, how could I just restart the Bluetooth on hassio without rebooting all the system?

[bazyl78]

@frenck @rytilahti Any chance someone will look into that? There is high focus on new integrations but old ones that stopped working are not touched :-(.

[frenck]

@bazyl78 There is a high focus on contributions, that is something different 😉

[nvanofwegen]

For now I'm using the command bluetoothctl power off && bluetoothctl power on in the web terminal add-on (using Hass.io/Pi 3B)

However, I'm having trouble adding it to the shell_commands (by calling the service every x minutes). But I keep getting Error running command: 'bluetoothctl power off && bluetoothctl power on', return code: 134 NoneType: None Calling a shell script with the command returns the same error code.

[bazyl78]

You can use service in hassio:

service: hassio.addon_stdin
data:
  addon: a0d7b954_ssh
  input: "bluetoothctl power off"

Anyway, EQ3 stopped working at all in my case :-(. I just see them unavailable and even those commands in terminal don't help :-(. Sometimes after host reboot they are available a few minutes and commands work in web terminal.

Then after some time I get: No default controller available

And need to restart Raspberry

[bazyl78]

OK @nvanofwegen :). Finally managed temporary workaround with this automation triggered every 1 minute. Thanks for suggestion.

• id: '1579634862062' alias: Bluetooth restart fix description: Bluetooth toggle on/off every 1 minutes (workaround) trigger:
  • minutes: /1 platform: time_pattern condition: [] action:
  • data: addon: a0d7b954_ssh input: sudo bluetoothctl power off service: hassio.addon_stdin
  • delay: '00:00:03'
  • data: addon: a0d7b954_ssh input: sudo bluetoothctl power on service: hassio.addon_stdin

Replace bullets with '-'

[nvanofwegen]

@bazyl78 I made the entry calling bluetoothctl power off && bluetoothctl power on every minute. So it's basically the same with the two commands and delay together. Thanks for your hassio.addon_stdin suggestion!

[rytilahti]

@bazyl78 my understanding is that this needs to be somewhere deeper in homeassistant (and/or potentially in the underlying bluetooth library bluepy, or even below that layer), see my response here: https://github.com/home-assistant/home-assistant/pull/11555#issuecomment-357815259 .

As I'm not actively using these devices (I have merely one for testing as I'm "maintaining" python-eq3bt..), nor do I have expertise on those lower level interfaces, I cannot be much help here. If someone knows a fix for this, I'd be happy to hear, and I can help with code reviews and testing.

So, if someone wants to step up and find a working solution, that would be great, but I would not hold breath considering this is not a new problem, sorry... @zewelor mentions about using his bt-mqtt gateway with great success, so that could be a potential way to go around some issues around this topic.

[garret]

@bazyl78 I tried to format better your automation as code to copy/paste for others:

  - alias: Bluetooth restart fix
    description: Bluetooth toggle on/off every 1 minutes (workaround)
    trigger:
      platform: time_pattern
      minutes: /1
    action:
      - service: hassio.addon_stdin
        data:
          addon: a0d7b954_ssh
          input: sudo bluetoothctl power off
      - delay: '00:00:03'
      - service: hassio.addon_stdin
        data:
          addon: a0d7b954_ssh
          input: sudo bluetoothctl power on

But it doesn't work... So I connected via SSH to my Hassio and gave the commands manually to turn off/on the bluetooth but they are still not recognized. How come?

~ $ bluetoothctl power off
-bash: bluetoothctl: command not found
~ $ sudo bluetoothctl power off
-bash: sudo: command not found
~ $

Additionally, I wanted to ask if it isn't bad for the raspberry pi hardware to have continuously this turning on or off. And why not every 15 min for instance? What if when you give the command is actually in the phase of turning off/on? I guess the command will not get to the valve.

[zewelor]

From my experience ( regarding work on bluetooth <-> mqtt gateway ) most problems with bluetooth on rpi is due to old bluez ( which doesn't work well with BLE ). First advice is to upgrade to newest bluez https://github.com/zewelor/bt-mqtt-gateway/wiki/Upgrade-Bluez-on-Raspbian . That fixes most problems with connection usually.

[garret]

@zewelor what if you have Hassio?

[zewelor]

Maybe its using some newer bluez, I think minimum version is 5.48. If not then I have to experience on upgrading bluez on hassio. Then I would recommend separate rpizw with https://github.com/zewelor/bt-mqtt-gateway to use as separate bluetooth gateway. Or maybe use esp32 with esphome as bluetooth gateway.

[bazyl78]

You need ssh & web terminal addon installed

śr., 22 sty 2020, 10:57 użytkownik Enzo notifications@github.com napisał:

@bazyl78 https://github.com/bazyl78 I tried to format better your automation as code to copy/paste for others:

• alias: Bluetooth restart fix description: Bluetooth toggle on/off every 1 minutes (workaround) trigger: platform: time_pattern minutes: /1 action:
  • service: hassio.addon_stdin data: addon: a0d7b954_ssh input: sudo bluetoothctl power off
  • delay: '00:00:03'
  • service: hassio.addon_stdin data: addon: a0d7b954_ssh input: sudo bluetoothctl power on

But it doesn't work... So I connected via SSH to my Hassio and gave the commands manually to turn off/on the bluetooth but they are still not recognized. How come?

~ $ bluetoothctl power off -bash: bluetoothctl: command not found ~ $ sudo bluetoothctl power off -bash: sudo: command not found ~ $

Additionally, I wanted to ask if it isn't bad for the raspberry pi hardware to have continuously this turning on or off. And why not every 15 min for instance? What if when you give the command is actually in the phase of turning off/on? I guess the command will not get to the valve.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/home-assistant/home-assistant/issues/28601?email_source=notifications&email_token=AEOKNI5Z55TOYLY5XY7RE2DQ7AJ7ZA5CNFSM4JKCEUE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJS6GAI#issuecomment-577102593, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEOKNI75CRM7UWEPK5XOCFLQ7AJ7ZANCNFSM4JKCEUEQ .

[garret]

@bazyl78 Thank you, I uninstalled the official "SSH server" addon and installed the one you told me and now I can control the bluetooth on Hassio by the web terminal.

So in the automation the "hassio.addon_stdin" is needed to communicate with the ssh & web terminal addon? Should I also keep "a0d7b954_ssh" in my automation or that changes from installation to installation (so in my case would be different)?

What about my other questions? I re-paste them again:

Isn't it bad for the raspberry pi hardware to have continuously this turning on or off of the blueooth? And why not every 15 min for instance? What if when you give the command is actually in the phase of turning off/on? I guess the command will not get to the valve?

[bazyl78]

You should keep "a0d7b954_ssh" in your automation

czw., 23 sty 2020, 10:27 użytkownik Enzo notifications@github.com napisał:

@bazyl78 https://github.com/bazyl78 Thank you, I uninstalled the official "SSH server" addon and installed the one you told me and now I can control the bluetooth on Hassio by the web terminal.

So in the automation the "hassio.addon_stdin" is needed to communicate with the ssh & web terminal addon? Should I also keep "a0d7b954_ssh" in my automation or that changes from installation to installation (so in my case would be different)?

What about my other questions? I re-paste them again:

Isn't it bad for the raspberry pi hardware to have continuously this turning on or off of the blueooth? And why not every 15 min for instance? What if when you give the command is actually in the phase of turning off/on? I guess the command will not get to the valve?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/home-assistant/home-assistant/issues/28601?email_source=notifications&email_token=AEOKNI4ETGW27Q23UXGK3P3Q7FPJ3A5CNFSM4JKCEUE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJWXE7I#issuecomment-577598077, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEOKNI4RQZSYF2OX6FWRHGTQ7FPJ3ANCNFSM4JKCEUEQ .

[garret]

@bazyl78 the automation/workaround does not work at all for me :( Does it still work to you?

[nvanofwegen]

@garret The ssh automation/workaround seemed to work in the first place for me, but still after a while the restart commands did nothing anymore. So I kinda gave up on this workaround approach. Thanks to the suggestion of @zewelor I started looking for another bluetooth device. Since I had a spare ESP32, I installed esp32_mqtt_eq3 and this works stable for 2 days straight now.

[nikidimi]

There is some issue while trying to send command to multiple BLE devices. I think it should be done sequentially, as discussed here: https://github.com/home-assistant/home-assistant/pull/11555

I've managed to create a stable solution by installing bt-mqtt-gateway on the same host as HASS (in my case - Raspberry Pi 3)

Quick guide to do so:

1. Install Configurator, Mosquitto broker and Portainer from Add-on store
2. Add a new user with a strong random password
3. Create a new file with Configurator. For example mqtt.yaml
4. Edit mqtt.yaml to configure bt-mqtt-gateway. Use the user from step 2. Quick example:

   
   mqtt:                             
   host: 127.0.0.1           
   port: 1883                                                                                                                   
   username: user                                                                                                   
   password: password                                                                                                                        
   client_id: bt-mqtt-gateway                           
   availability_topic: lwt_topic                                    

manager:
sensor_config:
topic: homeassistant retain: true
topic_subscription:
update_all:
topic: homeassistant/status
payload: online
command_timeout: 35 workers:
thermostat:
args:
devices:
kitchen:
mac: 00:11:22:33:44:55
topic_prefix: thermostat
topic_subscription: thermostat/+/+/set
update_interval: 60

5. Enable Portainer and disable protection mode
6. Add a new container with the  following settings:
- Image: zewelor/bt-mqtt-gateway:latest
- Network: host
- Mount the config file. Use bind mount with container: /config.yaml and host: /mnt/data/supervisor/homeassistant/mqtt.yaml
7. The devices should appear in Configuration->Integration->MQTT

P.S If you are using Raspberry Pi 3 (only the non-plus version), check out this issue: https://github.com/raspberrypi/firmware/issues/1150. 
This is a different problem. Workaround is by changing the UART speed in  `/usr/bin/btuart`. This is a bit complicated in HassOS because of the read-only root filesystem, but doable 

[garret]

@nikidimi thank you so much for your input! It has been really bothering me that with the powerful hardware of the raspberry pi I would have to use another device (e.g. ESP32) to get the valves working.

Your guide is very clear and thank you for that. However, I have some questions:

1. Since I have two valves, should I just add the other device in the devices: section. So something like this:

   
   [..]
      args:                    
       devices:                            
         kitchen:   
           mac: 00:11:22:33:44:55
         bedroom:
       mac: AA:BB:CC:DD:EE:FF
       topic_prefix: thermostat  
   [..]

2. I am a noob with docker (and so portainer). I installed portainer from the add-on store, disabled protection mode and started. On the portainer web interface I I added a container in "primary". I think I managed to pull the image and set up the network but don't understand  what I should do when you write  _"Mount the config file. Use bind mount with container: /config.yaml and host: /mnt/data/supervisor/homeassistant/mqtt.yaml"_. 
May I kindly ask you to be more detailed on what to do at this step? 

3. I have a Raspberry Pi 3B+ with the latest version of Hassio. In the end of your message you write something about a firmware issue. However, I should not follow that because is for people who have the previous model of raspberry pi?  

[nikidimi]

@garret

1. Yes, that's correct. You can see https://github.com/zewelor/bt-mqtt-gateway/blob/master/config.yaml.example for more examples.

2. Here is a more detailed guide. Go to Containers->Add container. In Advanced settings (bottom of the page) selected volumes, then click "map additional volume" and then click the "Bind" button. The /mnt/data/supervisor/homeassistant directory is the directory that contains Home Assistant configuration.yaml, so if you place mqtt.yaml in the same directory, this is the correct configuration: On the network tab:

3. No, it's only for Raspberry Pi 3B, it's has been improved in terms of hardware for the 3B+ and 4

[garret]

@nikidimi Thank you so much. You are so clear and detailed in your explanations! I think I managed to set up everything as you write but cannot still see my valve in Configuration->Integration->MQTT.

The reason might be that I found out I have a Raspberry Pi 3 Model B Rev 1.2 (and not B+ as I originally thought 🤦‍♂️).

Thus, hopefully for the last time, could I kindly ask to share the procedure to adjust this UART speed also for my model of Raspberry Pi? Consider I have the latest Hassio running on my raspberry pi.

[bazyl78]

Wow @nikidimi !!! That is really helpfull. Thank you so much.

[nikidimi]

@garret It should work without the UART speed patch (it's just not very stable), so let's get it working first. Did you create an user in Home Assistant and did you modify mqtt.yaml accordingly? You can also see the logs - from Home Assistant and from the bt-mqtt-gateway container (The first button next to "Running" in the container list is the log)

[garret]

@nikidimi Thank you a lot for your so fast support! I really hope to get these valves working again because now it's the time of the year I need them most 🙈

I will recap what I did and my configuration:

This is Portainer installed & started with protection mode disabled:

I created this user mqtt with a strong password from Hassio:

This is the file mqtt.yaml which I created in the same Hassio folder where my configuration.yamlis sitting (maybe this directory is the mistake?):

This is my containers list from Portainer with the bt-mqtt-gateway running:

This is the volumes section:

And this is the network part:

Finally, this is how the Mosquitto integration looks in Hassio:

It is only showing my battery phone which is due to another package I have installed, but as you can notice I don't see the two valves 😣

EDIT: From the container log I can see there seems to be a connection issue:

Start in normal mode,
11:05:30 Starting,
WARNING: pip is being invoked by an old script wrapper. This will fail in a future version of pip.,
Please see https://github.com/pypa/pip/issues/5599 for advice on fixing the underlying issue.,
To avoid this problem you can invoke Python with '-m pip' instead of running pip directly.,
11:05:32 Adding 1 thermostat devices,
Traceback (most recent call last):,
  File "./gateway.py", line 83, in <module>,
    manager.start(mqtt),
  File "/application/workers_manager.py", line 157, in start,
    mqtt.callbacks_subscription(self._mqtt_callbacks),
  File "/application/mqtt.py", line 112, in callbacks_subscription,
    self.mqttc.connect(self.hostname, port=self.port),
  File "/usr/local/lib/python3.8/site-packages/paho/mqtt/client.py", line 937, in connect,
    return self.reconnect(),
  File "/usr/local/lib/python3.8/site-packages/paho/mqtt/client.py", line 1071, in reconnect,
    sock = self._create_socket_connection(),
  File "/usr/local/lib/python3.8/site-packages/paho/mqtt/client.py", line 3522, in _create_socket_connection,
    return socket.create_connection(addr, source_address=source, timeout=self._keepalive),
  File "/usr/local/lib/python3.8/socket.py", line 808, in create_connection,
    raise err,
  File "/usr/local/lib/python3.8/socket.py", line 796, in create_connection,
    sock.connect(sa),
ConnectionRefusedError: [Errno 111] Connection refused,

[nikidimi]

@garret It cannot connect to the MQTT broker. Check the following:

1. Is "Mosquitto broker" running (Hass.io->Dashboard)?
2. Is the password correct?
3. Try restarting the container from Portainer

[zewelor]

Maybe restart mosquitto addon, after creating new user, it might need to restart to see it

[garret]

@nikidimi I am very sure the MQTT broker is running, also because I am using it with another package to check batteries of all my remotes and phones. In any case, I removed it from the integrations page and manually re-added with the mqtt username and its password (and enabled discovery). Again, I can see all my batteries but no valves.

This is also a proof Mosquitto is running:

I don't know if it's related to the issue but isn't it strange that when I go to the containers page it mentions there is 1 container but says 0 running?

If I click on containers this is however the view, and it seems I have 1 container running:

Before posting my previous post I had restarted the container, the add-ons, home assistant and even rebooted many times. This is also to reply to @zewelor 🙂 However, I cannot still see my valves and still get the same error if I look at the log of the container. It's a pity, I think I am so close to get them working but cannot understand what is missing! 😪

EDIT: I am also adding some screens from the bt-mqtt-gateway container info page, just for you to double check everything looks ok:

[nikidimi]

@garret Sorry, my mistake. The screenshot was wrong. Using host: 127.0.0.1 only works if the container network is "host".

[garret]

@nikidimi Thanks now everything seem to work! I knew I was very close. I hope it will last until the winter is gone! You are my hero!

EDIT: I can already see that my valves are in unknown state when I restart (not reboot) home assistant. Is it due to the UART? So I still see in a situation very similar as before...

[nikidimi]

@garret Yes, if they stay for more than an coupe of minutes this way, something is not working correctly. If the container is running, then it's probably the UART speed. Check the logs of the container.

For the UART speed - you have to change the speed in /usr/bin/btuart. The problem is that HassOS uses a read-only filesystem for the OS. I'm not sure that there is no other way, but what I did is follow this guide: https://blog.sleeplessbeastie.eu/2012/05/27/how-to-modify-squashfs-image/

Warning: Don't do this on your computer if you don't have experience with Linux. There are some commands that can delete the data not only on your SD card, but also on local drives (if you enter the wrong arguments)

1. Connect the SD card to a computer running Linux (If you are using a different OS, I suggest booting a live USB Ubuntu image, there is no need to install it)
2. Start a terminal and type mount. Try to find the entry named squashfs. It should be something like /dev/sdXX on /media/ubuntu/some-name type squashfs (ro,nosuid,nodev,relatime,uhelper=udisks2)
3. Type cat /media/ubuntu/some-name/usr/bin/btuart to check if this is the correct device that contains this file
4. Go to some empty directory (or create one) using cd
5. Type umount /dev/sdXX and unsquashfs /dev/sdXX
6. This will extract the root filesystem into the current directory
7. Edit the file squashfs-root/usr/bin/btuart. Change the line in the else clause that reads : $HCIATTACH /dev/serial1 bcm43xx 921600 noflow - $BDADDR to $HCIATTACH /dev/serial1 bcm43xx 115200 noflow - $BDADDR
8. This command has the potential to destroy your data if you specify the wrong device. Write back the root filesystem to the SD card: mksquashfs squashfs-root/ /dev/sdXX -noappend -comp lz4 -Xhc

[garret]

@nikidimi I'm so sad... essentially the valves are behaving exactly as if I had added them through their normal integration. So if I reboot Hassio everything works but after few minutes they become unavailable and cannot send/see any status from them.

Thank you for your guide about how to get eventually the UART speed changed but I don't feel confident enough to go into it. But I am sure it could help other people :)

Nevertheless, I have a raspberry pi 3b+ always running with Dietpi. Maybe I could solve the issue by installing the container there and it connects to the Mosquitto broker on the Hassio raspberry pi? What do you think? If yes, what should I change exactly?

Thank you very much again!

This is the current log from the container:

Start in normal mode,
17:12:07 Starting,
WARNING: pip is being invoked by an old script wrapper. This will fail in a future version of pip.,
Please see https://github.com/pypa/pip/issues/5599 for advice on fixing the underlying issue.,
To avoid this problem you can invoke Python with '-m pip' instead of running pip directly.,
17:12:10 Adding 2 thermostat devices,
Traceback (most recent call last):,
  File "./gateway.py", line 83, in <module>,
    manager.start(mqtt),
  File "/application/workers_manager.py", line 157, in start,
    mqtt.callbacks_subscription(self._mqtt_callbacks),
  File "/application/mqtt.py", line 112, in callbacks_subscription,
    self.mqttc.connect(self.hostname, port=self.port),
  File "/usr/local/lib/python3.8/site-packages/paho/mqtt/client.py", line 937, in connect,
    return self.reconnect(),
  File "/usr/local/lib/python3.8/site-packages/paho/mqtt/client.py", line 1071, in reconnect,
    sock = self._create_socket_connection(),
  File "/usr/local/lib/python3.8/site-packages/paho/mqtt/client.py", line 3522, in _create_socket_connection,
    return socket.create_connection(addr, source_address=source, timeout=self._keepalive),
  File "/usr/local/lib/python3.8/socket.py", line 808, in create_connection,
    raise err,
  File "/usr/local/lib/python3.8/socket.py", line 796, in create_connection,
    sock.connect(sa),
ConnectionRefusedError: [Errno 111] Connection refused,
Start in normal mode,
17:12:14 Starting,
WARNING: pip is being invoked by an old script wrapper. This will fail in a future version of pip.,
Please see https://github.com/pypa/pip/issues/5599 for advice on fixing the underlying issue.,
To avoid this problem you can invoke Python with '-m pip' instead of running pip directly.,
17:12:17 Adding 2 thermostat devices,
17:12:18 Updating 2 thermostat devices,
17:13:18 Updating 2 thermostat devices,
17:14:18 Updating 2 thermostat devices,
17:15:18 Updating 2 thermostat devices,
17:16:18 Updating 2 thermostat devices,
17:17:18 Updating 2 thermostat devices,
17:18:18 Updating 2 thermostat devices,
17:19:18 Updating 2 thermostat devices,
17:19:24 Error during update of thermostat device 'bedroom' (00:1A:22:0E:58:8B): BTLEDisconnectError,
17:20:18 Updating 2 thermostat devices,
17:20:53 Execution of command ThermostatWorker.status_update timed out after 35 seconds,
17:21:18 Updating 2 thermostat devices,
17:22:18 Updating 2 thermostat devices,
17:22:53 Execution of command ThermostatWorker.status_update timed out after 35 seconds, sending only partial update,
17:23:18 Updating 2 thermostat devices,
17:23:25 Error during update of thermostat device 'bedroom' (00:1A:22:0E:58:8B): BTLEDisconnectError,
17:24:18 Updating 2 thermostat devices,
17:24:24 Error during update of thermostat device 'bedroom' (00:1A:22:0E:58:8B): BTLEDisconnectError,
17:25:18 Updating 2 thermostat devices,
17:26:18 Updating 2 thermostat devices,
17:27:18 Updating 2 thermostat devices,
17:27:53 Execution of command ThermostatWorker.status_update timed out after 35 seconds,
17:28:18 Updating 2 thermostat devices,
17:28:56 Setting mode to Mode.Manual on thermostat device 'living_room' (00:1A:22:0E:0E:2E),
17:29:18 Updating 2 thermostat devices,
17:29:24 Error during update of thermostat device 'bedroom' (00:1A:22:0E:58:8B): BTLEDisconnectError,
17:29:31 Error during update of thermostat device 'living_room' (00:1A:22:0E:0E:2E): BTLEDisconnectError,
17:30:18 Updating 2 thermostat devices,

[nikidimi]

@garret Yes, this is due to the UART speed.

You can run the docker container on another host using docker run -d --name bt-mqtt-gateway --network=host -v $PWD/config.yaml:/config.yaml zewelor/bt-mqtt-gateway This will look for the config file under the name config.yaml inside the current directory The only thing to do before that is to copy the config file (mqtt.yaml), change the host: 127.0.0.1 to reflect the IP address of Home Assistant and rename it to config.yaml.

[garret]

@nikidimi I tried it but now seems that on the raspberry pi 3b+ can't connect to the valves as I always get a BTLEDisconnectError (and I stopped the container I had created on Hassio through Portainer).

This is the log from the new container on the raspberry pi 3b+ with dietpi:

root@DietPi:~# docker logs 15e9f3350427
Start in normal mode
20:09:20 Starting
WARNING: pip is being invoked by an old script wrapper. This will fail in a future version of pip.
Please see https://github.com/pypa/pip/issues/5599 for advice on fixing the underlying issue.
To avoid this problem you can invoke Python with '-m pip' instead of running pip directly.
20:09:22 Adding 2 thermostat devices
20:09:23 Updating 2 thermostat devices
20:09:23 Error during update of thermostat device 'bedroom' (00:1A:22:0E:58:8B): BTLEDisconnectError
20:09:23 Error during update of thermostat device 'living_room' (00:1A:22:0E:0E:2E): BTLEDisconnectError
20:10:23 Updating 2 thermostat devices
20:10:23 Error during update of thermostat device 'bedroom' (00:1A:22:0E:58:8B): BTLEDisconnectError
20:10:23 Error during update of thermostat device 'living_room' (00:1A:22:0E:0E:2E): BTLEDisconnectError
20:11:23 Updating 2 thermostat devices
20:11:23 Error during update of thermostat device 'bedroom' (00:1A:22:0E:58:8B): BTLEDisconnectError
20:11:23 Error during update of thermostat device 'living_room' (00:1A:22:0E:0E:2E): BTLEDisconnectError
20:12:23 Updating 2 thermostat devices
20:12:23 Error during update of thermostat device 'bedroom' (00:1A:22:0E:58:8B): BTLEDisconnectError
20:12:23 Error during update of thermostat device 'living_room' (00:1A:22:0E:0E:2E): BTLEDisconnectError
20:13:23 Updating 2 thermostat devices
root@DietPi:~#

I can easily connect to the valves with the app on my phone. I can still see the valves created from the old container. Is that normal? Should have not these be automatically deleted once I stopped the old container on Hassio? And apparently it seems I cannot see the "new valves" from the new container in the raspberry pi 3b+

EDIT: I think I understood what was the problem, general bluetooth was disabled on DietPi and had to enable it from dietpi-launcher.

So as I understand now I should not have any issues anymore. Let's see if it will last long enough 😅

Thank you again @nikidimi, you deserve a statue!

[garret]

@nikidimi I've been using bt-mqtt-gateway for some time now since I managed to get it working thanks to your input. However, I've noticed that sometimes the status of both valves is not updated anymore and also the commands are not sent. When checking the logs of the docker container, you don't see any errors but at the same there are no "command successfully sent to the valve" line in the log. Currently, I solve this issue by restarting the docker container. So it seems there is always the same problem going on that you need to periodically restart the "system" to get it working again.

Have you experienced the same?

I was thinking to add a crontab rule where I restart the container every 6 hours though it's sad that you still have to always recur to so many workarounds to have something working in a decent fashion.

[zewelor]

@garret Are you using newest bluez ?

[garret]

@zewelor I am using bluez 5.43-2+rpt2+deb9u2 on a rp3b+ with DietPi as operating system. The system is fully updated at the moment of writing.

[zewelor]

Thats very old, you need to upgrade it by hand somehow, to get reliable BLE. Minimum recommended version is 5.48, and I would suggest newest possible. It usually solves all of the problems. Old bluez works very bad for ble.

[stale[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[FaserF]

Hmm, I now a raspberry pi4 and for me its getting even worse. One of the two thermostats doesnt even connect once, the other one looses its connection after a few hours. @rytilahti any idea?

[garret]

@FaserF I don't own a raspberry pi4 but have you tried the bt-mqtt-gateway solution described previously in this thread? To me it was the only one that solved the issue (on a raspberry pi3 though).

[FaserF]

I had tried it a few months ago, for me it wasnt better with the gateway.

by the way, if anybody is interested, I have created a bt-mqtt-gateway hassio addon: https://github.com/FaserF/hassio-addons/tree/master/bt-mqtt-gateway

So we dont have to do it so "complicated" with potainer.

[nls-hffmnn]

Thank you @FaserF for your hassio-Addon. That helped me a lot!

After setting everything up I get the same error all the time... with the eq3bt I was able to get data from the devices. Now it is not even able to establish any connection...

Found config file at /share/bt-mqtt-gateway.yaml . Copying it now. Starting bt-mqtt gateway in normal mode If there are any bugs occuring below this line, please report it to the bt-mqtt-gateway developer and not to @FaserF - thanks. 22:55:25 Starting WARNING: pip is being invoked by an old script wrapper. This will fail in a future version of pip. Please see https://github.com/pypa/pip/issues/5599 for advice on fixing the underlying issue. To avoid this problem you can invoke Python with '-m pip' instead of running pip directly. WARNING: You are using pip version 20.0.2; however, version 20.2.3 is available. You should consider upgrading via the '/usr/local/bin/python3 -m pip install --upgrade pip' command. 22:55:28 Adding 3 thermostat devices 22:55:29 Updating 3 thermostat devices 22:55:29 Error during update of thermostat device 'Wohnzimmer' (00:1A:22:0F:CC:24): BTLEDisconnectError 22:55:29 Error during update of thermostat device 'Badezimmer' (00:1A:22:0F:CB:F9): BTLEDisconnectError 22:55:29 Error during update of thermostat device 'Schlafzimmer' (00:1A:22:0F:CB:22): BTLEDisconnectError

Any ideas?

[FaserF]

@nls-hffmnn I have exactly the same issue. And to me it doesn't look like a issue with my add-on, as I receive the same error message with the manual setup with portainer. Looks like this issue here: https://github.com/zewelor/bt-mqtt-gateway/issues/64