connecton to MQTT di a crash and reboot

i use the mosquitto MQTT and working fine with tasmota and other Programms.
But the i flash the JK-BMS to a esp then i get always this.
~/GIT/esphome-jk-bms$ ./test-esp8266.sh
INFO Reading configuration esp8266-example-faker.yaml...
INFO Generating C++ source...
INFO Compiling app...
Processing jk-bms (board: d1_mini; framework: arduino; platform: platformio/espressif8266 @ 3.2.0)
---------------------------------------------------------------------------------------------------------------------------------------
HARDWARE: ESP8266 80MHz, 80KB RAM, 4MB Flash
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
Dependency Graph
|-- ESP8266WiFi @ 1.0
|-- ESP8266mDNS @ 1.2
|-- AsyncMqttClient-esphome @ 0.8.6
|   |-- ESPAsyncTCP-esphome @ 1.2.3
|-- ArduinoJson @ 6.18.5
RAM:   [====      ]  43.5% (used 35640 bytes from 81920 bytes)
Flash: [====      ]  41.4% (used 432225 bytes from 1044464 bytes)
===================================================== [SUCCESS] Took 1.32 seconds =====================================================
INFO Successfully compiled program.
Found multiple options, please choose one:
  [1] /dev/ttyUSB0 (USB2.0-Ser!)
  [2] Over The Air (jk-bms.local)
