arendst
Bluetooth BT BLE devives (EQ3) not connecting properly
PROBLEM DESCRIPTION
A clear and concise description of what the problem is.
I do not know if this is related to issue https://github.com/arendst/Tasmota/issues/21445, but after upgrading my esp32/esp32c3 devices to 14.2.0.6, my eQ3 devices are no longer connecting reliably.
I have 8 Xiaomi devices and 8 EQ3s. The Xiaomis (running ATC firmware) seem to work but the EQ3s just show 20:44:07.951 EQ3: 001A2208C9FA: trv operation failed - retrying -12 (with the respective device ID).
Interestingly, I see all 8 EQ3 TRVs right after a restart and they briefly show the correct temperatures in the WebUI. But then the connection starts failing and all values are set to 0.
Does anybody have similar issues?
EDIT: Reverted to 13.4.0 (http://ota.tasmota.com/tasmota32/release-13.4.0/tasmota32-bluetooth.bin) and it works again. So seems that something is broken in 14.2.0.6 again.
REQUESTED INFORMATION
Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!
- [ x] Read the Contributing Guide and Policy and the Code of Conduct
- [x ] Searched the problem in issues
- [x ] Searched the problem in discussions
- [x ] Searched the problem in the docs
- [x ] Searched the problem in the chat
- [x ] Device used (e.g., Sonoff Basic): esp32 and esp32c3
- [x ] Tasmota binary firmware version number used: 14.2.0.x
- [x ] Pre-compiled
- [ x] Self-compiled
- [x ] Flashing tools used: OTA
- [ ] Provide the output of command:
Backlog Template; Module; GPIO 255:
Configuration output here:
- [ ] If using rules, provide the output of this command:
Backlog Rule1; Rule2; Rule3:
Rules output here:
- [x ] Provide the output of this command:
Status 0:
STATUS 0 output here:
14:22:13.465 CMD: status 0
14:22:13.475 MQT: stat/tasmota_F66EEC/STATUS = {"Status":{"Module":1,"DeviceName":"Tasmota","FriendlyName":["Tasmota"],"Topic":"tasmota_F66EEC","ButtonTopic":"0","Power":"0","PowerLock":"0","PowerOnState":3,"LedState":1,"LedMask":"FFFF","SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0,"InfoRetain":0,"StateRetain":0,"StatusRetain":0}}
14:22:13.519 MQT: stat/tasmota_F66EEC/STATUS1 = {"StatusPRM":{"Baudrate":115200,"SerialConfig":"8N1","GroupTopic":"tasmotas","OtaUrl":"http://192.168.0.2:8000/tasmota32c3-bluetooth.bin","RestartReason":"Software reset digital core","Uptime":"0T00:02:38","StartupUTC":"2024-10-11T13:19:35","Sleep":50,"CfgHolder":4618,"BootCount":1,"BCResetTime":"2024-10-11T14:19:40","SaveCount":6}}
14:22:13.567 MQT: stat/tasmota_F66EEC/STATUS2 = {"StatusFWR":{"Version":"14.2.0.6(bluetooth)","BuildDateTime":"2024-10-10T23:20:25","Core":"3_1_0","SDK":"5.3.1.240924","CpuFrequency":160,"Hardware":"ESP8685 v0.4","CR":"429/699"}}
14:22:13.593 MQT: stat/tasmota_F66EEC/STATUS3 = {"StatusLOG":{"SerialLog":2,"WebLog":2,"MqttLog":0,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["BaumlerlangenHA24",""],"TelePeriod":300,"Resolution":"558180C0","SetOption":["00008009","2805C80001000600003C5A0A192800000000","00000080","00006000","00004002","00000000"]}}
14:22:13.625 MQT: stat/tasmota_F66EEC/STATUS4 = {"StatusMEM":{"ProgramSize":1725,"Free":1154,"Heap":85,"StackLowMark":3,"PsrMax":0,"PsrFree":0,"ProgramFlashSize":4096,"FlashSize":4096,"FlashChipId":"164020","FlashFrequency":40,"FlashMode":"DIO","Features":["0809","8F9AC7CF","00148001","000000CF","011013C0","C0000981","40004080","00200000","5400082C","40000080","00000004"],"Drivers":"1,2,!3,!4,!5,7,!8,9,10,12,!16,!20,!21,!24,26,!27,29,!35,38,50,52,!59,62,!68,79,82,85,!121","Sensors":"1,2,3,5,6,40,52,62,127","I2CDriver":"7"}}
14:22:13.685 MQT: stat/tasmota_F66EEC/STATUS5 = {"StatusNET":{"Hostname":"tasmota-F66EEC-3820","IPAddress":"192.168.0.22","Gateway":"192.168.0.1","Subnetmask":"255.255.255.0","DNSServer1":"192.168.0.1","DNSServer2":"0.0.0.0","Mac":"54:32:04:F6:6E:EC","IP6Global":"","IP6Local":"fe80::5632:4ff:fef6:6eec%st1","Ethernet":{"Hostname":"","IPAddress":"0.0.0.0","Gateway":"0.0.0.0","Subnetmask":"0.0.0.0","DNSServer1":"192.168.0.1","DNSServer2":"0.0.0.0","Mac":"00:00:00:00:00:00","IP6Global":"","IP6Local":""},"Webserver":2,"HTTP_API":1,"WifiConfig":4,"WifiPower":19.0}}
14:22:13.751 MQT: stat/tasmota_F66EEC/STATUS6 = {"StatusMQT":{"MqttHost":"192.168.0.2","MqttPort":1883,"MqttClientMask":"DVES_%06X","MqttClient":"DVES_F66EEC","MqttUser":"mqtt","MqttCount":1,"MAX_PACKET_SIZE":1200,"KEEPALIVE":30,"SOCKET_TIMEOUT":4}}
14:22:13.789 MQT: stat/tasmota_F66EEC/STATUS7 = {"StatusTIM":{"UTC":"2024-10-11T13:22:13Z","Local":"2024-10-11T14:22:13","StartDST":"2024-03-31T02:00:00","EndDST":"2024-10-27T03:00:00","Timezone":"+01:00","Sunrise":"07:05","Sunset":"18:07"}}
14:22:13.810 MQT: stat/tasmota_F66EEC/STATUS10 = {"StatusSNS":{"Time":"2024-10-11T14:22:13"}}
14:22:13.823 MQT: stat/tasmota_F66EEC/STATUS11 = {"StatusSTS":{"Time":"2024-10-11T14:22:13","Uptime":"0T00:02:38","UptimeSec":158,"Heap":87,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"Berry":{"HeapUsed":4,"Objects":47},"Wifi":{"AP":1,"SSId":"BaumlerlangenHA24","BSSId":"F8:D2:AC:D6:92:A0","Channel":6,"Mode":"HT40","RSSI":100,"Signal":-45,"LinkCount":1,"Downtime":"0T00:00:04"}}}
- [x ] Set
weblogto 4 and then, when you experience your issue, provide the output of the Console log:
Console output here:
14:24:16.816 CMD: trvperiod 30
14:24:16.819 SRC: WebConsole from 192.168.0.168
14:24:16.821 CMD: Grp 0, Cmd 'TRVPERIOD', Idx 1, Len 2, Pld 30, Data '30'
14:24:16.832 MQT: stat/tasmota_F66EEC/RESULT = {"trvperiod":30}
14:24:19.725 EQ3: 001A2214ADC8: Poll fail not sent because EQ3HideFailedPoll
14:24:19.727 EQ3: 001A2214ADC8: trv operation failed - no more retries -12
14:24:19.735 MQT: tele/tasmota_F66EEC/BLE = {"BLEOperation":{"opid":"3","stat":"-12","state":"FAILNOTIFY","MAC":"001A2214ADC8","u":"128","svc":"3e135142-654f-9090-134a-a6ff5bb77046","char":"3fa4585a-ce4a-3bad-db4b-b8df8179ea09","notifychar":"d0e8434d-cd29-0996-af41-6c90f4e0eb2a","write":"03180A0B0E1808000000000000000000"}}
14:24:23.428 M32: A4C138F28078: New ATC at slot 4
TO REPRODUCE
Steps to reproduce the behavior:
Upgrade to 14.2.0 and enable BLE (if not already enabled). Check console for EQ3-TRV messages.
EXPECTED BEHAVIOUR
A clear and concise description of what you expected to happen.
SCREENSHOTS
If applicable, add screenshots to help explain your problem.
ADDITIONAL CONTEXT
Add any other context about the problem here.
(Please, remember to close the issue when the problem has been addressed)
I built tasmota32s3-bluetooth with use config overrides of:
#define WEBCAM_DEV_DEBUG
#define BLE_ESP32_DEBUG
#define USE_MI_ESP32
#define USE_BLE_ESP32
#define USE_EQ3_ESP32
works on fresh build of 14.2.0.1 on S3. EQ3 polling all good, out of 10 polls of three devices, only one failure (to be expected). works on build of 14.2.0.5..... I note that 1248bd138c7eda34fe91d9f60721a78210a27b56 changes the core version (commit before 14.2.0.6) works with 14.3.0.1 69f7f155dd3750ff44f620556d3d46c3ae25beda But... possibly more failed to connect, a few in a row.
failed to connect to device low level rc 0xd
...
failed to connect to device low level rc 0x216
but probably not more than expected with Eq3.... (it's a crap device ref BLE coms).
Added a battery to a temp/hum sensor (old ATC firmware). The adverts are being received, and the device displayed.
Conclusion: On my own build of latest dev, it seems working on s3. I do NOT have any aliases defined.
sample logging of a transaction with a distant eq3:
21:11:49.358 EQ3: 001A22085B1E: Op queued len now 1
21:11:49.360 EQ3: 001A22085B1E: Op dequeued len now 0
21:12:08.484 WIF: Checking connection...
21:12:19.425 BLE: failed to connect to device low level rc 0xd
21:12:19.428 BLE: failed to connect to device
21:12:19.549 BLE: BLETask: op failed -11
21:12:20.358 EQ3: 001A22085B1E: trv operation failed - retrying -11
21:12:20.362 RSL: BLE = {"BLEOperation":{"opid":"37","stat":"-11","state":"FAILCONNECT","MAC":"001A22085B1E","u":"128","svc":"3e135142-654f-9090-134a-a6ff5bb77046","char":"3fa4585a-ce4a-3bad-db4b-b8df8179ea09","notifychar":"d0e8434d-cd29-0996-af41-6c90f4e0eb2a","write":"03180A0F150B31000000000000000000"}}
21:12:28.483 WIF: Checking connection...
21:12:34.358 M32: Kick off readOneSensor
21:12:34.360 M32: Kick off tele sending
21:12:35.359 RSL: SENSOR = {"Time":"2024-10-15T21:12:35","ATC2682c3":{"mac":"a4c1382682c3","Temperature":23.2,"Humidity":51.2,"DewPoint":12.5,"Btn":0,"Battery":95,"RSSI":-50},"TempUnit":"C"}
21:12:43.356 BRY: GC from 5690 to 3707 bytes, objects freed 7/41 (in 0 ms) - slots from 46/91 to 45/91
21:12:43.362 RSL: STATE = {"Time":"2024-10-15T21:12:43","Uptime":"0T00:19:40","UptimeSec":1180,"Heap":110,"SleepMode":"Dynamic","Sleep":1,"LoadAvg":999,"MqttCount":0,"Berry":{"HeapUsed":3,"Objects":41},"POWER1":"OFF","POWER2":"OFF","Dimmer":19,"Color":"303030","HSBColor":"0,0,19","Channel":[19,19,19],"Scheme":0,"Width":1,"Fade":"OFF","Speed":1,"LedTable":"ON","Wifi":{"AP":1,"SSId":"MYSSID","BSSId":"AC:B6:87:C7:0E:B8","Channel":11,"Mode":"HT40","RSSI":100,"Signal":-33,"LinkCount":1,"Downtime":"0T00:00:04"}}
21:12:43.416 RSL: BLE = {"Time":"2024-10-15T21:12:43","BLEDevices":{"total":4,"001A22092CDB":{"i":0,"r":-72},"001A22092C9A":{"i":1,"r":-71},"001A22085B1E":{"i":2,"r":-88},"A4C1382682C3":{"i":3,"r":-50}}}
21:12:43.431 RSL: BLE = {"Time":"2024-10-15T21:12:43","BLE":{"scans":59,"adverts":4736,"devices":4,"resets":0}}
21:12:45.360 RSL: 001A22085B1E = {"cmd":"poll","result":"ok","MAC":"001A22085B1E","tas":"tasmota-9CE64C-1612","RSSI":-88,"stattime":1729023165,"temp":17.0,"posn":0,"mode":"manual","hassmode":"off","boost":"inactive","dst":"set","window":"closed","state":"unlocked","battery":"GOOD"}
21:12:45.384 RSL: BLE = {"BLEOperation":{"opid":"38","stat":"7","state":"DONENOTIFIED","MAC":"001A22085B1E","u":"128","svc":"3e135142-654f-9090-134a-a6ff5bb77046","char":"3fa4585a-ce4a-3bad-db4b-b8df8179ea09","notifychar":"d0e8434d-cd29-0996-af41-6c90f4e0eb2a","write":"03180A0F150B31000000000000000000","notify":"020109000422"}}
@AleXSR700 could you try again? If with 14.3.0.1 you still have consistent failures, check your wifi traffic (including MQTT, etc.). I had none beyond the GUI. Wifi and BLE do NOT play nice.... If possible, check serial logs with all connections closed to the esp. If necessary, I will build for 'std' esp32 (I have some webcam boards I bought for Eq3 use because of external antennas), and test again; just not sure when.
I will start a new build and start testing tomorrow.
Btw, you are building the base binaries instead of the bluetooth variant?
#define USE_MI_ESP32
#define USE_BLE_ESP32
#define USE_EQ3_ESP32
These are all part of the bluetooth variant (not sure if there is more to it than this plus the libs).
I will test as before with the bluetooth variant and if that fails, build and test the base image with those three enabled manually to countercheck.
I built tasmota32s3-bluetooth with the above. (bluetooth variants did not used to have USE_BLE_ESP32 or USE_EQ3_ESP32. now it seems they all do?)
I double checked configs, and it seems FIRMWARE_BLUETOOTH contains all for EQ3 except in _mi32 variants.
so double check your platformio_tasmota_cenv.ini is the same as the platformio_tasmota_cenv_sample.ini (for your c3), and the pure bluetooth variants should be fine. The fact that you have logs from the EQ3 driver indicate your build contained everything required.
I think the Mi32 is not compatible with the new bluetooth anyway. So if you build with #define USE_MI_ESP32, then I think you are using legacy build which is not the same as the bluetooth variant. https://tasmota.github.io/docs/Bluetooth_MI32/
But I am not sure what happens when you build - blueooth variant but enable mi32-legacy mode. I thought the latter does not use the latest BLE modules or something like that.
I didn't think EQ3 was even compatible with Mi32-legacy mode.
https://discord.com/channels/479389167382691863/796060106776117288/1216387713574637641 and following.
I built esp32c3_bluetooth (without defining any of the above USE_*) and am still seeing the same issues in 14.3.0.1 (bluetooth).
There is a big update ahead for the BLE legacy stuff. Look in open PRs ;-) There is no TRV driver for the MI BLE (and there will be none). The MI BLE is the more actual BLE code.
I don't have a c3 to test with :(. could you try on plain esp32?
Yes, I have a devkit esp32. So if you have a build you would like me to test, happy to.
There is a big update ahead for the BLE legacy stuff. Look in open PRs ;-) There is no TRV driver for the MI BLE (and there will be none). The MI BLE is the more actual BLE code.
Would kind of be nice to have one BLE variant for all BLE devices :)
Only for information: I just tested the latest dev 14.3.0.1 on a "plain" ESP32 and it is working without problems.
Would kind of be nice to have one BLE variant for all BLE devices :)
Will not happen since the drivers have different goals and design concepts.
looking at the berry in the PR, seems an EQ3 driver could be written in berry over the 'new' legacy stuff? (I am not volunteering!).
@btsimonh @SteWers : Did you test with latest TRV firmware 1.46 or above?
I now flashed the tasmota32-bluetooth and tasmota32c3-bluetooth from here: https://github.com/tasmota/install/releases/tag/2024-10-16.d.e39f1cc83f17100adc41fb8b6d18a792ecd50c11
I wanted to rule out any build issues.
Neither the ESP32 nor the ESP32C3 seem to work properly. In the WebUI I see all my ATC information (Xiaomi Mijia devices) correctly but all my EQ3s only show 0 values (except for RSSI, which is not a value published by the EQ3).
So all set point temperatures, valve positions and batteries are 0 all the time.
I flashed the downloaded binaries and then performed a reset 1. Then connected back to network, turned on BLE and power cycled.
Did you test with latest TRV firmware 1.46 or above?
I don't know the firmware of the TRV.
I don't know the firmware of the TRV.
It is displayed when you put the batteries in. In the newer firmware (1.46 and above) the manufacturer changed the pairing mechanism/key. https://github.com/arendst/Tasmota/issues/16775
So if the tested EQ3 firmware is older, the issue might be related to/the same as https://github.com/arendst/Tasmota/issues/16775 and would not show up with older devices.
I upgraded of mine to 1.46, so it is not possible to test if it would work with the older ones.
mine are all older firmware. it's odd that is works for you with older TAS, but newer EQ3 firmware - the key stuff was some time ago. I'd suggest that the key stuff was not about the key (I don't think it needed it in the end? it just worked again after some tweaks?), but about doing some handshake. Maybe check the commits associated with https://github.com/arendst/Tasmota/issues/16775 and see what was added to make it work then, then check for changes in the idf/nimble?
mine are all older firmware. it's odd that is works for you with older TAS, but newer EQ3 firmware - the key stuff was some time ago.
No, I deliberately stayed with firmware versions newer than that handshake/pairing change. So firmware v12 and v13 versions post https://github.com/arendst/Tasmota/issues/16775
Maybe check the commits associated with https://github.com/arendst/Tasmota/issues/16775 and see what was added to make it work then, then check for changes in the idf/nimble?
Since all of your devices are older firmware but work and the same applies for SteWers, I was thinking the same thing. Seems like a change made back im v12 to fix the compatibility with newer EQ3 firmware is no longer present or working in v14.
Maybe @h2zero has an idea?
looked for my 'spare' eq3 today (the one i dismantled and broke the wheel on...) to see if I could upgrade it and test.
But it's not going to happen:
Washing has so far not brought it to life....
ok, that one is fubar. (It does now start, but I can't read the display). I found another... (one which had broken off the rad). It's now on 1.46, and I get at a distance of 20cm:
15:44:09.723 EQ3: 001A22092FB7: Op queued len now 1
15:44:09.725 EQ3: 001A22092FB7: Op dequeued len now 0
15:44:12.314 BLE: failed subscribe for notify
15:44:12.438 BLE: BLETask: op failed -12
15:44:13.691 EQ3: 001A22092FB7: trv operation failed - retrying -12
15:44:13.697 RSL: BLE = {"BLEOperation":{"opid":"1","stat":"-12","state":"FAILNOTIFY","MAC":"001A22092FB7","u":"128","svc":"3e135142-654f-9090-134a-a6ff5bb77046","char":"3fa4585a-ce4a-3bad-db4b-b8df8179ea09","notifychar":"d0e8434d-cd29-0996-af41-6c90f4e0eb2a","write":"03180A130F2C09000000000000000000"}}
15:44:15.956 BLE: failed subscribe for notify
It works with the Calorbt app. 5 other EQ3 have responded.... Tas version 14.3.0.1 on esp32S3
I'll check it out some more.
@Staars Cristian - help :). You have latest and intimate knowledge of esp-nimble-cpp.... @h2zero too if you are able.
We're hitting AddLog(LOG_LEVEL_ERROR,PSTR("BLE: failed subscribe for notify")); - line 1921 in tasmota\tasmota_xdrv_driver\xdrv_79_esp32_ble.ino
This is happening only for EQ3 firmware versions which have 'new' security. Seems to me that the device is connected, has a valid characteristic, says that characteristic can notify, but then nimble is telling us it can't subscribe.... (pNCharacteristic->subscribe returns false).
Any advice or guidance appreciated. br, Simon
In line 1911:
if(pNCharacteristic->subscribe(true, BLE_ESP32::BLEGenNotifyCB)) {
You try to subscribe to an indication and not a notification. Is this intended?
But at least in 1911 an incomplete function signature is used - missing the response. IDK if this is a problem.
14.1.0 (lvgl-haspmota) - not working, trying 14.0.0.2..... not working. 13.4.1.1 (lvgl-haspmota)- BLE does not work at all. 13.4.0(lvgl-haspmota) none of the eq3 work. maybe something is wrong with my build.
14.1.0 (lvgl-haspmota) - not working, trying 14.0.0.2..... not working. 13.4.1.1 (lvgl-haspmota)- BLE does not work at all. 13.4.0(lvgl-haspmota) none of the eq3 work. maybe something is wrong with my build.
See the opening post of this thread. I linked the build for 13.4.0 there. Just download that one. It won't have yourWifi or mqtt settings of course, but should at least work for testing.
If I was to guess I would say that it's failing to subscribe because it should write to the descriptor with response request as per BT specifications. The older devices/firmwares wouldn't accept that in the past so that's the reason for writing without response now. At least that's what i remember.
