Connection to ioBroker is getting lost after a few seconds.

[MikeHotel0815]

I pushed the following yaml to my ESP32. All went fine and the ESP32 is connecting to ioBroker.

` substitutions: name: jkbms01 device_description: "Monitor and control a JK-BMS via bluetooth" external_components_source: github://syssi/esphome-jk-bms@main mac_address: xx:xx:xx:xx:xx:xx protocol_version: JK02

esphome: name: bms01 comment: "Monitor and control a JK-BMS via bluetooth" project: name: "syssi.esphome-jk-bms" version: 1.1.0

esp32: board: wemos_d1_mini32 framework: type: esp-idf version: latest

external_components:

• source: ${external_components_source} refresh: 0s

wifi: ssid: !secret wifi_ssid password: !secret wifi_password manual_ip:

Set this to the IP of the ESP

static_ip: 10.22.22.110
# Set this to the IP address of the router. Often ends with .1
gateway: 10.0.0.1
# The subnet of the network. 255.255.255.0 works for most home networks.
subnet: 255.0.0.0

ota:

logger:

api:

esp32_ble_tracker:

ble_client:

• mac_address: ${mac_address} id: client0

jk_bms_ble:

• ble_client_id: client0 protocol_version: ${protocol_version} throttle: 5s id: bms0

binary_sensor:

• platform: jk_bms_ble balancing: name: "${name} balancing" charging: name: "${name} charging" discharging: name: "${name} discharging"

button:

• platform: jk_bms_ble retrieve_settings: name: "${name} retrieve settings" retrieve_device_info: name: "${name} retrieve device info"

number:

• platform: jk_bms_ble jk_bms_ble_id: bms0 balance_trigger_voltage: name: "${name} balance trigger voltage" cell_count: name: "${name} cell count" total_battery_capacity: name: "${name} total battery capacity" cell_voltage_overvoltage_protection: name: "${name} cell voltage overvoltage protection" cell_voltage_overvoltage_recovery: name: "${name} cell voltage overvoltage recovery" cell_voltage_undervoltage_protection: name: "${name} cell voltage undervoltage protection" cell_voltage_undervoltage_recovery: name: "${name} cell voltage undervoltage recovery" balance_starting_voltage: name: "${name} balance starting voltage" voltage_calibration: name: "${name} voltage calibration" current_calibration: name: "${name} current calibration" power_off_voltage: name: "${name} power off voltage" max_balance_current: name: "${name} max balance current" max_charge_current: name: "${name} max charge current" max_discharge_current: name: "${name} max discharge current"

sensor:

• platform: jk_bms_ble jk_bms_ble_id: bms0 min_cell_voltage: name: "${name} min cell voltage" max_cell_voltage: name: "${name} max cell voltage" min_voltage_cell: name: "${name} min voltage cell" max_voltage_cell: name: "${name} max voltage cell" delta_cell_voltage: name: "${name} delta cell voltage" average_cell_voltage: name: "${name} average cell voltage" cell_voltage_1: name: "${name} cell voltage 1" cell_voltage_2: name: "${name} cell voltage 2" cell_voltage_3: name: "${name} cell voltage 3" cell_voltage_4: name: "${name} cell voltage 4" cell_voltage_5: name: "${name} cell voltage 5" cell_voltage_6: name: "${name} cell voltage 6" cell_voltage_7: name: "${name} cell voltage 7" cell_voltage_8: name: "${name} cell voltage 8" cell_voltage_9: name: "${name} cell voltage 9" cell_voltage_10: name: "${name} cell voltage 10" cell_voltage_11: name: "${name} cell voltage 11" cell_voltage_12: name: "${name} cell voltage 12" cell_voltage_13: name: "${name} cell voltage 13" cell_voltage_14: name: "${name} cell voltage 14" cell_voltage_15: name: "${name} cell voltage 15" cell_voltage_16: name: "${name} cell voltage 16" cell_voltage_17: name: "${name} cell voltage 17" cell_voltage_18: name: "${name} cell voltage 18" cell_voltage_19: name: "${name} cell voltage 19" cell_voltage_20: name: "${name} cell voltage 20" cell_voltage_21: name: "${name} cell voltage 21" cell_voltage_22: name: "${name} cell voltage 22" cell_voltage_23: name: "${name} cell voltage 23" cell_voltage_24: name: "${name} cell voltage 24" cell_resistance_1: name: "${name} cell resistance 1" cell_resistance_2: name: "${name} cell resistance 2" cell_resistance_3: name: "${name} cell resistance 3" cell_resistance_4: name: "${name} cell resistance 4" cell_resistance_5: name: "${name} cell resistance 5" cell_resistance_6: name: "${name} cell resistance 6" cell_resistance_7: name: "${name} cell resistance 7" cell_resistance_8: name: "${name} cell resistance 8" cell_resistance_9: name: "${name} cell resistance 9" cell_resistance_10: name: "${name} cell resistance 10" cell_resistance_11: name: "${name} cell resistance 11" cell_resistance_12: name: "${name} cell resistance 12" cell_resistance_13: name: "${name} cell resistance 13" cell_resistance_14: name: "${name} cell resistance 14" cell_resistance_15: name: "${name} cell resistance 15" cell_resistance_16: name: "${name} cell resistance 16" cell_resistance_17: name: "${name} cell resistance 17" cell_resistance_18: name: "${name} cell resistance 18" cell_resistance_19: name: "${name} cell resistance 19" cell_resistance_20: name: "${name} cell resistance 20" cell_resistance_21: name: "${name} cell resistance 21" cell_resistance_22: name: "${name} cell resistance 22" cell_resistance_23: name: "${name} cell resistance 23" cell_resistance_24: name: "${name} cell resistance 24" total_voltage: name: "${name} total voltage" current: name: "${name} current" power: name: "${name} power" charging_power: name: "${name} charging power" discharging_power: name: "${name} discharging power" temperature_sensor_1: name: "${name} temperature sensor 1" temperature_sensor_2: name: "${name} temperature sensor 2" power_tube_temperature: name: "${name} power tube temperature" state_of_charge: name: "${name} state of charge" capacity_remaining: name: "${name} capacity remaining" total_battery_capacity_setting: name: "${name} total battery capacity setting" charging_cycles: name: "${name} charging cycles" total_charging_cycle_capacity: name: "${name} total charging cycle capacity" total_runtime: name: "${name} total runtime" balancing_current: name: "${name} balancing current" errors_bitmask: name: "${name} errors bitmask"

switch:

• platform: jk_bms_ble charging: name: "${name} charging" discharging: name: "${name} discharging" balancer: name: "${name} balancer"

• platform: ble_client ble_client_id: client0 name: "${name} enable bluetooth connection"

text_sensor:

• platform: jk_bms_ble errors: name: "${name} errors" total_runtime_formatted: name: "${name} total runtime formatted" `