(number): 1
esptool.py v3.3.1
Serial port /dev/ttyUSB0
Connecting....
Chip is ESP8266EX
Features: WiFi
Crystal is 26MHz
MAC: c8:c9:a3:5a:d1:f6
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Flash will be erased from 0x00000000 to 0x0006afff...
Compressed 436384 bytes to 293172...
Wrote 436384 bytes (293172 compressed) at 0x00000000 in 6.9 seconds (effective 507.4 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...
INFO Successfully uploaded program.
INFO Starting log output from /dev/ttyUSB0 with baud rate 115200
[12:17:29]rll\xb0r$\xe2n

                        \xc4
                            l\xc7
                                 b|\x8e\x90\x92rb\xc4
                                                     b\xf2nnlnnb
                                                                bp\x8c$blrlp\xf2n0

                                                                                \x90
                                                                                l
                                                                                \x8c

                                                                                b
                                                                                n\xe2n\xc7
                                                                                \xc4
                                                                                b\xc4\xf2nn'l\x8cl`\x90nn
                                                                                $`nr\x8e\x92\x92n

             rr\x92`p\xf2n0

                           r\x8c<b

                                  b
                                   n\xe2n

                                         b\xc4\xf2nn'
                                                     l`\x90nn
                                                             $`nr\x8e\x92\x92n

                                                                              rl`r\x92\x92n

                                                                                rl`\x9c

                                                                                \x8c$ll`\xfc\x82n\x92`[I][logger:243]: Log initialized
[12:17:29][C][ota:461]: There have been 2 suspected unsuccessful boot attempts.
[12:17:29][I][app:029]: Running\xfe\xa1\xff[C][wifi:037]: Setting up WiFi...
[12:17:29][D][wifi:373]: Starting scan...
[12:17:29]NWh)[I][jk_bms:062]: Status frame received
[12:17:29][D][sensor:126]: 'jk-bms cell voltage 1': Sending state 3.82100 V with 3 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms cell voltage 2': Sending state 3.83400 V with 3 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms cell voltage 3': Sending state 3.83100 V with 3 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms cell voltage 4': Sending state 3.82000 V with 3 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms cell voltage 5': Sending state 3.83200 V with 3 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms cell voltage 6': Sending state 3.83400 V with 3 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms cell voltage 7': Sending state 3.82500 V with 3 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms cell voltage 8': Sending state 3.83200 V with 3 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms cell voltage 9': Sending state 3.81100 V with 3 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms cell voltage 10': Sending state 3.83400 V with 3 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms cell voltage 11': Sending state 3.82500 V with 3 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms cell voltage 12': Sending state 3.83500 V with 3 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms cell voltage 13': Sending state 3.83500 V with 3 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms cell voltage 14': Sending state 3.82600 V with 3 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms min cell voltage': Sending state 3.81100 V with 3 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms max cell voltage': Sending state 3.83500 V with 3 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms max voltage cell': Sending state 12.00000  with 0 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms min voltage cell': Sending state 9.00000  with 0 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms delta cell voltage': Sending state 0.02400 V with 3 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms average cell voltage': Sending state 3.82821 V with 3 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms power tube temperature': Sending state 29.00000 °C with 0 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms temperature sensor 1': Sending state 30.00000 °C with 0 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms temperature sensor 2': Sending state 28.00000 °C with 0 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms total voltage': Sending state 53.59000 V with 2 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms current': Sending state 2.08000 A with 2 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms power': Sending state 111.46719 W with 2 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms charging power': Sending state 111.46719 W with 2 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms discharging power': Sending state 0.00000 W with 2 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms capacity remaining': Sending state 15.00000 % with 0 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms temperature sensors': Sending state 2.00000  with 0 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms charging cycles': Sending state 4.00000  with 0 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms total charging cycle capacity': Sending state 0.00000 Ah with 0 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms battery strings': Sending state 14.00000  with 0 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms errors bitmask': Sending state 0.00000  with 0 decimals of accuracy
[12:17:29][D][text_sensor:067]: 'jk-bms errors': Sending state ''
[12:17:29][D][sensor:126]: 'jk-bms operation mode bitmask': Sending state 7.00000  with 0 decimals of accuracy
[12:17:29][D][text_sensor:067]: 'jk-bms operation mode': Sending state 'Charging enabled;Discharging enabled;Balancer enabled'
[12:17:29][D][binary_sensor:036]: 'jk-bms balancing': Sending state ON
[12:17:29][D][binary_sensor:036]: 'jk-bms charging': Sending state ON
[12:17:29][D][binary_sensor:036]: 'jk-bms discharging': Sending state ON
[12:17:29][D][sensor:126]: 'jk-bms total voltage overvoltage protection': Sending state 56.70000 V with 2 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms total voltage undervoltage protection': Sending state 42.70000 V with 2 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms cell voltage overvoltage protection': Sending state 4.05000 V with 3 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms cell voltage overvoltage recovery': Sending state 4.00000 V with 3 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms cell voltage overvoltage delay': Sending state 5.00000 s with 0 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms cell voltage undervoltage protection': Sending state 3.05000 V with 3 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms cell voltage undervoltage recovery': Sending state 3.10000 V with 3 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms cell voltage undervoltage delay': Sending state 5.00000 s with 0 decimals of accuracy
[12:17:29][D][sensor:126]: 'jk-bms cell pressure difference protection': Sending state 0.30000 V with 3 decimals of accuracy
[12:17:30][D][sensor:126]: 'jk-bms discharging overcurrent protection': Sending state 7.00000 A with 0 decimals of accuracy
[12:17:30][D][sensor:126]: 'jk-bms discharging overcurrent delay': Sending state 3.00000 s with 0 decimals of accuracy
[12:17:30][D][sensor:126]: 'jk-bms charging overcurrent protection': Sending state 5.00000 A with 0 decimals of accuracy
[12:17:30][D][sensor:126]: 'jk-bms charging overcurrent delay': Sending state 5.00000 s with 0 decimals of accuracy
[12:17:30][D][sensor:126]: 'jk-bms balance starting voltage': Sending state 3.30000 V with 3 decimals of accuracy
[12:17:30][D][sensor:126]: 'jk-bms balance opening pressure difference': Sending state 0.00800 V with 3 decimals of accuracy
[12:17:30][D][binary_sensor:036]: 'jk-bms balancing switch': Sending state ON
[12:17:30][D][sensor:126]: 'jk-bms power tube temperature protection': Sending state 90.00000 °C with 0 decimals of accuracy
[12:17:30][D][sensor:126]: 'jk-bms power tube temperature recovery': Sending state 70.00000 °C with 0 decimals of accuracy
[12:17:30][D][sensor:126]: 'jk-bms temperature sensor temperature protection': Sending state 100.00000 °C with 0 decimals of accuracy
[12:17:30][D][sensor:126]: 'jk-bms temperature sensor temperature recovery': Sending state 100.00000 °C with 0 decimals of accuracy
[12:17:30][D][sensor:126]: 'jk-bms temperature sensor temperature difference protection': Sending state 20.00000 °C with 0 decimals of accuracy
[12:17:30][D][sensor:126]: 'jk-bms charging high temperature protection': Sending state 70.00000 °C with 0 decimals of accuracy
[12:17:30][D][sensor:126]: 'jk-bms discharging high temperature protection': Sending state 70.00000 °C with 0 decimals of accuracy
[12:17:30][D][sensor:126]: 'jk-bms charging low temperature protection': Sending state -20.00000 °C with 0 decimals of accuracy
[12:17:30][D][sensor:126]: 'jk-bms charging low temperature recovery': Sending state -10.00000 °C with 0 decimals of accuracy
[12:17:30][D][sensor:126]: 'jk-bms discharging low temperature protection': Sending state -20.00000 °C with 0 decimals of accuracy
[12:17:30][D][sensor:126]: 'jk-bms discharging low temperature recovery': Sending state -10.00000 °C with 0 decimals of accuracy
[12:17:30][D][sensor:126]: 'jk-bms total battery capacity setting': Sending state 14.00000 Ah with 0 decimals of accuracy
[12:17:30][D][sensor:126]: 'jk-bms capacity remaining derived': Sending state 2.10000 Ah with 0 decimals of accuracy
[12:17:30][D][binary_sensor:036]: 'jk-bms charging switch': Sending state ON
[12:17:30][D][binary_sensor:036]: 'jk-bms discharging switch': Sending state ON
[12:17:30][D][sensor:126]: 'jk-bms current calibration': Sending state 1.04100 A with 3 decimals of accuracy
[12:17:30][D][sensor:126]: 'jk-bms device address': Sending state 1.00000  with 0 decimals of accuracy
[12:17:30][D][text_sensor:067]: 'jk-bms battery type': Sending state 'Ternary Lithium'
[12:17:30][D][sensor:126]: 'jk-bms sleep wait time': Sending state 10.00000 s with 0 decimals of accuracy
[12:17:30][D][sensor:126]: 'jk-bms alarm low volume': Sending state 20.00000 % with 0 decimals of accuracy
[12:17:30][D][text_sensor:067]: 'jk-bms password': Sending state '123456'
[12:17:30][D][binary_sensor:036]: 'jk-bms dedicated charger switch': Sending state OFF
[12:17:30][D][text_sensor:067]: 'jk-bms device type': Sending state 'Input Us'
[12:17:30][D][sensor:126]: 'jk-bms total runtime': Sending state 964.26666 h with 0 decimals of accuracy
[12:17:30][D][text_sensor:067]: 'jk-bms total runtime formatted': Sending state '40d 4h'
[12:17:30][D][text_sensor:067]: 'jk-bms software version': Sending state 'H6.X__S6.1.3S__'
[12:17:30][D][sensor:126]: 'jk-bms actual battery capacity': Sending state 0.00000 Ah with 0 decimals of accuracy
[12:17:30][D][text_sensor:067]: 'jk-bms manufacturer': Sending state 'BT3072020120000200521001'
[12:17:30][D][uart_debug:114]: >>> 4E:57:00:13:00:00:00:00:06:03:00:00:00:00:00:00:68:00:00:01:29
[12:17:32]NWh)[I][jk_bms:062]: Status frame received
[12:17:32][D][sensor:126]: 'jk-bms cell voltage 1': Sending state 3.82100 V with 3 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms cell voltage 2': Sending state 3.83400 V with 3 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms cell voltage 3': Sending state 3.83100 V with 3 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms cell voltage 4': Sending state 3.82000 V with 3 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms cell voltage 5': Sending state 3.83200 V with 3 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms cell voltage 6': Sending state 3.83400 V with 3 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms cell voltage 7': Sending state 3.82500 V with 3 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms cell voltage 8': Sending state 3.83200 V with 3 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms cell voltage 9': Sending state 3.81100 V with 3 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms cell voltage 10': Sending state 3.83400 V with 3 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms cell voltage 11': Sending state 3.82500 V with 3 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms cell voltage 12': Sending state 3.83500 V with 3 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms cell voltage 13': Sending state 3.83500 V with 3 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms cell voltage 14': Sending state 3.82600 V with 3 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms min cell voltage': Sending state 3.81100 V with 3 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms max cell voltage': Sending state 3.83500 V with 3 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms max voltage cell': Sending state 12.00000  with 0 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms min voltage cell': Sending state 9.00000  with 0 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms delta cell voltage': Sending state 0.02400 V with 3 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms average cell voltage': Sending state 3.82821 V with 3 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms power tube temperature': Sending state 29.00000 °C with 0 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms temperature sensor 1': Sending state 30.00000 °C with 0 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms temperature sensor 2': Sending state 28.00000 °C with 0 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms total voltage': Sending state 53.59000 V with 2 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms current': Sending state 2.08000 A with 2 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms power': Sending state 111.46719 W with 2 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms charging power': Sending state 111.46719 W with 2 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms discharging power': Sending state 0.00000 W with 2 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms capacity remaining': Sending state 15.00000 % with 0 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms temperature sensors': Sending state 2.00000  with 0 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms charging cycles': Sending state 4.00000  with 0 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms total charging cycle capacity': Sending state 0.00000 Ah with 0 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms battery strings': Sending state 14.00000  with 0 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms errors bitmask': Sending state 0.00000  with 0 decimals of accuracy
[12:17:32][D][text_sensor:067]: 'jk-bms errors': Sending state ''
[12:17:32][D][sensor:126]: 'jk-bms operation mode bitmask': Sending state 7.00000  with 0 decimals of accuracy
[12:17:32][D][text_sensor:067]: 'jk-bms operation mode': Sending state 'Charging enabled;Discharging enabled;Balancer enabled'
[12:17:32][D][sensor:126]: 'jk-bms total voltage overvoltage protection': Sending state 56.70000 V with 2 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms total voltage undervoltage protection': Sending state 42.70000 V with 2 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms cell voltage overvoltage protection': Sending state 4.05000 V with 3 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms cell voltage overvoltage recovery': Sending state 4.00000 V with 3 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms cell voltage overvoltage delay': Sending state 5.00000 s with 0 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms cell voltage undervoltage protection': Sending state 3.05000 V with 3 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms cell voltage undervoltage recovery': Sending state 3.10000 V with 3 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms cell voltage undervoltage delay': Sending state 5.00000 s with 0 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms cell pressure difference protection': Sending state 0.30000 V with 3 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms discharging overcurrent protection': Sending state 7.00000 A with 0 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms discharging overcurrent delay': Sending state 3.00000 s with 0 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms charging overcurrent protection': Sending state 5.00000 A with 0 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms charging overcurrent delay': Sending state 5.00000 s with 0 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms balance starting voltage': Sending state 3.30000 V with 3 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms balance opening pressure difference': Sending state 0.00800 V with 3 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms power tube temperature protection': Sending state 90.00000 °C with 0 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms power tube temperature recovery': Sending state 70.00000 °C with 0 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms temperature sensor temperature protection': Sending state 100.00000 °C with 0 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms temperature sensor temperature recovery': Sending state 100.00000 °C with 0 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms temperature sensor temperature difference protection': Sending state 20.00000 °C with 0 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms charging high temperature protection': Sending state 70.00000 °C with 0 decimals of accuracy
[12:17:32][D][sensor:126]: 'jk-bms discharging high temperature protection': Sending state 70.00000 °C with 0 decimals of accuracy
[12:17:33][D][sensor:126]: 'jk-bms charging low temperature protection': Sending state -20.00000 °C with 0 decimals of accuracy
[12:17:33][D][sensor:126]: 'jk-bms charging low temperature recovery': Sending state -10.00000 °C with 0 decimals of accuracy
[12:17:33][D][sensor:126]: 'jk-bms discharging low temperature protection': Sending state -20.00000 °C with 0 decimals of accuracy
[12:17:33][D][sensor:126]: 'jk-bms discharging low temperature recovery': Sending state -10.00000 °C with 0 decimals of accuracy
[12:17:33][D][sensor:126]: 'jk-bms total battery capacity setting': Sending state 14.00000 Ah with 0 decimals of accuracy
[12:17:33][D][sensor:126]: 'jk-bms capacity remaining derived': Sending state 2.10000 Ah with 0 decimals of accuracy
[12:17:33][D][sensor:126]: 'jk-bms current calibration': Sending state 1.04100 A with 3 decimals of accuracy
[12:17:33][D][sensor:126]: 'jk-bms device address': Sending state 1.00000  with 0 decimals of accuracy
[12:17:33][D][text_sensor:067]: 'jk-bms battery type': Sending state 'Ternary Lithium'
[12:17:33][D][sensor:126]: 'jk-bms sleep wait time': Sending state 10.00000 s with 0 decimals of accuracy
[12:17:33][D][sensor:126]: 'jk-bms alarm low volume': Sending state 20.00000 % with 0 decimals of accuracy
[12:17:33][D][text_sensor:067]: 'jk-bms password': Sending state '123456'
[12:17:33][D][text_sensor:067]: 'jk-bms device type': Sending state 'Input Us'
[12:17:33][D][sensor:126]: 'jk-bms total runtime': Sending state 964.26666 h with 0 decimals of accuracy
[12:17:33][D][text_sensor:067]: 'jk-bms total runtime formatted': Sending state '40d 4h'
[12:17:33][D][text_sensor:067]: 'jk-bms software version': Sending state 'H6.X__S6.1.3S__'
[12:17:33][D][sensor:126]: 'jk-bms actual battery capacity': Sending state 0.00000 Ah with 0 decimals of accuracy
[12:17:33][D][text_sensor:067]: 'jk-bms manufacturer': Sending state 'BT3072020120000200521001'
[12:17:33][D][uart_debug:114]: >>> 4E:57:00:13:00:00:00:00:06:03:00:00:00:00:00:00:68:00:00:01:29
[12:17:35][D][wifi:388]: Found networks:
[12:17:35][I][wifi:431]: - 'IoT' (50:EB:F6:17:BE:D8) ▂▄▆█
[12:17:35][D][wifi:433]:     Channel: 6
[12:17:35][D][wifi:434]:     RSSI: -50 dB
[12:17:35][D][wifi:436]: - 'Mod Guest' (02:31:92:B1:29:AB) ▂▄▆█
[12:17:35][D][wifi:436]: - 'OpenWrt' (00:31:92:B1:29:AB) ▂▄▆█
[12:17:35][D][wifi:436]: - 'Mod' (9C:74:1A:7F:34:60) ▂▄▆█
[12:17:35][D][wifi:436]: - 'Thailand Wi-Fi by MDES' (04:B0:E7:4E:07:E0) ▂▄▆█
[12:17:35][D][wifi:436]: - 'Ratda_2.4G' (5C:3A:3D:96:43:0B) ▂▄▆█
[12:17:35][I][wifi:248]: WiFi Connecting to 'IoT'...
[12:17:37][I][wifi:505]: WiFi Connected!
[12:17:37][C][wifi:353]:   Local MAC: C8:C9:A3:5A:D1:F6
[12:17:37][C][wifi:354]:   SSID: 'IoT'
[12:17:37][C][wifi:355]:   IP Address: <IP_ADDRESS>
[12:17:37][C][wifi:356]:   BSSID: 50:EB:F6:17:BE:D8
[12:17:37][C][wifi:358]:   Hostname: 'jk-bms'
[12:17:37][C][wifi:360]:   Signal strength: -55 dB ▂▄▆█
[12:17:37][C][wifi:364]:   Channel: 6
[12:17:37][C][wifi:365]:   Subnet: <IP_ADDRESS>
[12:17:37][C][wifi:366]:   Gateway: <IP_ADDRESS>
[12:17:37][C][wifi:367]:   DNS1: <IP_ADDRESS>
[12:17:37][C][wifi:368]:   DNS2: <IP_ADDRESS>
[12:17:37][C][ota:085]: Over-The-Air Updates:
[12:17:37][C][ota:086]:   Address: jk-bms.local:8266
[12:17:37][W][ota:094]: Last Boot was an unhandled reset, will proceed to safe mode in 8 restarts
[12:17:37][C][mqtt:029]: Setting u
[12:17:37]--------------- CUT HERE FOR EXCEPTION DECODER ---------------
[12:17:37]
[12:17:37]Exception (29):
WARNING Exception type: Access to invalid address: STORE (wild pointer?)
[12:17:37]epc1=0x4000df64 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000 depc=0x00000000
[12:17:37]
[12:17:37]>>>stack>>>
WARNING Found stack trace!

If I try to flash the esp8266-example.yaml without changes I receive an out of memory exception. To solve this issue I've removed some sensors from the configuration. The diff looks like this:
diff --git a/esp8266-example-debug.yaml b/esp8266-example-debug.yaml
index a1f935f..6302926 100644
--- a/esp8266-example-debug.yaml
+++ b/esp8266-example-debug.yaml
@@ -1,7 +1,6 @@
 <<: !include esp8266-example.yaml

 logger:
-  baud_rate: 0
   level: DEBUG

 uart:
diff --git a/esp8266-example.yaml b/esp8266-example.yaml
index 45a9df6..257a1cc 100644
--- a/esp8266-example.yaml
+++ b/esp8266-example.yaml
@@ -2,8 +2,8 @@ substitutions:
   name: jk-bms
   device_description: "Monitor and control a JK-BMS via UART-TTL"
   external_components_source: github://syssi/esphome-jk-bms@main
-  tx_pin: GPIO1
-  rx_pin: GPIO3
+  tx_pin: GPIO4
+  rx_pin: GPIO5

 esphome:
   name: ${name}
@@ -25,7 +25,6 @@ wifi:

 ota:
 logger:
-  baud_rate: 0

 mqtt:
   broker: !secret mqtt_host
@@ -148,90 +147,6 @@ sensor:
       name: "${name} capacity remaining"
     capacity_remaining_derived:
       name: "${name} capacity remaining derived"
-    temperature_sensors:
-      name: "${name} temperature sensors"
-    charging_cycles:
-      name: "${name} charging cycles"
-    total_charging_cycle_capacity:
-      name: "${name} total charging cycle capacity"
-    battery_strings:
-      name: "${name} battery strings"
-    errors_bitmask:
-      name: "${name} errors bitmask"
-    operation_mode_bitmask:
-      name: "${name} operation mode bitmask"
-    total_voltage_overvoltage_protection:
-      name: "${name} total voltage overvoltage protection"
-    total_voltage_undervoltage_protection:
-      name: "${name} total voltage undervoltage protection"
-    cell_voltage_overvoltage_protection:
-      name: "${name} cell voltage overvoltage protection"
-    cell_voltage_overvoltage_recovery:
-      name: "${name} cell voltage overvoltage recovery"
-    cell_voltage_overvoltage_delay:
-      name: "${name} cell voltage overvoltage delay"
-    cell_voltage_undervoltage_protection:
-      name: "${name} cell voltage undervoltage protection"
-    cell_voltage_undervoltage_recovery:
-      name: "${name} cell voltage undervoltage recovery"
-    cell_voltage_undervoltage_delay:
-      name: "${name} cell voltage undervoltage delay"
-    cell_pressure_difference_protection:
-      name: "${name} cell pressure difference protection"
-    discharging_overcurrent_protection:
-      name: "${name} discharging overcurrent protection"
-    discharging_overcurrent_delay:
-      name: "${name} discharging overcurrent delay"
-    charging_overcurrent_protection:
-      name: "${name} charging overcurrent protection"
-    charging_overcurrent_delay:
-      name: "${name} charging overcurrent delay"
-    balance_starting_voltage:
-      name: "${name} balance starting voltage"
-    balance_opening_pressure_difference:
-      name: "${name} balance opening pressure difference"
-    power_tube_temperature_protection:
-      name: "${name} power tube temperature protection"
-    power_tube_temperature_recovery:
-      name: "${name} power tube temperature recovery"
-    temperature_sensor_temperature_protection:
-      name: "${name} temperature sensor temperature protection"
-    temperature_sensor_temperature_recovery:
-      name: "${name} temperature sensor temperature recovery"
-    temperature_sensor_temperature_difference_protection:
-      name: "${name} temperature sensor temperature difference protection"
-    charging_high_temperature_protection:
-      name: "${name} charging high temperature protection"
-    discharging_high_temperature_protection:
-      name: "${name} discharging high temperature protection"
-    charging_low_temperature_protection:
-      name: "${name} charging low temperature protection"
-    charging_low_temperature_recovery:
-      name: "${name} charging low temperature recovery"
-    discharging_low_temperature_protection:
-      name: "${name} discharging low temperature protection"
-    discharging_low_temperature_recovery:
-      name: "${name} discharging low temperature recovery"
-    total_battery_capacity_setting:
-      name: "${name} total battery capacity setting"
-    current_calibration:
-      name: "${name} current calibration"
-    device_address:
-      name: "${name} device address"
-    sleep_wait_time:
-      name: "${name} sleep wait time"
-    alarm_low_volume:
-      name: "${name} alarm low volume"
-    manufacturing_date:
-      name: "${name} manufacturing date"
-    total_runtime:
-      name: "${name} total runtime"
-#    start_current_calibration:
-#      name: "${name} start current calibration"
-    actual_battery_capacity:
-      name: "${name} actual battery capacity"
-#    protocol_version:
-#      name: "${name} protocol version"

 text_sensor:
   - platform: jk_bms

Could you try the same? In my case it's stable as soon the total number of sensors is reduced. You issue looks a bit different:
WARNING Exception type: Access to invalid address: STORE (wild pointer?)

Could you tell me the GPIOs you are using for UART? I assume it isn't GPIO1 and GPIO3 anymore because you are able to show the serial output of the logger.

Hi Syssi,
perfect now is working fine.
I use GPIO1 and GPIO3 with the name TX and RX on the PCB
git diff
diff --git a/esp8266-example-debug.yaml b/esp8266-example-debug.yaml
index a1f935f..6302926 100644
--- a/esp8266-example-debug.yaml
+++ b/esp8266-example-debug.yaml
@@ -1,7 +1,6 @@
 <<: !include esp8266-example.yaml

 logger:
-  baud_rate: 0
   level: DEBUG

 uart:
diff --git a/esp8266-example.yaml b/esp8266-example.yaml
index 45a9df6..540b101 100644
--- a/esp8266-example.yaml
+++ b/esp8266-example.yaml
@@ -10,7 +10,8 @@ esphome:
   comment: ${device_description}
   project:
     name: "syssi.esphome-jk-bms"
-    version: 1.2.0
+    version: latest
+ #   version: 1.2.0

 esp8266:
   board: d1_mini
@@ -25,12 +26,15 @@ wifi:

 ota:
 logger:
-  baud_rate: 0
+  baud_rate: 115200
+  level: DEBUG
+

 mqtt:
   broker: !secret mqtt_host
   username: !secret mqtt_username
   password: !secret mqtt_password
+  port: 1883
   id: mqtt_client

 uart:
@@ -148,90 +152,6 @@ sensor:
       name: "${name} capacity remaining"
     capacity_remaining_derived:
       name: "${name} capacity remaining derived"
-    temperature_sensors:
-      name: "${name} temperature sensors"
-    charging_cycles:
-      name: "${name} charging cycles"
-    total_charging_cycle_capacity:
-      name: "${name} total charging cycle capacity"
-    battery_strings:
-      name: "${name} battery strings"
-    errors_bitmask:
-      name: "${name} errors bitmask"
-    operation_mode_bitmask:
-      name: "${name} operation mode bitmask"
-    total_voltage_overvoltage_protection:
-      name: "${name} total voltage overvoltage protection"
-    total_voltage_undervoltage_protection:
-      name: "${name} total voltage undervoltage protection"
-    cell_voltage_overvoltage_protection:
-      name: "${name} cell voltage overvoltage protection"
-    cell_voltage_overvoltage_recovery:
-      name: "${name} cell voltage overvoltage recovery"
-    cell_voltage_overvoltage_delay:
-      name: "${name} cell voltage overvoltage delay"
-    cell_voltage_undervoltage_protection:
-      name: "${name} cell voltage undervoltage protection"
-    cell_voltage_undervoltage_recovery:
-      name: "${name} cell voltage undervoltage recovery"
-    cell_voltage_undervoltage_delay:
-      name: "${name} cell voltage undervoltage delay"
-    cell_pressure_difference_protection:
-      name: "${name} cell pressure difference protection"
-    discharging_overcurrent_protection:
-      name: "${name} discharging overcurrent protection"
-    discharging_overcurrent_delay:
-      name: "${name} discharging overcurrent delay"
-    charging_overcurrent_protection:
-      name: "${name} charging overcurrent protection"
-    charging_overcurrent_delay:
-      name: "${name} charging overcurrent delay"
-    balance_starting_voltage:
-      name: "${name} balance starting voltage"
-    balance_opening_pressure_difference:
-      name: "${name} balance opening pressure difference"
-    power_tube_temperature_protection:
-      name: "${name} power tube temperature protection"
-    power_tube_temperature_recovery:
-      name: "${name} power tube temperature recovery"
-    temperature_sensor_temperature_protection:
-      name: "${name} temperature sensor temperature protection"
-    temperature_sensor_temperature_recovery:
-      name: "${name} temperature sensor temperature recovery"
-    temperature_sensor_temperature_difference_protection:
-      name: "${name} temperature sensor temperature difference protection"
-    charging_high_temperature_protection:
-      name: "${name} charging high temperature protection"
-    discharging_high_temperature_protection:
-      name: "${name} discharging high temperature protection"
-    charging_low_temperature_protection:
-      name: "${name} charging low temperature protection"
-    charging_low_temperature_recovery:
-      name: "${name} charging low temperature recovery"
-    discharging_low_temperature_protection:
-      name: "${name} discharging low temperature protection"
-    discharging_low_temperature_recovery:
-      name: "${name} discharging low temperature recovery"
-    total_battery_capacity_setting:
-      name: "${name} total battery capacity setting"
-    current_calibration:
-      name: "${name} current calibration"
-    device_address:
-      name: "${name} device address"
-    sleep_wait_time:
-      name: "${name} sleep wait time"
-    alarm_low_volume:
-      name: "${name} alarm low volume"
-    manufacturing_date:
-      name: "${name} manufacturing date"
-    total_runtime:
-      name: "${name} total runtime"
-#    start_current_calibration:
-#      name: "${name} start current calibration"
-    actual_battery_capacity:
-      name: "${name} actual battery capacity"
-#    protocol_version:
-#      name: "${name} protocol version"

 text_sensor:
   - platform: jk_bms
diff --git a/test-esp8266.sh b/test-esp8266.sh
index 332ef1a..208b227 100755
--- a/test-esp8266.sh
+++ b/test-esp8266.sh
@@ -1,3 +1,17 @@
 #!/bin/bash

-esphome -s external_components_source components ${1:-run} ${2:-esp8266-example-faker.yaml}
+# Disable brltty
+sudo mv /usr/lib/udev/rules.d/85-brltty.rules /usr/lib/udev/rules.d/85-brltty.rules_disable
+sudo udevadm control --reload-rules
+sudo systemctl disable brltty.service
+sudo systemctl stop brltty.service
+
+#esphome -s external_components_source components ${1:-run} ${2:-esp8266-example-faker.yaml}
+esphome -s external_components_source components ${1:-run} ${2:-esp8266-example.yaml}
+
+
+# Enable brltty
+sudo mv /usr/lib/udev/rules.d/85-brltty.rules_disable /usr/lib/udev/rules.d/85-brltty.rules
+sudo udevadm control --reload-rules
+sudo systemctl enable brltty.service
+sudo systemctl start brltty.service

I had some problems because of BRLTTY, I need for virtual box. That always sparks in between.
That's why I adjusted the Shell Script. Maybe help someone else. who has the problem.
dmes with BRLTTY
[264343.602230] usb 3-2: USB disconnect, device number 2
[264631.302236] usb 3-2: new full-speed USB device number 5 using xhci_hcd
[264631.467708] usb 3-2: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.54
[264631.467717] usb 3-2: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[264631.467720] usb 3-2: Product: USB2.0-Ser!
[264631.522498] usbcore: registered new interface driver usbserial_generic
[264631.522522] usbserial: USB Serial support registered for generic
[264631.524438] usbcore: registered new interface driver ch341
[264631.524454] usbserial: USB Serial support registered for ch341-uart
[264631.524482] ch341 3-2:1.0: ch341-uart converter detected
[264631.535806] ch341-uart ttyUSB0: break control not supported, using simulated break
[264631.535941] usb 3-2: ch341-uart converter now attached to ttyUSB0
[264632.091643] input: BRLTTY 6.4 Linux Screen Driver Keyboard as /devices/virtual/input/input42
[264632.097726] usb 3-2: usbfs: interface 0 claimed by ch341 while 'brltty' sets config #1
[264632.100877] ch341-uart ttyUSB0: ch341-uart converter now disconnected from ttyUSB0
[264632.100899] ch341 3-2:1.0: device disconnected

and with Disabled BRTTY
[264860.460662] usb 3-2: USB disconnect, device number 8
[264864.350242] usb 3-2: new full-speed USB device number 9 using xhci_hcd
[264864.511546] usb 3-2: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.54
[264864.511553] usb 3-2: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[264864.511557] usb 3-2: Product: USB2.0-Ser!
[264864.521594] ch341 3-2:1.0: ch341-uart converter detected
[264864.534622] ch341-uart ttyUSB0: break control not supported, using simulated break
[264864.534738] usb 3-2: ch341-uart converter now attached to ttyUSB0

and the MQTT Data
jk-bms/sensor/jk-bms_cell_voltage_1/state 3.528
jk-bms/sensor/jk-bms_cell_voltage_2/state 3.527
jk-bms/sensor/jk-bms_cell_voltage_3/state 3.535
jk-bms/sensor/jk-bms_cell_voltage_4/state 3.541
jk-bms/sensor/jk-bms_cell_voltage_5/state 3.544
jk-bms/sensor/jk-bms_cell_voltage_6/state 3.555
jk-bms/sensor/jk-bms_cell_voltage_7/state 3.563
jk-bms/sensor/jk-bms_cell_voltage_8/state 3.536
jk-bms/sensor/jk-bms_cell_voltage_9/state 3.556
jk-bms/sensor/jk-bms_cell_voltage_10/state 3.563
jk-bms/sensor/jk-bms_cell_voltage_11/state 3.535
jk-bms/sensor/jk-bms_cell_voltage_12/state 3.560
jk-bms/sensor/jk-bms_cell_voltage_13/state 3.562
jk-bms/sensor/jk-bms_cell_voltage_14/state 3.560
jk-bms/sensor/jk-bms_cell_voltage_15/state 3.562
jk-bms/sensor/jk-bms_cell_voltage_16/state 3.556
jk-bms/sensor/jk-bms_min_cell_voltage/state 3.527
jk-bms/sensor/jk-bms_max_cell_voltage/state 3.563
jk-bms/sensor/jk-bms_max_voltage_cell/state 7
jk-bms/sensor/jk-bms_min_voltage_cell/state 2
jk-bms/sensor/jk-bms_delta_cell_voltage/state 0.036
jk-bms/sensor/jk-bms_average_cell_voltage/state 3.549
jk-bms/sensor/jk-bms_power_tube_temperature/state 35
jk-bms/sensor/jk-bms_temperature_sensor_1/state 31
jk-bms/sensor/jk-bms_temperature_sensor_2/state 32
jk-bms/sensor/jk-bms_total_voltage/state 56.78
jk-bms/sensor/jk-bms_current/state -0.65
jk-bms/sensor/jk-bms_power/state -36.91
jk-bms/sensor/jk-bms_charging_power/state 0.00
jk-bms/sensor/jk-bms_discharging_power/state 36.91
jk-bms/sensor/jk-bms_capacity_remaining/state 95
jk-bms/sensor/jk-bms_errors/state (null)
jk-bms/sensor/jk-bms_operation_mode/state Charging enabled;Discharging enabled;Balancer enabled
jk-bms/sensor/jk-bms_capacity_remaining_derived/state 266
jk-bms/sensor/jk-bms_battery_type/state Ternary Lithium
jk-bms/sensor/jk-bms_password/state **********
jk-bms/sensor/jk-bms_device_type/state Battery
jk-bms/sensor/jk-bms_total_runtime_formatted/state 54d 5h
jk-bms/sensor/jk-bms_software_version/state 10.XW_S10.07___
jk-bms/sensor/jk-bms_manufacturer/state Battery #2

This part of the diff doesn't look good to me:
 ota:
 logger:
-  baud_rate: 0
+  baud_rate: 115200
+  level: DEBUG
+

If you set the baud_rate of the logger component the logger starts to write log data to GPIO1/GPIO3. In other words: You are writing log data into your BMS if the uart component is also attached to GPIO1/GPIO3. Please set the baud_rate to 0 if the BMS is attached to GPIO1/3.

Hi Syssi,
yes i removed this.
this is my working config
substitutions:
  name: jk-bms2
  device_description: "Monitor and control a JK-BMS via UART-TTL"
  external_components_source: github://syssi/esphome-jk-bms@main
  tx_pin: GPIO1
  rx_pin: GPIO3

esphome:
  name: ${name}
  comment: ${device_description}
  project:
    name: "syssi.esphome-jk-bms"
#    version: latest
    version: 1.2.0

esp8266:
  board: d1_mini

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: <IP_ADDRESS>
#    # Set this to the IP address of the router. Often ends with .1
#    gateway: <IP_ADDRESS>
#    # The subnet of the network. <IP_ADDRESS> works for most home networks.
#    subnet: <IP_ADDRESS>

ota:
logger:
  baud_rate: 0
  level: INFO

mqtt:
  broker: !secret mqtt_host
  username: !secret mqtt_username
  password: !secret mqtt_password
  port: 1883
  id: mqtt_client

uart:
  id: uart0
  baud_rate: 115200
  rx_buffer_size: 384
  tx_pin: ${tx_pin}
  rx_pin: ${rx_pin}

jk_modbus:
  id: modbus0
  uart_id: uart0
  rx_timeout: 50ms

jk_bms:
  id: bms0
  jk_modbus_id: modbus0

binary_sensor:
  - platform: jk_bms
    balancing:
      name: "${name} balancing"
    balancing_switch:
      name: "${name} balancing switch"
    charging:
      name: "${name} charging"
    charging_switch:
      name: "${name} charging switch"
    discharging:
      name: "${name} discharging"
    discharging_switch:
      name: "${name} discharging switch"
    dedicated_charger_switch:
      name: "${name} dedicated charger switch"

sensor:
  - platform: jk_bms
    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"
    power_tube_temperature:
      name: "${name} power tube temperature"
    temperature_sensor_1:
      name: "${name} temperature sensor 1"
    temperature_sensor_2:
      name: "${name} temperature sensor 2"
    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"
    capacity_remaining:
      name: "${name} capacity remaining"
    capacity_remaining_derived:
      name: "${name} capacity remaining derived"
    temperature_sensors:
      name: "${name} temperature sensors"
    charging_cycles:
      name: "${name} charging cycles"
    total_charging_cycle_capacity:
      name: "${name} total charging cycle capacity"
    battery_strings:
      name: "${name} battery strings"
    errors_bitmask:
      name: "${name} errors bitmask"
    operation_mode_bitmask:
      name: "${name} operation mode bitmask"
#    total_voltage_overvoltage_protection:
#      name: "${name} total voltage overvoltage protection"
#    total_voltage_undervoltage_protection:
#      name: "${name} total voltage undervoltage protection"
#    cell_voltage_overvoltage_protection:
#      name: "${name} cell voltage overvoltage protection"
#    cell_voltage_overvoltage_recovery:
#      name: "${name} cell voltage overvoltage recovery"
#    cell_voltage_overvoltage_delay:
#      name: "${name} cell voltage overvoltage delay"
#    cell_voltage_undervoltage_protection:
#      name: "${name} cell voltage undervoltage protection"
#    cell_voltage_undervoltage_recovery:
#      name: "${name} cell voltage undervoltage recovery"
#    cell_voltage_undervoltage_delay:
#      name: "${name} cell voltage undervoltage delay"
#    cell_pressure_difference_protection:
#      name: "${name} cell pressure difference protection"
#    discharging_overcurrent_protection:
#      name: "${name} discharging overcurrent protection"
#    discharging_overcurrent_delay:
#      name: "${name} discharging overcurrent delay"
#    charging_overcurrent_protection:
#      name: "${name} charging overcurrent protection"
#    charging_overcurrent_delay:
#      name: "${name} charging overcurrent delay"
#    balance_starting_voltage:
#      name: "${name} balance starting voltage"
#    balance_opening_pressure_difference:
#      name: "${name} balance opening pressure difference"
#    power_tube_temperature_protection:
#      name: "${name} power tube temperature protection"
#    power_tube_temperature_recovery:
#      name: "${name} power tube temperature recovery"
#    temperature_sensor_temperature_protection:
#      name: "${name} temperature sensor temperature protection"
#    temperature_sensor_temperature_recovery:
#      name: "${name} temperature sensor temperature recovery"
#    temperature_sensor_temperature_difference_protection:
#      name: "${name} temperature sensor temperature difference protection"
#    charging_high_temperature_protection:
#      name: "${name} charging high temperature protection"
#    discharging_high_temperature_protection:
#      name: "${name} discharging high temperature protection"
#    charging_low_temperature_protection:
#      name: "${name} charging low temperature protection"
#    charging_low_temperature_recovery:
#      name: "${name} charging low temperature recovery"
#    discharging_low_temperature_protection:
#      name: "${name} discharging low temperature protection"
#    discharging_low_temperature_recovery:
#      name: "${name} discharging low temperature recovery"
    total_battery_capacity_setting:
      name: "${name} total battery capacity setting"
    current_calibration:
      name: "${name} current calibration"
#    device_address:
#      name: "${name} device address"
#    sleep_wait_time:
#      name: "${name} sleep wait time"
#    alarm_low_volume:
#      name: "${name} alarm low volume"
#    manufacturing_date:
#      name: "${name} manufacturing date"
    total_runtime:
      name: "${name} total runtime"
#    start_current_calibration:
#      name: "${name} start current calibration"
    actual_battery_capacity:
      name: "${name} actual battery capacity"
#    protocol_version:
#      name: "${name} protocol version"

text_sensor:
  - platform: jk_bms
    errors:
      name: "${name} errors"
    operation_mode:
      name: "${name} operation mode"
    battery_type:
      name: "${name} battery type"
#    password:
#      name: "${name} password"
    device_type:
      name: "${name} device type"
#    software_version:
#      name: "${name} software version"
    manufacturer:
      name: "${name} manufacturer"
    total_runtime_formatted:
      name: "${name} total runtime formatted"

It worked great too.
But I made a huge mistake.
I did the ESP with 5V and trusted that the Mini Voltage Regulator does its job.
Well after about 1 hour he didn't do it anymore and grilled the ESP. And unfortunately also the TTL output of the JK BMS.
Please take it in your documentary that people have to be careful. Use only 3.3V and best install a digital insulation between the ESP and the BMS.
The BMS has installed a digital insulation, but to change it you have to open the BMS.
Now I'm measuring between the TX and TX pins in the off condition 4 mega ohm. Before that, it was around 60 kilos.
Here I grilled the digital insulation.
Here is the board I built. While the ESP was hung on the BMS via USB power.

First of all, a DC-DC Step Down Converter
DC-DC Buck Step Down 09V-1220V (80max) TO 5V 3A