But after a few seconds. I am getting a

[08:43:30][W][api.connection:080]: iobrokermaster (::FFFF:10.200.200.1): Connection closed

The connection is not coming back at all.

Can anyone give me some help?

Thanx in advance!

[MikeHotel0815]

Sorry, the CODE Tag is not working!?

[Yosh1977]

I have the same problem. Anyone an idea ?

[Yosh1977]

I have the same problem. Anyone an idea ?

That ist my Yaml

`esphome: name: test

esp8266: board: esp01_1m

logger:

api:

ota: password: "58806ed2e79dac18f843ff7f75c227a7"

wifi: ssid: !secret wifi_ssid password: !secret wifi_password

ap: ssid: "Test Fallback Hotspot" password: "nu2Pe4AN9p4g"

substitutions: device_name: test

captive_portal:

web_server: port: 80

binary_sensor:

• platform: gpio name: mmwave_in_bedroom pin: number: GPIO16 mode: INPUT_PULLDOWN

uart: id: uart_bus tx_pin: GPIO4 rx_pin: GPIO5 baud_rate: 115200 debug: direction: BOTH dummy_receiver: true after: delimiter: "\n" sequence:

• lambda: UARTDebug::log_string(direction, bytes);

number:

• platform: template name: distance id: distance min_value: 0 max_value: 1350 initial_value: 315 optimistic: true step: 15 restore_value: true unit_of_measurement: cm set_action:

  • uart.write: "sensorStop"
  • delay: 1s
  • uart.write: !lambda int cm = (int)ceil(x / 15.0); std::string cms = "detRangeCfg -1 0 " + to_string(cm); return std::vector(cms.begin(), cms.end());
  • delay: 1s
  • uart.write: "saveCfg 0x45670123 0xCDEF89AB 0x956128C6 0xDF54AC89"
  • delay: 1s
  • uart.write: "sensorStart"

• platform: template name: latency id: latency min_value: 0 max_value: 65000 initial_value: 12500 optimistic: true step: 25 restore_value: true unit_of_measurement: ms set_action:

  • uart.write: "sensorStop"
  • delay: 1s
  • uart.write: !lambda int ms = (int)ceil(x / 25.0); std::string mss = "outputLatency -1 0 " + to_string(ms); return std::vector(mss.begin(), mss.end());
  • delay: 1s
  • uart.write: "saveCfg 0x45670123 0xCDEF89AB 0x956128C6 0xDF54AC89"
  • delay: 1s
  • uart.write: "sensorStart"

button:

• platform: restart name: Restart $device_name

• platform: template name: "factory_reset_sensor" id: "factory_reset_sensor" on_press:

  • uart.write: "sensorStop"
  • delay: 1s
  • uart.write: "factoryReset 0x45670123 0xCDEF89AB 0x956128C6 0xDF54AC89"
  • delay: 3s
  • uart.write: "sensorStart"`