Then a small DC-DC step down for 3.3 volts

A digital insulation is definitely coming to the next version.
But now I have to wait 3 months before I get back to my battery.  Are you able to replace the optical isolator on your BMS? I could point you to the location and provide some measurements if needed. Could you explain your schematics of the power supply in some more words? I would like to understand: What's the VIN of the big DC/DC converter? How did you power the big converter?

Could you measure the resistance between B- and GND of the UART-TTL port? It should be 0 Ohm.

Hi,
i measure the resistance Between RX and GND and TX and GND.
Both have >4Mega Ohm
I did that with both BMS. BMS switched off. Separated from the battery and then measured.
Now I switched to the ES32 and read the data Bluetooth.

Now I only have to configure Telegraf to write the data from the MQTT to InfluxDB.

i uses the esp32-ble-exampe.yaml to create my config with the Sensors what i need.
I think that was even more than 6 mega ohm between RX and GND.
I can't reach the BMS now because I have already closed the rack.
I'll look at the TTL problem when I'm back home.

Thank you. I make a design copy from the off-grid garage.
the display ports are working all the time.
I first tried it with the JK TTL to rs485 adapter.  but apparently I have those with 9200 baud.  the functions don't.  then I bought some TTL adapters and then only got data from the lower  BMS.  I may have already grilled the upper BMS while testing.
but after I didn't get much further with the Python script from .  I decided to do something similar to what I built for my jdb BMS.  an esp12 as Modbus to TTL over network.  but then I came across your project.
I think it's just the optocoupler that's broken.  you can replace it, maybe even a two resistors.  but I need time for that.  which I don't have right now.  and smb soldering is no fun without the right tools either.

but I still have a question.  can you make the mttq output json compliant.  I can't get Telegraf to write the data to the influxdb.  somehow he doesn't want to parse that properly with the topic

I think so too. You have fried one of these components:

I use the official MQTT component from ESPHome. IMO the output isn't JSON because each measurement is available on a dedicated topic as int, float or text. You have to tell telegraf the correct data_format per topic.

This is what I'm talking about:
[[inputs.mqtt_consumer]]
  name_override = "my_integer"
  topics = ["/XXX"]
  data_format = "value"
  data_type = "integer"

[[inputs.mqtt_consumer]]
  name_override = "my_string"
  topics = ["/SSS"]
  data_format = "value"
  data_type = "string"