An when I reduse it to

esphome: name: test

esp8266: board: esp01_1m

logger:

api:

ota: password: "58806ed2e79dac18f843ff7f75c227a7"

wifi: ssid: !secret wifi_ssid password: !secret wifi_password

ap: ssid: "Test Fallback Hotspot" password: "nu2Pe4AN9p4g"

substitutions: device_name: test

captive_portal:

web_server: port: 80

binary_sensor:

• platform: gpio name: mmwave_in_bedroom pin: number: GPIO16 mode: INPUT_PULLDOWN

uart: id: uart_bus tx_pin: GPIO4 rx_pin: GPIO5 baud_rate: 115200 debug: direction: BOTH dummy_receiver: true after: delimiter: "\n" sequence:

• lambda: UARTDebug::log_string(direction, bytes);

Than the connection still are connected

[stefan-3r]

I have the same problem -regardless of my yaml-config and my ESP-device (eg a Wemos D1 mini and a seperate NodeMCU V2).

What happens:

• Adapter (V0.2.4) is running fine, also the ESPHome-Dashboard.
• I can edit and flash new versions, see the logs in the dashboard, communicate via webserver of the ESPHomees with them.
• BUT: after every connection via ESPHome-API (in my case every 30 seconds, like configured in the esphome.0-instance) I get a connection, but after constant 5 seconds it gets closed again. For every device. I get the following error in the log of the ESPHomees:

  12:37:41 | [D] | [api:102] | Accepted 192.168.178.xxx
  12:37:46 | [W] | [api.connection:080] | raspi-bridge (192.168.178.xxx): Connection closed

  And in the log of the iobroker:

  esphome.0   2022-08-07 12:37:45.635 warn    Client 192.168.178.yyy Timeout, connection Lost, will reconnect automatically when device is available!
  esphome.0   2022-08-07 12:37:40.672 error   ESPHome client 192.168.178.yyy TypeError: Cannot read properties of undefined (reading 'deserializeBinary')
  esphome.0   2022-08-07 12:37:40.655 error   ESPHome client 192.168.178.yyy TypeError: Cannot read properties of undefined (reading 'deserializeBinary')

  When I switch to degug-output of the instance, I get the following befor each "cannot read properties...":

  esphome.0   2022-08-07 12:47:06.967 error   ESPHome client 192.168.178.yyy TypeError: Cannot read properties of undefined (reading 'deserializeBinary')
  esphome.0   2022-08-07 12:47:06.966 debug   192.168.178.yyy client data �T9�
  esphome.0   2022-08-07 12:47:06.934 error   ESPHome client 192.168.178.yyy TypeError: Cannot read properties of undefined (reading 'deserializeBinary')
  esphome.0   2022-08-07 12:47:06.933 debug   192.168.178.yyy client data �L��
  

  The strange bytes seem to vary over time.

I think, this problem was not there for the first few days I installed the ESP-Home-Adapter and occurs since last wednesday (august 3rd). But I am not sure. And I don't know what I changed since then with relation to iobroker...

What I tried since I encountered the problem:

• boot of course
• deinstalled and reinstalled the adapter and instance
• installed adapter and instance on second iobroker-host (ma slave, I user a multihost-setting) All with no effect.

My configuration is:

• iobroker multihost
• master: -- Raspi 4B -- iobroker-admin v5.3.8 -- iobroker-esphome v0.2.4
• slave: -- Raspi 3B
• on both: -- node v16.16.0, nodejs v16.16.0, npm v8.11.0 -- js-controller 4.0.23 -- Python v3.9.2

I attached two of my tested ESPHome-configs, both have this problem, also some different (filename is .yaml.txt instead of .yaml, because github says, .yaml is not allowed) briefkasten.yaml.txt basic.yaml.txt

I like the ESPHome-adapter and the whole concept very much. And even if I switch to direct MQTT-communication because of faster sending of sensor-data after wakeup from deep-sleep, I'd like to get it running via esphome - it's just so easy and fast to get things running (when it's all running ;-) ) So many thanx for your development, @DrozmotiX, and thanx in advance for your kind support!

Stefan

[Trrw]

Same problem