I totally forgot that I use different databases for different inputs.
Therefore, the data all went into the false database. :(
[[inputs.mqtt_consumer]]
  # Override mqtt_consumer to
  name_override = "jk-bms1"

  servers = ["tcp://<IP_ADDRESS>:1883"]
  qos = 2
  topics = ["jk-bms1-ble/sensor/#"]

  data_format = "value"
  data_type = "float"

  persistent_session = false

[[outputs.influxdb]]
 # Only accept measurements with
  namepass = ["jk-bms1"]

  urls = ["http://<IP_ADDRESS>:8086"]
  database = "jk-bms1"
  skip_database_creation = true
  username = "XYZ"
  password = "123"

[[inputs.mqtt_consumer]]
  # Override mqtt_consumer to
  name_override = "jk-bms2"

  servers = ["tcp://<IP_ADDRESS>:1883"]
  qos = 2
  topics = ["jk-bms2-ble/sensor/#"]

  data_format = "value"
  data_type = "float"

  persistent_session = false

[[outputs.influxdb]]
  # Only accept measurements with
  namepass = ["jk-bms2"]

  urls = ["http://<IP_ADDRESS>:8086"]
  database = "jk-bms2"
  skip_database_creation = true
  username = "XYZ"
  password = "123"

If I remember correctly you can find warnings/errors at the telegraf log if telegraf is unable to interpret a received value/measurement.

Do you have an idea how I can overwrite the topic in Telegraf.
I have this key at Show Series in the InfluxDB
jk-bms1,host=powermeterpi4.th.secretisland.de,topic=jk-bms1-ble/sensor/average_cell_voltage/state
jk-bms1,host=powermeterpi4.th.secretisland.de,topic=jk-bms1-ble/sensor/balancing_current/state
jk-bms1,host=powermeterpi4.th.secretisland.de,topic=jk-bms1-ble/sensor/capacity_remaining/state
jk-bms1,host=powermeterpi4.th.secretisland.de,topic=jk-bms1-ble/sensor/cell_resistance_1/state
jk-bms1,host=powermeterpi4.th.secretisland.de,topic=jk-bms1-ble/sensor/cell_resistance_10/state

i want
jk-bms1,host=powermeterpi4.th.secretisland.de,topic=average_cell_voltage
jk-bms1,host=powermeterpi4.th.secretisland.de,topic=balancing_current
jk-bms1,host=powermeterpi4.th.secretisland.de,topic=capacity_remaining
jk-bms1,host=powermeterpi4.th.secretisland.de,topic=cell_resistance_1
jk-bms1,host=powermeterpi4.th.secretisland.de,topic=cell_resistance_10

I'm just saying that as a sensor, and the sensor day is the name of the sensor
[[inputs.mqtt_consumer]]
  # Override mqtt_consumer to
  name_override = "jk-bms1"

  servers = ["tcp://<IP_ADDRESS>:1883"]
  persistent_session = false
  qos = 2
  topics = ["jk-bms1-ble/sensor/#"]

  data_format = "value"
  data_type = "float"

[[inputs.mqtt_consumer.topic_parsing]]
  data_format = "value"
  data_type = "float"

  topic = "jk-bms1-ble/sensor/+/state"
  tags = "_/_/sensor/_"
  measurement = "_/_/measurement/_"
  fields = "_/_/_/state"

[[outputs.influxdb]]
  # Only accept measurements with
  namepass = ["jk-bms1"]

  urls = ["http://<IP_ADDRESS>:8086"]
  database = "jk-bms1"
  skip_database_creation = true
  username = ""
  password = ""

InfluxDB
jk-bms1,host=powermeterpi4.th.secretisland.de,sensor=average_cell_voltage,topic=jk-bms1-ble/sensor/average_cell_voltage/state
jk-bms1,host=powermeterpi4.th.secretisland.de,sensor=balancing_current,topic=jk-bms1-ble/sensor/balancing_current/state
jk-bms1,host=powermeterpi4.th.secretisland.de,sensor=capacity_remaining,topic=jk-bms1-ble/sensor/capacity_remaining/state
jk-bms1,host=powermeterpi4.th.secretisland.de,sensor=cell_resistance_1,topic=jk-bms1-ble/sensor/cell_resistance_1/state
jk-bms1,host=powermeterpi4.th.secretisland.de,sensor=cell_resistance_10,topic=jk-bms1-ble/sensor/cell_resistance_10/state
jk-bms1,host=powermeterpi4.th.secretisland.de,sensor=cell_resistance_11,topic=jk-bms1-ble/sensor/cell_resistance_11/state

And then it's nice in the Grafana

I assume you are looking for something like this:
[[processors.rename]]
  namepass = "cpu"
  [[processors.rename.field]]
    from = "usage_idle"
    to = "idle"

But I must admit my telegraf knowledge is pretty limited.

I assume you are looking for something like this:
[[processors.rename]]
  namepass = "cpu"
  [[processors.rename.field]]
    from = "usage_idle"
    to = "idle"

But I must admit my telegraf knowledge is pretty limited.

i try this. but not working i got a solution

It looks like your solution is better / more generic.


feat: support cast between integer and bool

Signed-off-by: xyz<EMAIL_ADDRESS>What's changed and what's your intention?
This pr add support for casting between integer and bool.
Cast from integer to bool: 0 -> false , other -> true.
Cast from bool to integer: false -> 0, true -> 1.
PLEASE DO NOT LEAVE THIS EMPTY !!!
Please explain IN DETAIL what the changes are in this PR and why they are needed:

Summarize your change (mandatory)
How does this PR work? Need a brief introduction for the changed logic (optional)
Describe clearly one logical change and avoid lazy messages (optional)
Describe any limitations of the current code (optional)

Checklist

[ ] I have written necessary docs and comments
[x] I have added necessary unit tests and integration tests

Refer to a related PR or issue link (optional)
#112

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


[VL] Fix StringToMap test failure

What changes were proposed in this pull request?
Gluten + Velox backend only supports the default SQLConf.MapKeyDedupPolicy.EXCEPTION policy. This PR adds the check to make it fall back on unsupported config.
How was this patch tested?
Existing Spark UT covers it.

===== Performance report for TPCH SF2000 with Velox backend, for reference only ====

query
log/native_3995_time.csv
log/native_master_12_10_2023_e9ea4e3e4_time.csv
difference
percentage

q1
33.56
34.68
1.121
103.34%

q2
25.87
27.19
1.326
105.12%

q3
37.93
37.58
-0.348
99.08%

q4
39.54
37.98
-1.561
96.05%

q5
70.89
70.50
-0.393
99.45%

q6
7.10
6.93
-0.176
97.52%

q7
85.26
84.23
-1.032
98.79%

q8
86.95
85.45
-1.491
98.28%

q9
127.36
126.22
-1.142
99.10%

q10
43.57
43.28
-0.295
99.32%

q11
20.65
19.94
-0.713
96.55%

q12
28.43
27.48
-0.957
96.63%

q13
47.03
47.58
0.547
101.16%

q14
15.26
16.51
1.245
108.15%

q15
28.52
27.43
-1.088
96.19%

q16
16.01
15.68
-0.328
97.95%

q17
103.72
104.55
0.830
100.80%

q18
150.13
149.27
-0.861
99.43%

q19
12.89
13.60
0.706
105.47%

q20
27.48
27.18
-0.297
98.92%

q21
225.13
225.87
0.738
100.33%

q22
13.96
13.10
-0.855
93.87%

total
1247.24
1242.22
-5.026
99.60%


ci: move to github

Remove travis environment
Add github action based CI
Mount .git to fix failing server specs
Fix up Dockerfile to improve layer cacheability

@kimburgess in lieu of separating out the test runner from this repository, would you recommend adding a cache layer to the action (I'd like to compile the binaries in release mode)?
I would also like to run the test runner specs in parallel with the driver report.
Any pointers are appreciated

@caspiano yep, using actions/cache is definitely worthwhile. For it to play nicely, you'll need to use buildkit. You can do this via the docker/build-push-action, or if you want to keep things in compose, by using compose under it's new home in the docker cli (rather than docker-compose) which will let you use the DOCKER_BUILDKIT env var (https://docs.docker.com/compose/reference/build/#native-build-using-the-docker-cli).
Example with the action can be seen in https://github.com/PlaceOS/PlaceOS/blob/967f20c161b3179dc5489be099a49cacad17e9d1/.github/workflows/build.yml#L98-L99


Use %Y with month-based calendar

%G leads to nonsensical dates when used with %M. Presumably just a slip.

Thanks for catching this!


System freeses on auxilury button press

Probobly an issue with the config files.

Appears to no longer happen. Closing for now; reopen if this shows up again.


[WIP][ENH] A reader for Brainstorm events

This PR adds the necessary code to be able to read Brainstorm markers (events + annotations) from a events_*.mat file.
The proposed user code would be :
import numpy as np
import mne
from scipy import io

raw_fname = '/Data_samples_In_MNE/sample_audvis_raw.fif'

raw = mne.io.read_raw_fif(raw_fname)

annot_fname = '/Your/Path/events_sample_audvis_raw_ASD.mat'

raw.annotations = mne.annotations.read_brainstorm_annotations(annot_fname,raw.info['meas_date'])

@annesodub also PEP8 is failing. Maybe you can add a pep8 checker to your editor. (maybe this helps)

@annesodub I am taking over this PR.
In the event mat file you shared you wrote flux_jump_MEG1711
why not having put BAD in the description? same for blink and HEOG.
thanks

@annesodub please rebase your branch on top of master. To do this:
git checkout master
git pull origin master
git checkout read_brainstorm_annotations
git rebase master

then you can add a test like this one:
@testing.requires_testing_data
def test_read_brainstorm_annotations():
    """Test reading for Brainstorm events file"""
    fname = op.join(data_dir, 'events_sample_audvis_raw_bst.mat')
    annot = read_brainstorm_annotations(fname)
    assert len(annot) == 238
    assert annot.onset.min() > 40  # takes into account first_samp
    assert np.unique(annot.description).size == 5

this should be put in the file : test_annotations.py
let us know if you need help.

thanks @annesodub !


Catalog UI: Description section that uses readme is not updated in the UI when switching between templates using dropdown

v0.51.0
Steps to Reproduce:

Go to Catalog, select Apache Zookeeper.
Use dropdown to select another template.

Result: The description section remains the same and doesn't get updated.
Expected Result: The description section to be updated.
Note: The only difference is that Apache Zookeeper has an explicit README.md file. If you pick another service that doesn't have a README.md in the catalog, the description gets updated.

:+1: See it today with my personal Catalog

Yes, the readme content isn't cleared if the new template doesn't have one.

Verified with v0.56.0-rc1


[no ci] Overlay: correct wireless interface files

Commit #998 introduces some problems:

wlan0 should not be enabled by default, it is not needed for ethernet only devices and requires a driver in almost all cases (that is what the wlandev interface is intended for).

post-up is the preferred choice for wpa_supplicant, so we can be sure the interface is initialized.

-t 15 increases the discover counter to 15, removing it sets it to the default value of 3.

Continuation of a discussion that was previously started here
https://github.com/OpenIPC/firmware/pull/998

i don't have a ready solution yet, but the way wifi acts now is very annoying. so i am all for changes as long as they make the interface to appear sooner and connect faster :)

Thank you.
I think it will take us some time to realize the changes and perhaps some colleagues will want to comment on this issue

In commit #998, I made WiFi connections work better and faster. Here were the main changes:
wpa_supplicant Timing: Most Linux systems start wpa_supplicant before trying to connect. Starting it after, like in openipc, slows things down. In #998, I fixed this.  I am not aware of another linux distribution or embedded linux system that places it in post-up.  wpa_supplicant can absolutely be started before the wireless interface is fully "up" or activated:
Doing so can indeed speed up the authentication process, especially in environments where faster network connection establishment is desired.  By starting wpa_supplicant early, it can begin its tasks (like scanning for networks, setting up credentials, etc.) while other system or network-related processes are also initializing.
Once the interface is up, if wpa_supplicant has already been running, it's in a ready state to authenticate immediately, rather than having to start up and then authenticate.
In many systems, especially embedded systems or IoT devices as we handle, reducing the time it takes to establish a network connection after boot or wake can be critical. Starting wpa_supplicant early contributes to minimizing this delay.
Timeout Change: We set the timeout to 15 seconds.  It gives udhcpc enough time to work properly, making sure devices connect without issues.  The dhcp lease is aquired before udhcpc moves into the background, saving time.
  With #998, it takes about 5 seconds. I checked and tested this on different WiFi modules, including RTL8189FS, RTL8189ES, and ATM603x, all using the Ingenic T20/31 platforms.
@victorxda, did my changes cause real issues for you on your devices, or are they just observations of the scripts? I'd hate to revert such a time saving effort.

I made some boottime tests with the previous and current firmware to check for the actual time difference.

Old firmware with post-up:
--- boot time: 11 seconds

Old firmware with pre-up:
--- boot time: 9 seconds

Current firmware:
--- boot time: 22 seconds

The pre-up vs. post-up makes indeed a difference, so we are keeping this change.
The main culprit seems to be the discover packets, which sometimes stacks up to the complete 15 queries:
udhcpc: broadcasting discover
udhcpc: broadcasting discover
[...]
udhcpc: broadcasting discover
udhcpc: broadcasting discover

Timeout Change: We set the timeout to 15 seconds. It gives udhcpc enough time to work properly, making sure devices connect without issues. The dhcp lease is aquired before udhcpc moves into the background, saving time.

I don't see a timeout change, but there two options that come into question:
Pause between packets -T and Send up to N discover packets -t which is mentioned on point 3.
Both should be reduced to the minimum value to reduce the setup time.

 -x hostname:$(hostname) -T 1 -A 0 -R -b -O search solves the delay (20 seconds default) after udhcpc forks to the background.


Fix skip mode

For #131.
Add set_skip() function which sets skip flags of all MI blocks in
a partition block size.

@ycho does this fix #131? If so, please close the related issue.

I think further testing is required to close this!


Add support for Connect RPC protocol

Title: Add support for the Connect RPC protocol, on par with gRPC and gRPC-Web
Description:
Add two features to support the Connect RPC protocol:

Export metrics for proxied Connect traffic, as Envoy does today for gRPC.
Add a filter to translate from the Connect protocol to gRPC, as Envoy does today to expose gRPC backends to gRPC-Web clients.

The Connect protocol and the associated RPC libraries are similar to gRPC: they use HTTP as a transport, support unary and streaming RPCs, and are encoding agnostic but usually paired with Protobuf. Unlike gRPC, the Connect protocol works with HTTP/1.1,† doesn't use HTTP trailers, and keeps the wire representation of unary RPCs dead simple. Because it demands very little of the underlying HTTP transport, Connect is easy to adopt: clients can be as simple as a cURL one-liner, and popular frameworks like Rails, Flask, and Laravel can serve Connect traffic.
Envoy's excellent metrics are, by themselves, a significant incentive for organizations to adopt gRPC. It'd be wonderful to bring the same consistent observability to Connect traffic.
Of course, many organizations already have large gRPC deployments. A translating filter would let web browsers call these backends using a protocol that's more developer-friendly than gRPC-Web. We designed Connect with translating proxies in mind, so converting to and from gRPC is simple, reasonably efficient, and semantically lossless.
Thanks for considering this enhancement!
Relevant Links:

The Connect website, especially the project overview
The Connect protocol specification
The Go implementation
The TypeScript implementation (for browsers)
Implementations for Node.js, Kotlin, and Swift are in progress.

† Naturally, bidirectional streaming still requires HTTP/2. Unary, server streaming, and client streaming RPCs work over HTTP/1.1 or HTTP/2.

cc @alyssawilk

I'm in favor of supporting this, pending finding someone to implement it. It should be very similar to the grpc-web filter. One thing that I wonder is whether the grpc-web filter can just be modified to also support connect traffic which might make overall maintenance less costly.

Glad to hear it :tada: If there's agreement that these additional features are welcome, we can help find bandwidth to implement:

Someone at @bufbuild could put up a PR. Our skill ranges from "saw some C++ decades ago" to "wrote a bit of production C++ 3y ago," but nobody on our team is fearlessly shipping GFE diffs 🤣 That said, we can make sure that the Connect protocol gets implemented correctly.
If it would help the Envoy community, we could also offer a short-term contract to someone in the community. Perhaps someone's between full-time jobs or wants to start putting together an Envoy-focused contracting business?

Basically, we're happy to partner up on this.

@jchadwick-buf has a draft PR open (https://github.com/envoyproxy/envoy/pull/24836) to add two filters to Envoy: one to collect stats for Connect traffic, and one to bridge Connect to gRPC.
In the few months since we opened this issue, adoption of Connect has grown a fair bit. Privately, a number of users have said that they'd like these features in Envoy.

Envoy's gRPC stats are excellent, so organizations often grow to depend on them. Orgs moving from gRPC to Connect naturally want the same stats, collected in the same place.
Quite a few mobile and web users of connect-{web,kotlin,swift} were reluctant to adopt the grpc-web protocol, but are happy with Connect. They'd like to drop their cumbersome grpc-gateway deployments in favor of a simple Connect-to-gRPC bridge within Envoy, which they'll deploy as an API gateway.
Backend microservice teams have begun migrating to the Connect protocol, but they'd like a shim to let their existing gRPC-only servers speak the new protocol. Many of those users already run Envoy as part of their service mesh's data plane, so the bridge filter works well for them.

As far as I know, only PlanetScale is currently discussing their use of Connect in public. I'll poll our Slack and see if any other users are able to publicly +1 this comment.

The bridge filter has been a consistent request from orgs migrating from gRPC to Connect. Mobile and web teams want it because they like the Connect protocol, but need to interoperate with a large gRPC-only backend. (Switching to the c


mautrix-signal: 0.7.1 -> 0.7.2

Changelog: https://github.com/mautrix/signal/releases/tag/v0.7.2
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[x] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

The fix is not in a release yet, the recommendation from https://github.com/mautrix/signal/issues/564#issuecomment-2427399352 is to use main instead

The fix is not in a release yet, the recommendation from mautrix/signal#564 (comment) is to use main instead

Do you know which commit in particular fixed it? The usual procedure would then be to only pull in that commit / PR as a patch into nixpkgs until the next release.


Add VS Code settings

Close: #62

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (32a754b) 100.00% compared to head (9364edb) 100.00%.

Additional details and impacted files
@@            Coverage Diff            @@
##              main       #64   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            2         2
  Lines           23        23
=========================================
  Hits            23        23

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Modelsim Block Design and IP Core integration

Reworks way of integrating IP Cores and Block Designs into ModelSim simulation

Please, rebase your branch on the current devel in the OFM repository.

For now just rebased.
Testing of the rebased changes will be done within a week.


Page requires refresh

Orchestration mode. is not the  option any more

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: e0ac55b8-8be8-1f86-e3b1-3fe3f6c340c1
Version Independent ID: c26d3fc8-b62c-4895-3687-2fc7364c6383
Content: Quickstart - Create a virtual machine scale set in the Azure portal - Azure Virtual Machine Scale Sets
Content Source: articles/virtual-machine-scale-sets/quick-create-portal.md
Service: virtual-machine-scale-sets
Sub-service: ****
GitHub Login: @ju-shim
Microsoft Alias: jushiman

@gorankuk I will look into this, thank you for the information.

Thanks for the feedback! We've assigned this issue to the content author to investigate further and update the document as appropriate.

Hello, I looked into this quick start and we refreshed it some time after you submitted this issue. It is up to date and there have been recent releases surrounding Orchestration Modes. Here is a link to the Orchestration Modes preview:
https://docs.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-orchestration-modes
In the coming months, you will see a number of updates throughout our documents having to do with orchestration.
Thank you for your report, we will be closing this now. #please-close


Create a 'save button'

Would be nice to have the option to save the current alert (after asses its occurrence) and provide a download file (.csv, shapefile, jsson).

This was partially solved with #19 19

Ant totally fixed with c5c48546b296ba9ef65df85577ef2c702aab5caa


udpate codecov-action

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@61d1ac0). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main       #1   +/-   ##
=======================================
  Coverage        ?   73.68%
=======================================
  Files           ?        2
  Lines           ?       19
  Branches        ?        0
=======================================
  Hits            ?       14
  Misses          ?        5
  Partials        ?        0

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Login Page

I want to add an impressive Login page to this.
This is the need of the hour. It has been time since contributors have asked for login page but nobody makes it. Kindly assign me this. I will finish this fast

@Ojas-Arora Issue assigned to you


IsGeolocationEnabled Event

Hello,
I'd like implement a event to inform my when the IsGeolocationEnabled is enabled or not.
How can do it that?
Thanks,
XCO

I agree 100% with this suggestion. If the user disables the GPS on the device (e.g. boarding an aircraft) and later re-enables the GPS, the application is not able to resume picking up location changes.
Thanks for all the good work!


MultiInferenceMessage & MultiResponseMessage share a new base class

MultiInferenceMessage & MultiResponseMessage now inherit a new class MultiTensorMessage reducing the duplicated code in each
MultiResponseProbsMessage class now uses ResponseMemoryProbs
Add missing docstrings
Common CSV & Json reading code moved to deserializers.[hpp|cpp]

fixes #313
fixes #311

@gpucibot merge


Add Customer Users list page to admin app

Description
This PR adds the customer user list page to the admin app. I also added in a basic e2e cypress test for the home page and the admin page.

Reviewer Notes
I am not sure how to create an admin user that will work across all three environments.
Setup
Add any steps or code to run in this section to help others prepare to run your code:
To view the new page complete the following steps.

make server_run in a terminal
make admin_client_run
Wait for the admin home page to load and click on Sign In Local
Click create new user
Navigate to the Customer Users tab on the left hand navigation

Code Review Verification Steps

[x] If the change is risky, it has been tested in experimental before merging.
[x] Code follows the guidelines for Logging
[ ] The requirements listed in
Querying the Database Safely
have been satisfied.
Any new migrations/schema changes:

[ ] Follow our guidelines for zero-downtime deploys (see Zero-Downtime Deploys)
[ ] Have been communicated to #g-database
[ ] Secure migrations have been tested following the instructions in our docs

[x] There are no aXe warnings for UI.
[ ] This works in Supported Browsers and their phone views (Chrome, Firefox, IE, Edge).
[ ] Tested in the Experimental environment (for changes to containers, app startup, or connection to data stores)
[ ] User facing changes have been reviewed by design.
[ ] Request review from a member of a different team.
[ ] Have the Jira acceptance criteria been met for this change?

References

Jira story for this change
this article explains more cypress tests :)

Warnings

:warning:

It looks like you are attempting to bypass a linter rule, which is not within
security compliance rules.
** Contains a rule that is not in the permitted eslint list. You are free to disable only: (
no-underscore-dangle
,prefer-object-spread
,object-shorthand
,camelcase
,react/jsx-props-no-spreading
,react/destructuring-assignment
,react/forbid-prop-types
,react/prefer-stateless-function
,react/sort-comp
,import/no-extraneous-dependencies
,import/order
,import/prefer-default-export
,import/no-named-as-default
) **
Please remove the bypass code and address the underlying issue. cc: @transcom/Truss-Pamplemoose

:warning:
This PR does not include changes to unit tests, even though it affects app code.

:warning:

Files located in legacy directories (src/shared or src/scenes) have
been edited. Are you sure you don’t want to also relocate them to the new file structure?
View the frontend file org ADR for more information

:warning:
Please add the JIRA issue key to the PR title (e.g. MB-123)

  Generated by :no_entry_sign: dangerJS against 40206bd759ce3377fe7f99b1664ebad4ce4166f7

Warnings

:warning:

It looks like you are attempting to bypass a linter rule, which is not within
security compliance rules.
** Contains a rule that is not in the permitted eslint list. You are free to disable only: (
no-underscore-dangle
,prefer-object-spread
,object-shorthand
,camelcase
,react/jsx-props-no-spreading
,react/destructuring-assignment
,react/forbid-prop-types
,react/prefer-stateless-function
,react/sort-comp
,import/no-extraneous-dependencies
,import/order
,import/prefer-default-export
,import/no-named-as-default
) **
Please remove the bypass code and address the underlying issue. cc: @transcom/Truss-Pamplemoose

:warning:
This PR does not include changes to unit tests, even though it affects app code.

:warning:

Files located in legacy directories (src/shared or src/scenes) have
been edited. Are you sure you don’t want to also relocate them to the new file structure?
View the frontend file org ADR for more information

:warning:
Please add the JIRA issue key to the PR title (e.g. MB-123)

  Generated by :no_entry_sign: dangerJS against 40206bd759ce3377fe7f99b1664ebad4ce4166f7


Update 15-Howto-Track-File-Inputs-and-Outputs.md

Correct typo

I just signed the Scala CLA, so the CLA check should now pass.


Disable in CI environments

Hello, I'm an avid user of this module. Thanks for making and maintaining it.
I often find that this module causes issues in CI environments where the env configuration is not always the same as development. So our team (@electron) usually ends up doing this:
if (!process.env.CI) require('dotenv-safe').load()

All the CI providers set this environment variable.
Would you open to making this a built-in feature in dotenv-safe? Maybe an option?
Edit: One could even argue that because this tool is intended for use in development, it could automatically abort if process.env.CI is detected. That would of course be a breaking change and would require a major version bump.

Could you go into a bit more detail about the issues you're seeing in CI?

We have numerous CI environments with different jobs (Travis, AppVeyor, Circle, and VSTS), and some of them only need a subset of the variables listed in .env. For example, some boxes do releases to S3 and GitHub, so they need those credentials, but other boxes just run tests and don't need any of these credentials.
As an alternative to changing the behavior, we could also document the process.env.CI technique in the README. 🤔

I see, that makes sense. I can't think of a sensible default that would work for both cases, where you either care or don't care about validating environment variables when running on CI. It's also problematic because you could still care about the subset of the variables you're using only for CI.
One workaround I can think of is using different example files depending on process.env.CI, something like this:
require('dotenv-safe').config({
  example: process.env.CI ? '.env.ci.example' : '.env.example'
});

which would have the benefit of "documenting" what's needed for CI and what isn't. You would probably have some duplication between the CI and non-CI example files, though.
I've also thought of accepting multiple example files, so you could have something like this:
require('dotenv-safe').config({
  example: process.env.CI ?
    ['.env.credentials.example', '.env.dev.example'] :
    ['.env.dev.example']
});

which would validate against the union of all variables defined in all the different files, and not need to have duplicated variables defined in each example file. Creating a single .env file from all of them could be done with cat .env.credentials.example .env.dev.example | uniq > .env, which is a bit less elegant than cp .env.example .env. If there are duplicates it won't be a problem, because there can't be any conflicts. What do you think?

I think your first example is easier to understand. There could be duplicates across files but I think it's worth it to keep the API simpler.

Also thanks for taking the time to think through this problem. Just want to reiterate that  supplementary documentation may be the best answer for now.

 Yes, I agree that adding documentation is the way to go. If more cases like this one come up, we can revisit adding new features to the API. Thanks for bringing this up, by the way.

Was just about to update the README but I see you did that already in https://github.com/rolodato/dotenv-safe/commit/2d3e705c7eb68e1af1638e120e9933e1361aaf91. Thanks!


use correct path for build artifacts

Build logs are showing:
Collecting artifacts...
No artifacts found matching 'out_engine\*.nupkg' path
No artifacts found matching 'out_console\*.nupkg' path
"NuGet" deployment has been skipped as environment variable has not matched ("appveyor_repo_tag" is "false", should be "true")
"NuGet" deployment has been skipped as environment variable has not matched ("appveyor_repo_tag" is "false", should be "true")
Build success

Running the build locally, the artifacts appear to be in LocalAppVeyor.Engin\out_engine and LocalAppVeyor\out_console respectively, so update the appveyor.yml file so it can find them.

It seems to be broken since migration from project.json.
Thank you for this!


[New Resource] xPSListener

This would be used to add, remove or configure WS-Man listeners. The most likely use case for this is to allow creation of an HTTPS WS-Man listener and deleting the HTTP WS-Man listener.
I've already created this resource as cWSManListener in a separate resource module and submitted it to be added to the DSC Community resources, but perhaps it would be better to be added to an existing module. I would suggest renaming the resource to xPSListener. Or is there a better suggestion?
In the company I work for we use this resource as well as the xPSDesiredStateConfiguration.xPSEndpoint resource as well as my cWSManListener resource to ensure our remoting connections are secure. It would be really nice if we didn't have to use two resource modules for this task as they're fairly closely related.

@PlagueHO Since there's also this resource that you posted, I would say this should be in a separate WSManDsc resource module along with that new resource.
@TravisEz13 @KarolKaczmarek What do you think?

xPSListener doesn't seem like the correct name.

@TravisEz13  - I've changed the name of this to:
WSManListener.
Does that sound like a more appropriate name?

I'm going to close this issue as it is covered in this Issue:
https://github.com/PowerShell/DscResources/issues/75


Significant memory overhead in write_parquet

Describe the bug
When generating a 1 GiB dataset, the peak memory usage varies significantly depending on the daft data types (uint8, list[uint8], tensor[uint8]). The memory spike occurs only during write_parquet.
To Reproduce
Steps:

Create a dataset of size 1 GiB (using 1024**3 uint8 elements).
Store the data in three formats:

uint8
list[uint8]
tensor[uint8]

Write each dataset to disk using daft’s write_parquet method.

Code:
import tempfile
import numpy as np
import daft
from typing import Literal

def gen_1gb_df(dtype: Literal["uint8", "list[uint8]", "tensor[uint8]"]) -> daft.DataFrame:
    if dtype == "uint8":
        shape = (1024 * 1024 * 1024)
    elif dtype == "list[uint8]":
        shape = (1024, 1024 * 1024)
    elif dtype == "tensor[uint8]":
        shape = (1024, 1024, 1024)
    else:
        raise ValueError(f"Invalid dtype: {dtype}")

    df = daft.from_pydict({"A": np.random.randint(low=0, high=256, size=shape, dtype=np.uint8)})  # 1GB
    return df

def write_temp_parquet(df: daft.DataFrame):
    with tempfile.TemporaryDirectory() as tmpdir:
        df.write_parquet(tmpdir)

if __name__ == "__main__":
    # daft.set_execution_config(enable_native_executor=True)
    df = gen_1gb_df(DTYPE)
    write_temp_parquet(df)

Results:
uint8:

list[uint8]:

tensor[uint8]:

Reuslts with native executor:
If adding the following line before generating the df
daft.set_execution_config(enable_native_executor=True)

uint8:

list[uint8]:

tensor[uint8]:

Expected behavior
A x20 or x35 memory overhead (depends on the runner) for certain datatypes seems excessive.
Component(s)
Parquet
Additional context
Materializing the dataframe without writing it results in much lower memory usage.
I was using daft v0.3.14

Thanks for making this issue!
I've ran the repro and I've identified a couple issues:

The write operator in swordfish currently buffers data into morsel_size rows and subsequently into rows_per_row_group rows. This double buffering is unnecessary and we just need to do rows_per_row_group rows.
Instead of buffering by rows_per_row_group rows we should buffer by a strict row_group_size bytes. In the list/tensor examples there are only 1024 rows, but each row is very large. The py_runner is able to write this into 3 row groups, but swordfish only writes 1 row group. This causes inflated memory usage because swordfish needs to allocate a much larger buffer to write this 1 mega row group.

Should have a fix for this pretty soon.
This is a before and after of the tensor[uint8] example with the above fixes implemented. (Running swordfish on a 128cpu machine)

That was quick - great catch! Thanks!

@sagiahrac looks like a fix for this issue has been implemented and released in version 0.3.16. I'll close this issue now, feel free to reopen if the issue persists in the new library version.

Sorry what I meant to say is that the change is in main and will be part of the upcoming v0.3.16 release. We have not yet published v0.3.16.


Peek references is currently scrolling to the wrong position

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.88.0
OS Version: Windows 10

Steps to Reproduce:

Open a code file (I'm using TypeScript) with a reference to a function defined at least 20-30 lines down in some other file.
Place the cursor on the reference and press shift+F12.
The peek references window displays with the referenced line appearing 5 lines below the visible scroll area of the peek code view.

I've tested with and without extensions loaded, and on two different projects - one which is a multiroot workspace and one which is not.
https://github.com/microsoft/vscode/assets/298883/fc5c68f4-c009-45f0-aa01-5ffd86ade164
Note: My previous attempt to report this issue was met with premature closure for invalid reasons and seems to now be being ignored, so I'm opening a new version of it with an updated video. Please don't close this before at least following up. See the video above.

same here

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for similar existing issues. See also our issue reporting guidelines.
Happy Coding!


Bitmap fonts (.fnt) are not correctly displayed in Theme preview and on Label3D

Godot version
Godot 4 beta 4
System information
Windows 10
Issue description
Bitmap fonts (.fnt) will not show the font correctly in the theme preview and when used on Label3D (the "white bar" on the screenshot)
Using such a theme will however work as expected on Buttons and Labels outside the Theme preview.

Steps to reproduce
Use the .fnt font file on a Theme
Use the .fnt font file on a Label3D
Minimal reproduction project
bitmap_font_test.zip

Can't reproduce, bitmap fonts are working fine in both preview and Label3D. Please provide your bitmap font file to test, most likely it is not loaded correctly. Unlike UI controls, Label3D and Preview will not fall back to the default built-in font and display hex code/white boxes if the font is not loaded or do not have required glyphs.

Oh ok. I have attached a minimal project with my font.
I figured out how to create a .fnt file and made a little tool in godot to create one but i guess there must be something off then.

Your file have missing font size (it's probably should be ignored by importer) and char count set to one 1 whine there are 81 char in the file (this is clearly wrong):
If the first 4 lines of the fnt file are changed to the following, it will work:
info face="plaque" size=16
common lineHeight=6
page id=0 file="plaque.png"
chars count=81

Loading fonts with missing font size should be fixed by https://github.com/godotengine/godot/pull/68664, and your tool should set valid number of chars.

Wow, thanks a lot for your help! You people are fantastic!
Sorry for reporting a non-bug


About load interval

Hello, thank you for your great work.
I have a question regarding acceptible arguments of your config file.
Is it possible to set the load_interval in config file like mmdetection?
If it's possible, where should I specify the argument?
Thank you for your reply.

For BEVDepth's exps files, load_interval inside parser.set_defaults(load_interval=7) worked same way as in mmdetection 3d.
However, I figured out that the same setting does not work for BEVStereo exps files.
How did you pass the load_interval argument in BEVDepth?


[BUG] AWS Credential refresh not getting picked up

Describe the bug
I have a CLI that refreshes the AWS credentials continuously on my machine. For the last many months, the app has been able to pick up the refreshed credentials without any issues.
Now in 1.2.3, I have to restart the app for it to pick up the credentials once they expire.
Environment (required):

macOS version: 15.1
Amazon Bedrock Client for Mac version: 1.2.3

Sorry, will be fixing right now.


Debian setup instructions

I'm a bit confused at how to set this up on Debian or Ubuntu.  On a Debian 12 live ISO I run the commands sudo apt install gophernicus telnet, then telnet localhost 70 and receive this:

What I was expecting maybe was to see a landing page or an empty directory listing.  I've tried creating /var/gopher and adding files to it but nothing changes this response.  I've tried the same on Ubuntu 24.04 and got the same response with telnet. Am I supposed to modify the installed systemd files?  Or am I meant to run gophernicus -r some/directory elsewhere?  Unless I've missed it completely I can't find anything specific about this in the documentation.

My apologies I've just realised that Debian/Ubuntu defaults to /srv/gopher for serving.  The included man page and some of the documentation here refer to /var/gopher however.

Seriously sorry I just found README.Debian, all is illuminated thank you all


Reproducibility Updates

Adding some reproducibility updates.
Adding a few more tidbits here.
I knitted things by hand because make labs wouldn't work.
Rscript -e "remotes::install_github('muschellij2/jhur')"

won't install which is required by this.
Downloading GitHub repo muschellij2/jhur@HEAD
Error: Failed to install 'jhur' from GitHub:
  missing value where TRUE/FALSE needed
Execution halted

Looks good so far! Indeed I think we could simplify how things are rendered, but we were going with how it was previously done. is that error from using the make command in the main directory? luckily it is still working for me - what we did last time is the other instructors made edits to the respective rmd files and then I rendered everything to avoid conflicts as well.

is that error from using the make command in the main directory?

Yes. Although it should be able to install from anywhere.

is that error from using the make command in the main directory?

Yes. Although it should be able to install from anywhere.

I guess we should check his code and file a PR if we can figure it out

I see that you went with a different final rendered version without slides- was there a reason for that? Just curious.  Also would it be ok if I add one or more of your cartoons from your course?


Thoughts on children VDRs inside parent VDR (handling recursion)

I stumbled upon the case-scenario in which a VDR may have other VDRs as children. Having the prop :parent=true maintains the children within the parent boundaries (as expected GOOD!), but the activation mechanism (meaning whether or not a VDR is active) occurs in all children VDRs (included the parent VDR). In this case, when trying to drag a child, the parent would move as well (once the child has reached the parent boundaries).
Probably not the best explanation (hard to do it in words... I'll try to post a visual example), but I hope my point goes through. I will be looking into vdr code to find possible solutions. However, this feature might not be within your development plans.
Any thoughts on this? Cheers!

Your point is clear, but as you said it is not an essential feature at this point. However if you are able to make it work without twisting the component (I believe that the issue is related to the propagation of mouse events), I might accept a PR.
Cheers!

I believe that the issue is related to the propagation of mouse events

That's right!
I've been able to create well behaved children (and down to any depth... grandchildren, etc).
The implementation was actually very simple and it actually lead me to solve something I had noticed before, which is that when the container (parent) of a VDR changes its dimension (after being rendered), the VDR element is unaware of it and will move out of bounds (or have invisible walls).
With this changes, even if the parent changes size after the element is mounted, the VDR knows what the limits are.

(the red box sudden jump happens when it gets clicked, re-calculates its parent limits and gets inside its bounds, there are other options, but that one seemed the simplest one)
I'll be pushing this commit and opening a PR, let me know!


Output in combination with metafile not working

This is a very useful package. One issue that I have:
I tried to run:
npx banal --metafile ./dist/my-app/stats.json --output ./analyze/index.html
This does not work, only --output-analysis seems to work, and also if the folder does not exist, we get an ENOENT error.

if the folder does not exist, we get an ENOENT error.

Just fixed in v1.5.1.

I tried to run:
npx banal --metafile ./dist/my-app/stats.json --output ./analyze/index.html
This does not work, only --output-analysis seems to work

--output is for outputting the artifacts needed for the analysis, the stuff that you'd find by opening the "temp path" that gets logged when doing something like npx banal chalk. In this case those files are not generated because you are starting from a --metafile already, so it only makes sense to use --output-analysis in combination with that.


Graphql auth transformer/dynamic groups

Description of changes
I moved the changes suggested in this PR over to the new repository: https://github.com/aws-amplify/amplify-cli/pull/9535. This adds support for dynamic groups when the custom claims are a stringified array (e.g. custom claims set through the Cognito pre-token-generation trigger).
cc @danielleadams this is the PR with the changes you suggested in this comment https://github.com/aws-amplify/amplify-cli/pull/9535#issuecomment-1169926914. Please take a look when you get the time and let me know if this looks alright to you. Thanks
Issue #, if available
https://github.com/aws-amplify/amplify-category-api/issues/132
Description of how you validated changes
I tested the changes both through automated tests and manually
Checklist

[ ] PR description included
[ ] yarn test passes
[ ] Tests are changed or added
[ ] Relevant documentation is changed or added (and PR referenced)
[ ] New AWS SDK calls or CloudFormation actions have been added to relevant test and service IAM policies

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Hey @alex-vladut ,
Thank you for writing this contribution, I'm going over the code now but could you rebase this on main to resolve conflicts first?


docs(*) add 1.8.3 changes

Add 1.8.3 changes and release instructions.
Small, but we haven't had a patch release in quite a while, and the error return is something we want in KIC sooner or later.
I also want to confirm the new CI stuff works in the actual deck repo and confirm if there's something I forgot that still requires manual work.
Added release instructions since we'd apparently forgotten to ever take them out of a Google Doc, and they've been stable for a while now.

Codecov Report

Merging #535 (8cfe7b7) into main (4820ab9) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #535   +/-   ##
=======================================
  Coverage   50.46%   50.46%
=======================================
  Files          72       72
  Lines        7871     7871
=======================================
  Hits         3972     3972
  Misses       3550     3550
  Partials      349      349

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4820ab9...8cfe7b7. Read the comment docs.


RFC 0040 - add trait implementations to export structs to JSON Schema

Rendered
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Hi @Swolebrain I discussed this with the team today, and we're all on board with deriving JsonSchema for more Cedar types (although we want to be careful about not accidentally exposing internal datatypes -- but we can iron this out when reviewing the PR). We also think it's a good idea to put this behind a flag so that users aren't required to take the dependency/extra compile time if they don't need it.
We also agreed that the RFC mechanism is a little heavy weight for this particular request, since it's not changing the language per se. We'd prefer using an issue to track this instead -- I've taken the liberty of porting to an issue here: https://github.com/cedar-policy/cedar/issues/492
Let me know if that sounds ok and I'll close the RFC. Thanks for submitting this!


Change external ip address provider to ifconfig.co

For the time being icanhazip.com works. If the site goes down or we get a notification to use another site ifconfig.co will be the first one that we check.