Anyone playing with BLE on ESP32?

Simon H

unread,

Nov 25, 2020, 3:30:45 AM11/25/20

to TasmotaUsers

Hi All,

Great to see ESP32 coming along in Tasmota.

I have a couple of temp/humidity sensor (round one, like MJ_HT_V1 or CGG1 mentioned in the page:

https://tasmota.github.io/docs/Bluetooth/

I've build the firmware, and have it running, and returning temp and humidity!

Note that you must send command

SetOption115 1

to activate the MI32 driver xsns_62_MI_ESP32.ino

I do note that when you turn on this option, it disables xsns_52_ibeacon.ino in some way... I can't immediately see any direct link - it may just be a conflict in the use of BLE.

Is it advisable to turn off iBeacon functionality to use the MI functionality? Can you have both?

What I would really like is to add support for both reading and control of my BLE radiator valves (EQ3) to link up with:

https://github.com/btsimonh/node-red-contrib-eq3-bluetooth

(shell script version: https://github.com/btsimonh/eQ-3-radiator-thermostat)

My valves are dispersed around the house, and I don't want to put a linux box within range of each of them....

I had intended to build a BLE bridge from an ESP32 for this purpose, and as Tasmota is my favourite ESP firmware (and is adaptable fairly easily), and now has both prototype ESP32 support and BLE support, it seems like a good basis.

Any thoughts on a fairly raw bridge mode for read and control?

(there is 'MI32Option 2', which seems to enable posting of all raw data to MQTT, so someone is considering it?).

br,

Simon

Simon H

unread,

Nov 25, 2020, 3:43:39 AM11/25/20

to TasmotaUsers

I should have searched... this thread:

https://groups.google.com/g/sonoffusers/c/xZZYTuSQgqk/m/e1JCIJWsAAAJ

also highlights this repo

https://github.com/softypit/esp32_mqtt_eq3

However, a much more generic bridge implementation which could post raw commands would be more attractive, else the Tasmota code just gathers more and more very specific drivers....

s

YJB

unread,

Nov 25, 2020, 4:04:43 AM11/25/20

to TasmotaUsers

Hi,

I do agree that a more generic way would be preferable. (on a tasmota basis)

I've looked at several solutions and found https://github.com/softypit/esp32_mqtt_eq3 a pain, as the mqtt topic definitions are not very easy to handle. They require a lot of "translation" if you want to use them in home assistant.So if someone would write the mqtt handling it would be a good solution.

The solution that I'm currently using is zewelor/bt-mqtt-gateway. Its doing a pretty good job, but runs only on Linux. The good news is that a few Rapberry Pi zero's distributed around the house (3 in my case) are covering the entire house. And as a bonus I'm running roomassistenton on the same PI.

Ysbrand

Philip Knowles

unread,

Nov 25, 2020, 5:04:58 AM11/25/20

to Simon H, TasmotaUsers

I run softypit/esp32_mqtt_eq3: esp32-based mqtt node to control EQ-3 BLE TRVs (github.com)

for my EQ3 on ESP32 (1 upstairs 1 downstairs) and control using openHAB.

There is a conflict between BLE and iBeacon on the ESP32 and haven’t found any firmware which will run iBeacon and BLE at the same time. I use Tasmota for my MiFlora and OpenMQTTGateway for the beacons (can’t get Tasmota iBeacon to work for some reason).

Regards

Phil K

Sent from Mail for Windows 10

--
You received this message because you are subscribed to the Google Groups "TasmotaUsers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonoffusers...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/sonoffusers/0c884a35-4e8f-473c-b714-df2914582056n%40googlegroups.com.

Simon H

unread,

Dec 6, 2020, 1:56:17 PM12/6/20

to TasmotaUsers

Hi All,

ok, I have a PR in progress which enables generic BLE - i.e. you CAN have sensors and iBeacon at the same time.

the PR is here:

https://github.com/arendst/Tasmota/pull/10046

it also allows you to:

1/ see what devices have been seen. (240s timeout).

2/ get all the advertisments as MQTT from a single device (with service data and payload) - (if they can be sent to MQTT before the next one!).

3/ perform read, write, and get notification from devices. (it will do one 'operation' at a time, but you can queue a few to happen, and get tagged results via MQTT).

So, I'm now looking for testers and people who have BLE device they wish to talk to.

My devices are limited (to MJ_HT_V1 temp/hum, and EQ3 valves).

I certainly get temp/hum, and even have added 'pair button' sensing, for MJ_HT_V1, and can write values and get notifications from EQ3.

We really need more devices tested, and descriptions of real world requirements/use cases for generic BLE and Tasmota.

I am not intending to create an EQ3 driver inside Tasmota, although in actuality it would be fairly simple.

My preference for 'complex' BLE operations would be to bridge between the requirements and 'raw' read/write/notify using something like Node-Red.

best regards,

Simon

Simon H

unread,

Dec 6, 2020, 3:50:28 PM12/6/20

to TasmotaUsers

I have put instructions here:

https://docs.google.com/document/d/1PMaGJwhxtKDgruHc79bVby8Wx6kbHyKp6WM6AriXNMo/edit?usp=sharing

Simon H

unread,

Dec 14, 2020, 10:05:01 AM12/14/20

to TasmotaUsers

Hi Phil,

how flexible are you with the MQTT in terms of controlling esp32_mqtt_eq3 ?

here:

https://github.com/btsimonh/Tasmota/tree/xdrv_48_EQ3_ESP32

is a tamsota esp32 branch which has generic BLE, and on top of that the MI sensors AND EQ3.

in my_user_config, define

#define USE_MI_ESP32 // Add support for ESP32 as a BLE-bridge (+9k2 mem, +292k flash)

#define USE_BLE_ESP32 // Add support for ESP32 as a BLE-bridge (+9k2? mem, +292k? flash)

//#define USE_IBEACON // Add support for bluetooth LE passive scan of ibeacon devices (uses HM17 module)

//#define USE_IBEACON_ESP32

#define USE_EQ3_ESP32 // Add support for EQ3 TRV radiator valves - requires USE_BLE_ESP32

build & upload.

Go to Configuration/Configure BLE and enable it.

To identify your EQ3 devices, you will need to turn on Active scanning too - but you can turn this off once you have some valid MACs..

then the command

trv devlist - gives a list of EQ3s.

then e.g.

trv 001A22090837 reqprofile 0

trv 001A22092EE0 settemp 22

trv 001A22090837 on

trv 001A22092EE0 state

trv 00:1A:22:09:2E:E0 state - this for should also work.

Full command set:

trv reset

trv devlist

trv scan

trv <mac> state

trv <mac> raw <hex to send>

trv <mac> on

trv <mac> off

trv <mac> boost

trv <mac> unboost

trv <mac> lock

trv <mac> unlock

trv <mac> auto

trv <mac> manual

trv <mac> eco

trv <mac> day

trv <mac> night

trv <mac> settemp 20.5

trv <mac> settime - set to Tasmota timeout

trv <mac> settime <hex as per esp32_mqtt_eq3>

trv <mac> offset 1.5

trv <mac> setdaynight 22 17.5

trv <mac> setwindowtempdur 12 30

trv <mac> reqprofile <0-6>

trv <mac> setprofile <0-6> 20.5-07:30,17-17:00,22.5-22:00,17-24:00 (up to 7 temp-HH:MM)

Responses:

normal:

tele/tasmota_E89E98/EQ3 = {"trv":"00:1a:22:09:2e:e0","blestate":DONENOTIFIED,"raw":"02010900042C","temp":22.0,"posn":0,"mode":"manual","boost":"inactive","dst":"set","window":"closed","state":"unlocked","battery":"GOOD"}

holiday:

as above, but adds ,"holidayend":"YY-MM-DD HH:MM"

when trv <mac> reqprofile is used:

tele/tasmota_E89E98/EQ3 = {"trv":"00:1a:22:09:2e:e0","blestate":DONENOTIFIED,"raw":"02010900042C","profiledayN":"20.5-07:30,17.0-17:00,22.5-22:00,17.0-24:00"}

where N is the day (0-6).

when trv <mac> setprofile is used:

tele/tasmota_E89E98/EQ3 = {"trv":"00:1a:22:09:2e:e0","blestate":DONENOTIFIED,"raw":"02010900042C","profiledayset":N}

where N is the day (0-6).

on error:

tele/tasmota_E89E98/EQ3 = {"trv":"00:1a:22:09:2e:e0","blestate":"FAIL<xxxx>","retriesremain":<1-3>}

when retries exhausted:

tele/tasmota_E89E98/EQ3 = {"trv":"00:1a:22:09:2e:e0","blestate":"FAIL<xxxx>"}

If you think this is a useful addition to Tasmota, then please add some comments to the PR:

https://github.com/arendst/Tasmota/pull/10118

It's hot off the press, so if you do try it and find issues, let me know.

let me know what you think,

best regards,

Simon

p.s. what devices/aerials do you use? I just got a esp32cam module with +8dB external aerial, and it reports RSSI 20dB higher than my 'normal' module. I've yet to actually try to site it for best coverage...

On Wednesday, November 25, 2020 at 10:04:58 AM UTC knowles...@gmail.com wrote:

Ysbrand Bergman

unread,

Dec 14, 2020, 11:32:47 AM12/14/20

to Simon H, TasmotaUsers

Just wondering,

Will the TRV's then also be controlled through MQTT? I did try esp32_mqtt_eq3, but the mqtt approach is not very easy to translate in a home assistant context. Most of the esp32_mqtt_e3 command (and status messages) require multiple arguments with implies a lot of parsing:

/livingroomradin/trv <mac> on

/livingroomradin/trv <mac> settemp 20

etc

A more tasmota like style would have my preference:

cmnd/radiator_1/settemp "20"

stat/radiator_1/valve_state

-- returns 50 (%)

etc

Woudl that make sense?

Ysbrand

To view this discussion on the web, visit https://groups.google.com/d/msgid/sonoffusers/5f5c1e37-7bcd-441d-9a97-a0a5511fcfe0n%40googlegroups.com.

Philip Knowles

unread,

Dec 14, 2020, 12:01:32 PM12/14/20

to Simon H, TasmotaUsers

I’m using openHAB (and NodeRed to handle some MQTT issues from non-Tasmota firmware) so I’m quite happy to try options.

Will have a look over the next few days.

To view this discussion on the web, visit https://groups.google.com/d/msgid/sonoffusers/5f5c1e37-7bcd-441d-9a97-a0a5511fcfe0n%40googlegroups.com.

Simon H

unread,

Dec 14, 2020, 3:01:51 PM12/14/20

to TasmotaUsers

I am considering an 'alias' system in the generic BLE.

So basically, you'd be able to configure a set of aliases to BLE mac adresses.

so

i.e. you'd
/livingroomradin/trv <alias> on

now, if you could on Tasmota 'hear' other MQTT topics, it may be better?

any guidance welcome :).

p.s. pls register your interest in the generic BLE PR, else BLE just won't happen until a maintainer needs it.....

s

Simon H

unread,

Dec 14, 2020, 3:03:05 PM12/14/20

to TasmotaUsers

thanks Phil.

NR :).

s

p.s. pls register your interest in the generic BLE PR, else BLE just won't happen until a maintainer needs it.....

YJB

unread,

Dec 19, 2020, 2:31:33 AM12/19/20

to TasmotaUsers

Looks promising; I've build and uploaded the code to an ESP32 and I'm able to control my EQ3 TRV, looks pretty straightforward as long as I'm using the commandline.

Now I need to figure out an efficient way to use the standard climate components in HA, for example:

mode_command_topic:

temperature_state_topic:

temperature_state_template:

temperature_command_topic:

current_temperature_topic:

current_temperature_template:

away_mode_state_topic:

Probably need to use a template as HA more or less expects an unique topic for each option.

Not sure how the aliasing you are proposing would work, but that's probably my lack of knowledge.

Since this is using BLE, I expected that I could query the ATC sensors as well, and yes I see the sensor, but it's not giving any values:

SENSOR = {"Time":"2020-12-19T08:16:44","LYWSD03-2489f8":{"Temperature":null,"Humidity":null,"DewPoint":null,"Battery":null,"RSSI":-51},"BLE":{"scans":2873,"advertisments":1354694,"devices":8,"resets":0},"TempUnit":"C"}

Anyways, I know I'm on the bleeding edge, so time will tell.

Thanks for the effort!

Y.

Simon H

unread,

Dec 20, 2020, 8:01:32 AM12/20/20

to YJB, TasmotaUsers

fixed a typo in the LYWSD02/03 characteristic - pls pull the change
and report. I don't have all the sensors :(.

Yep, I don't run any of the 'standard' automation systems, so need
guidance on the best way to control the EQ3s.
I've heard of people using NodeRed to 'adapt' what automation systems
need vs what is needed on MQTT.

ref. alias, I was thinking more of being able to name BLE devices in
Tasmota. i.e. FRED=01a3432345 - and then being able to use 'FRED' in
place of a MAC address for ANY BLE interaction. just an idea really;
would not help in mapping to MQTT topics.
br,

S

> You received this message because you are subscribed to a topic in the Google Groups "TasmotaUsers" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/sonoffusers/1NtgBRCLybE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to sonoffusers...@googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/sonoffusers/856bf5c7-414e-41b8-af12-af5607c69708n%40googlegroups.com.

Ysbrand Bergman

unread,

Dec 20, 2020, 10:14:49 AM12/20/20

to Simon H, YJB, TasmotaUsers

Hi,

Thanks for this, unfortunately it didn't make a difference.

I've added a second sensor without the custom firmware, and it looks the same:

(From the home screen):

MI ESP32 v0917a 1-2 / 2

LYWSD03 MAC Address A4:C1:38:24:89:F8

LYWSD03 RSSI -37 dBm

LYWSD03 Pair Button Pressed

LYWSD03 MAC Address A4:C1:38:08:E3:B3

LYWSD03 RSSI -62 dBm

LYWSD03 Pair Button Pressed

I've verified the build date and I'm positive that I'm running the updated version.

Maybe I'm doing something wrong, not sure how I can debug this.

This is part of the console debuglog:

16:09:05 SL1-4 BLETask:Starting Ni

16:09:05 SL1-4 MI32Adv: svcdata[0]

16:09:06 SL1-4 MI32Adv: svcdata[0]

16:09:06 WIF: Checking connection...

16:09:07 SL1-4 MI32Adv: svcdata[0]

16:09:08 SL2-3 MI32Adv: svcdata[0]

16:09:08 SL1-4 MI32Adv: svcdata[0]

16:09:08 SL1-4 EQ3Device: saw 00:1

16:09:09 SL1-4 MI32Adv: svcdata[0]

16:09:09 SL2-3 MI32Adv: svcdata[0]

16:09:09 SL1-4 MI32Adv: svcdata[0]

16:09:10 SL1-4 MI32Adv: svcdata[0]

16:09:11 SL1-4 MI32Adv: svcdata[0]

16:09:12 SL1-4 MI32Adv: svcdata[0]

16:09:13 SL1-4 MI32Adv: svcdata[0]

16:09:14 SL5-0 MI32Adv: svcdata[0]

16:09:14 SL4-1 MI32: will test ID-

16:09:14 SL3-2 MI32: ID is type 3

16:09:14 SL2-3 SafeAddLog_P overfloxV��?4 ��

16:09:14 SL1-4 SafeAddLog_P overfloxV��?4 ��

16:09:15 SL1-4 MI32Adv: svcdata[0]

16:09:15 SL1-4 EQ3Device: saw 00:1

16:09:15 SL1-4 MI32Adv: svcdata[0]

16:09:16 SL1-4 MI32Adv: svcdata[0]

16:09:16 SL0-4 MI32Adv: svcdata[0]

16:09:16 SL4-1 MI32: will test ID-

16:09:16 SL3-2 MI32: ID is type 3

16:09:16 SL2-3 SafeAddLog_P overfloxV��?4 ��

16:09:16 SL1-4 SafeAddLog_P overfloxV��?4 ��

16:09:16 SL1-4 MI32Adv: svcdata[0]

16:09:17 SL1-4 MI32Adv: svcdata[0]

16:09:18 SL5-0 MI32Adv: svcdata[0]

16:09:18 SL4-1 MI32: will test ID-

16:09:18 SL3-2 MI32: ID is type 3

16:09:18 SL2-3 SafeAddLog_P overfloxV��?4 ��

16:09:18 SL1-4 SafeAddLog_P overfloxV��?4 ��

16:09:18 SL1-4 MI32Adv: svcdata[0]

16:09:19 SL1-4 MI32Adv: svcdata[0]

16:09:19 SL5-0 MI32Adv: svcdata[0]

16:09:19 SL4-1 MI32: will test ID-

16:09:19 SL3-2 MI32: ID is type 3

16:09:19 SL2-3 SafeAddLog_P overfloxV��?4 ��

16:09:19 SL1-4 SafeAddLog_P overfloxV��?4 ��

16:09:20 SL1-4 MI32Adv: svcdata[0]

16:09:21 SL1-4 MI32Adv: svcdata[0]

16:09:22 SL1-4 MI32Adv: svcdata[0]

16:09:22 SL2-3 MI32Adv: svcdata[0]

16:09:22 SL1-4 EQ3Device: saw 00:1

16:09:22 SL1-4 MI32Adv: svcdata[0]

16:09:23 SL1-4 MI32Adv: svcdata[0]

16:09:23 MQT: tele/ESP32-1/STATE = {"Time":"2020-12-20T16:09:23","Uptime":"0T00:30:39","UptimeSec":1839,"Heap":89,"SleepMode":"Normal","Sleep":50,"LoadAvg":24,"MqttCount":5,"Wifi":{"AP":1,"SSId":"YBROUTER-2G","BSSId":"10:0C:6B:4C:0E:ED","Channel":1,"RSSI":100,"Signal":-48,"LinkCount":1,"Downtime":"0T00:00:05"}}

16:09:24 MQT: tele/ESP32-1/SENSOR = {"Time":"2020-12-20T16:09:24","LYWSD03-2489f8":{"Temperature":null,"Humidity":null,"DewPoint":null,"Battery":null,"RSSI":-40},"LYWSD03-08e3b3":{"Temperature":null,"Humidity":null,"DewPoint":null,"Battery":null,"RSSI":-62},"BLE":{"scans":60,"advertisments":18965,"devices":12,"resets":0},"TempUnit":"C"}

16:09:24 SL1-4 MI32Adv: svcdata[0]

16:09:25 SL1-4 MI32Adv: svcdata[0]

16:09:26 SL1-4 MI32: scancomplete

16:09:26 MQT: tele/ESP32-1/BLE = {"active":{"total":10,"B03829B0C9BE":{"i":0,"n":"HB-00040949","r":-60},"52525252CE0F":{"i":1,"n":"","r":-81},"7C0FC6831026":{"i":2,"n":"98E7829E87563395E9","r":-57},"54545442DE74":{"i":3,"n":"","r":-59},"4D0D0D4D5DC4":{"i":4,"n":"","r":-75},"001A2216A458":{"i":5,"n":"CC-RT-BLE","r":-70},"A4C1382489F8":{"i":6,"n":"ATC_2489F8","r":-40},"A4C13808E3B3":{"i":7,"n":"LYWSD03MMC","r":-52},"32B16E93A4DB":{"i":8,"n":"","r":-80},"36DA1C5F1180":{"i":9,"n":"","r":-95}}}

16:09:26 SL1-4 MI32Adv: svcdata[0]

16:09:26 SL1-4 EQ3Device: saw 00:1

16:09:26 SL1-4 MI32Adv: svcdata[0]

16:09:27 WIF: Checking connection...

16:09:27 SL1-4 MI32Adv: svcdata[0]

16:09:28 SL1-4 MI32Adv: svcdata[0]

16:09:29 SL1-4 MI32Adv: svcdata[0]

16:09:30 SL4-1 MI32Adv: svcdata[0]

16:09:30 SL3-2 MI32Adv: svcdata[0]

16:09:30 SL2-3 EQ3Device: saw 00:1

16:09:30 SL1-4 SafeAddLog_P overfloxV��?4 ��

16:09:31 SL1-4 MI32Adv: svcdata[0]

16:09:32 SL1-4 MI32Adv: svcdata[0]

16:09:32 SL1-4 EQ3Device: saw 00:1

16:09:33 SL5-0 MI32Adv: svcdata[0]

16:09:33 SL4-1 MI32: will test ID-

16:09:33 SL3-2 MI32: ID is type 3

16:09:33 SL2-3 SafeAddLog_P overfloxV��?4 ��

16:09:33 SL1-4 SafeAddLog_P overfloxV��?��?

16:09:33 SL1-4 MI32Adv: svcdata[0]

16:09:33 SL1-4 EQ3Device: saw 00:1

16:09:33 SL1-4 MI32Adv: svcdata[0]

16:09:34 SL1-4 MI32Adv: svcdata[0]

16:09:35 SL1-4 MI32Adv: svcdata[0]

16:09:36 SL2-3 MI32Adv: svcdata[0]

16:09:36 SL1-4 MI32Adv: svcdata[0]

16:09:36 SL5-0 MI32Adv: svcdata[0]

16:09:36 SL4-1 MI32: will test ID-

16:09:36 SL3-2 MI32: ID is type 3

16:09:36 SL2-3 SafeAddLog_P overfloxV��?4 ��

16:09:36 SL1-4 SafeAddLog_P overfloxV��?��?

16:09:37 SL1-4 MI32Adv: svcdata[0]

16:09:38 SL1-4 MI32Adv: svcdata[0]

16:09:38 SL2-3 MI32Adv: svcdata[0]

16:09:38 SL1-4 MI32Adv: svcdata[0]

16:09:39 SL1-4 MI32Adv: svcdata[0]

16:09:39 SL2-3 MI32Adv: svcdata[0]

16:09:39 SL1-4 MI32Adv: svcdata[0]

16:09:40 SL1-4 MI32Adv: svcdata[0]

16:09:40 SL5-0 MI32Adv: svcdata[0]

16:09:40 SL4-1 MI32: will test ID-

16:09:40 SL3-2 MI32: ID is type 3

16:09:40 SL2-3 SafeAddLog_P overfloxV��?��?

16:09:40 SL1-4 SafeAddLog_P overfloxV��?4 ��

16:09:41 SL1-4 MI32Adv: svcdata[0]

16:09:42 SL1-4 MI32Adv: svcdata[0]

16:09:42 SL1-4 EQ3Device: saw 00:1

16:09:42 SL1-4 MI32Adv: svcdata[0]

16:09:43 SL1-4 MI32Adv: svcdata[0]

16:09:43 SL2-3 MI32Adv: svcdata[0]

16:09:43 SL1-4 MI32Adv: svcdata[0]

16:09:43 SL2-3 MI32Adv: svcdata[0]

16:09:43 SL1-4 MI32Adv: svcdata[0]

16:09:44 SL1-4 MI32Adv: svcdata[0]

16:09:45 SL1-4 MI32Adv: svcdata[0]

16:09:45 SL1-4 EQ3Device: saw 00:1

16:09:45 SL1-4 MI32: scancomplete

16:09:46 MQT: tele/ESP32-1/BLE = {"active":{"total":9,"B03829B0C9BE":{"i":0,"n":"HB-00040949","r":-53},"52525252CE0F":{"i":1,"n":"","r":-93},"7C0FC6831026":{"i":2,"n":"98E7829E87563395E9","r":-47},"54545442DE74":{"i":3,"n":"","r":-59},"4D0D0D4D5DC4":{"i":4,"n":"","r":-75},"001A2216A458":{"i":5,"n":"CC-RT-BLE","r":-70},"A4C1382489F8":{"i":6,"n":"ATC_2489F8","r":-37},"A4C13808E3B3":{"i":7,"n":"LYWSD03MMC","r":-51},"32B16E93A4DB":{"i":8,"n":"","r":-84}}}

16:09:47 SL1-4 MI32Adv: svcdata[0]

16:09:47 WIF: Checking connection...

16:09:48 SL1-4 MI32Adv: svcdata[0]

16:09:49 SL1-4 EQ3Device: saw 00:1

16:09:50 SL1-4 MI32Adv: svcdata[0]

16:09:51 SL1-4 MI32Adv: svcdata[0]

Simon H

unread,

Dec 20, 2020, 11:19:11 AM12/20/20

to TasmotaUsers

I just pushed a new version - related to EQ3 and MQTT, not to the sensors.

Now you can us the topics:

cmnd/Tasmota_blassblaa/EQ3/<mac>/<cmd>: data

and

cmnd/Tasmota_blassblaa/EQ3/<mac>: cmd <data>

e.g.

topic:cmnd/tasmota_esp32/EQ3/001A22092C9A/settemp

payload: 21

topic:cmnd/tasmota_esp32/EQ3/001A22092C9A

payload: settemp 21

BUT - commands take some time (especially with timeouts)... so if you send too quickly, they won't work.

If one is in progress, you won't get anything back from the 'direct' mqtt request.

If one is NOT in progress, you will get responses on tele/Tasmota_blassblaa/EQ3

so, I got the topics as you need them? pls confirm.

But not yet perfect.

And can HA even wait for a response? or do commands have to be queued?

s

(i'll have a look at when it polls for data from the LYWSD03 - maybe it does not ask often ? - so see if the values appear in 20 mins...)

Simon H

unread,

Dec 20, 2020, 11:48:04 AM12/20/20

to TasmotaUsers

@YJB - please pull now and test sensors again.

Lots of debug at level DEBUG.

I was never reading sensors which required connection. Now am.

However, it will only kick a read every 'period'.

You can set the period using 'MI32period 40', for example. (kick a read every 40s, rather than default 300).

pls. confirm.

s

YJB

unread,

Dec 20, 2020, 2:55:37 PM12/20/20

to TasmotaUsers

Not sure if we should split this topic in a BLE sensors and a BLE EQ3 topic?

Anyways, changing the MQTT topics for EQ3 really, really helped. I can confirm that these are working and I do not think that the retries is causing any issues. Keep in mind that MQTT is basically asynchronous; you send a command and at some point you will get a status. If we take the design very serious (not saying that we should) the we need to go along the following

stat - reports back status or configuration message
tele - reports telemetry info at specified intervals

So tele will repeat a status on a regular for all sensors/devices controlled by tasmota and stat will be the response to a command. But then, I see quite a few deviations from this, so sending "tele" messages as a response should work as well.

The command structure could be simplified, nit sure what is more effective from a coding perspective:

state (no options, we could ask for a specific component state, but parsing the payload should work)

boost/unboost -->> boost <0/1>

lock/unlock -->> lock <0/1>

auto/manual/day/night -->> mode <manual/auto/day/night>

on/off -->> valve <1/0> or <open/closed>

The other commands are probably less important as they are more like one time commands, but then, maybe someone else has an opinion on this.

One thing that I noticed is that the mac address is always reversed on the second retry, not sure if that is just a reporting issue:

{"trv":"00:1a:22:16:a4:58","blestate":"FAILCONNECT","retriesremain":3}

{"BLEOperation":{"opid":"1","stat":"-11","state":"FAILCONNECT","MAC":"001A2216A458","svc":"3e135142-654f-9090-134a-a6ff5bb77046","char":"3fa4585a-ce4a-3bad-db4b-b8df8179ea09","notifychar":"d0e8434d-cd29-0996-af41-6c90f4e0eb2a","write":"412D"}}

{"trv":"58:a4:16:22:1a:00","blestate":"FAILCONNECT","retriesremain":2}

{"BLEOperation":{"opid":"2","stat":"-11","state":"FAILCONNECT","MAC":"58A416221A00","svc":"3e135142-654f-9090-134a-a6ff5bb77046","char":"3fa4585a-ce4a-3bad-db4b-b8df8179ea09","notifychar":"d0e8434d-cd29-0996-af41-6c90f4e0eb2a","write":"412D"}}

{"trv":"00:1a:22:16:a4:58","blestate":"FAILCONNECT","retriesremain":1}

{"BLEOperation":{"opid":"3","stat":"-11","state":"FAILCONNECT","MAC":"001A2216A458","svc":"3e135142-654f-9090-134a-a6ff5bb77046","char":"3fa4585a-ce4a-3bad-db4b-b8df8179ea09","notifychar":"d0e8434d-cd29-0996-af41-6c90f4e0eb2a","write":"412D"}}

There is probably more, but I feel there is goog progress on the EQ3 implementation!!

YB

YJB

unread,

Dec 20, 2020, 3:04:39 PM12/20/20

to TasmotaUsers

One thing I forgot to add, shouldn't the response topic not contain the mac of the TRV in the same manner as the cmnd?

Now it is (I guess a single topic for all trv's (I'm testing with only one)):

tele/ESP32-1/EQ3

What about:

tele/ESP32-1/EQ3/001A2216A458

YB

Simon H

unread,

Dec 21, 2020, 3:54:02 AM12/21/20

to TasmotaUsers

Hi YB,

exactly the kind of feedback that's useful :).

on the commands, the original (still in place) cmnd/Tas/TRV [<MAC> cmd param1 param2] was blatantly stolen from an existing EQ3 MQTT implementation.

So.. I'll leave them as they are, but ADD interpretation of param1 for if it exists for

boost <0/1>

lock <0/1>

mode <manual/auto/day/night>

valve <1/0> or <open/closed>

hence retaining compatibility for those who have already adapted to that implementation.

ref state (no options, we could ask for a specific component state, but parsing the payload should work)

I don't keep the result, would not want to encourage someone to to ask for each individual thing causing 6 connections rather than the one :).

tele->stat - can do.

It does not retain any info, so does not generate a regular tele message..... unless you think it may be useful to have stats on overall success/failure/retries.

"the mac address is always reversed on the second retry, " - great spot. NimBLE and address reversal - bahh!!! could point to an underlying issue in my BLE implementation. thankyou.

ref

"tele/ESP32-1/EQ3

What about:

tele/ESP32-1/EQ3/001A2216A458"

I've tried to keep actual responses as JSON, so it makes little difference?

did you see any temperatures from your sensors after >300s?

br,

Simon

Changes:

mac reversal fixed?

Added (in addition to existing functionality)

boost off|0 - param missing or not off/0 -> on

lock off|0 - param missing or not off/0 -> on

valve off|0|on|1 (note I only look for off|0 - anything else==on)

mode auto|manual|eco (default to auto if param not recognised)

Did NOT change day/night - not quite sure EXACTLY what these do, but they are not a mode command?

MQTT commands now responded to like:

09:47:28 MQT: stat/tasmota_esp32/EQ3/001A22092C9A = {"result":"queued"}

results posted like:

09:47:31 MQT: stat/tasmota_esp32/EQ3/001A22092C9A = {"trv":"00:1a:22:09:2c:9a","blestate":"FAILCONNECT","retriesremain":3}

09:47:39 MQT: stat/tasmota_esp32/EQ3/001A22092C9A = {"trv":"00:1a:22:09:2c:9a","blestate":"DONENOTIFIED","raw":"02010900042A","temp":21.0,"posn":0,"mode":"manual","boost":"inactive","dst":"set","window":"closed","state":"unlocked","battery":"GOOD"}

Ysbrand Bergman

unread,

Dec 21, 2020, 4:12:13 AM12/21/20

to Simon H, TasmotaUsers

Thanks Simon for this,

Will look at this again later today.

No, the sensor values are still not received.

Not sure if this is related to more logging, but the ESP32 now reboots on a regular basis (since yesterdays code I believe. When I disable bluetooth, it will stay up and running.

Also, the loadavg goes up over time (also with bluetooth enabled, but slower increase), so maybe we're running somewhere in a loop?

YB

To view this discussion on the web, visit https://groups.google.com/d/msgid/sonoffusers/f8997353-e13c-4dcc-9ce8-a427fe28535bn%40googlegroups.com.

Simon H

unread,

Dec 21, 2020, 4:15:44 AM12/21/20

to TasmotaUsers

if you have a serial log of the reboot..... it may be that it's torching in the sensor read (I've not got one that it can read like that).

"loadavg" - how do I see this?

Ysbrand Bergman

unread,

Dec 21, 2020, 4:25:14 AM12/21/20

to Simon H, TasmotaUsers

Hi Simon,

Let me see if I can capture some serial log as well.

Loadavg is reported by the regular tele messages (default every 300 seconds):

Dec 20 21:42:06 ESP32-1-5100 ESP-MQT: tele/ESP32-1/STATE = {"Time":"2020-12-20T21:42:06","Uptime":"0T00:00:13","UptimeSec":13,"Heap":84,"SleepMode":"Normal","Sleep":50,"LoadAvg":97,"MqttCount":1,"Wifi":{"AP":1,"SSId":"YBROUTER-2G","BSSId":"10:0C:6B:4C:11:A8","Channel":1,"RSSI":44,"Signal":-78,"LinkCount":1,"Downtime":"0T00:00:05"}}

Dec 20 21:47:23 ESP32-1-5100 ESP-MQT: tele/ESP32-1/STATE = {"Time":"2020-12-20T21:47:23","Uptime":"0T00:00:14","UptimeSec":14,"Heap":95,"SleepMode":"Normal","Sleep":50,"LoadAvg":55,"MqttCount":1,"Wifi":{"AP":1,"SSId":"YBROUTER-2G","BSSId":"10:0C:6B:4C:11:A8","Channel":1,"RSSI":46,"Signal":-77,"LinkCount":1,"Downtime":"0T00:00:05"}}

Dec 20 21:57:40 ESP32-1-5100 ESP-MQT: tele/ESP32-1/STATE = {"Time":"2020-12-20T21:57:39","Uptime":"0T00:00:17","UptimeSec":17,"Heap":95,"SleepMode":"Normal","Sleep":50,"LoadAvg":23,"MqttCount":1,"Wifi":{"AP":1,"SSId":"YBROUTER-2G","BSSId":"10:0C:6B:4C:0E:ED","Channel":1,"RSSI":98,"Signal":-51,"LinkCount":1,"Downtime":"0T00:00:09"}}

Dec 20 22:03:05 ESP32-1-5100 ESP-MQT: tele/ESP32-1/STATE = {"Time":"2020-12-20T22:03:05","Uptime":"0T00:00:33","UptimeSec":33,"Heap":62,"SleepMode":"Normal","Sleep":50,"LoadAvg":30,"MqttCount":1,"Wifi":{"AP":1,"SSId":"YBROUTER-2G","BSSId":"10:0C:6B:4C:0E:ED","Channel":1,"RSSI":100,"Signal":-49,"LinkCount":1,"Downtime":"0T00:00:23"}}

I've seen it going up to 1000+ on this ESP32 while on all my other Tasmota devices it is normally around 19, on some Tuya dimmers 50-60

To view this discussion on the web, visit https://groups.google.com/d/msgid/sonoffusers/0592b654-4777-41c5-be6a-a4c6cbda8c0en%40googlegroups.com.

Simon H

unread,

Dec 21, 2020, 6:05:56 AM12/21/20

to TasmotaUsers

ok, i've made some 'adjustments' in base level BLE around starting and stopping the task. I definitely saw two consecutive

12:00:41 SL1-4 MI32: scancomplete

messages, which cannot happen, so indicates something bad...

My loadavg is a pretty consistent 19 - so I think your high one may be an indicator that it was managing to run a task twice in some way.

ref the crash, if you "MI32Period 20" - it would kick a 'read start' on your sensors every 20s, rather than the default 300s.

I do wonder if I can read info from my MJ_HT_V1 to at least exercise the same code your sensor needs...

s

Simon H

unread,

Dec 21, 2020, 7:32:50 AM12/21/20

to TasmotaUsers

and more adjustments in BLE regarding start/stop of scanning.

I have left a lot of logging in there, will be interesting to see logs of action after:

13:09:46 kick off readOneSensor

br,

simon

Ysbrand Bergman

unread,

Dec 21, 2020, 1:09:01 PM12/21/20

to TasmotaUsers

Hi Simon,

I did compile the new version and let it run for some while, captured the restart:

18:54:19 BLE:scans:7,advertisments:2676,devices:14,resets:0,BLEStop:0,BLERunning:1,BLERunningScan:2,BLELoopCount:142,BLEOpCount:1

lld_pdu_get_tx_flush_nb HCI packet count mismatch (1, 2)

18:54:20 BLE:scans:7,advertisments:2676,devices:14,resets:0,BLEStop:0,BLERunning:1,BLERunningScan:2,BLELoopCount:142,BLEOpCount:1

18:54:21 SL1-24 BLETask: op failed -11

18:54:21 BLE:scans:7,advertisments:2676,devices:14,resets:0,BLEStop:0,BLERunning:1,BLERunningScan:0,BLELoopCount:143,BLEOpCount:1

18:54:21 operation failed fffffff5

18:54:21 some to show

18:54:21 completed 1

18:54:21 MQT: tele/tasmota_DF33EC/BLE = {"BLEOperation":{"opid":"0","stat":"-11","state":"FAILCONNECT","MAC":"A4C1382489F8","u":"84148224"}}

18:54:22 BLE:scans:7,advertisments:2676,devices:14,resets:0,BLEStop:0,BLERunning:1,BLERunningScan:0,BLELoopCount:144,BLEOpCount:2

18:54:23 BLE:scans:7,advertisments:2676,devices:14,resets:0,BLEStop:0,BLERunning:1,BLERunningScan:0,BLELoopCount:144,BLEOpCount:2

18:54:24 BLE:scans:7,advertisments:2676,devices:14,resets:0,BLEStop:0,BLERunning:1,BLERunningScan:0,BLELoopCount:144,BLEOpCount:2

Guru Meditation Error: Core 1 panic'ed (LoadProhibited). Exception was unhandled.

Core 1 register dump:

PC : 0x401290a7 PS : 0x00060530 A0 : 0x80121416 A1 : 0x3ffe0aa0

A2 : 0x00000000 A3 : 0x3ffc7a1c A4 : 0x00060520 A5 : 0x3f429948

A6 : 0x00000002 A7 : 0x3ffe09a4 A8 : 0x80120e52 A9 : 0x3ffe0a90

A10 : 0x3ffc7a10 A11 : 0x00000000 A12 : 0x00000038 A13 : 0x3ffc7a48

A14 : 0x00000002 A15 : 0x00000003 SAR : 0x00000010 EXCCAUSE: 0x0000001c

EXCVADDR: 0x00000000 LBEG : 0x4000c46c LEND : 0x4000c477 LCOUNT : 0x00000000

ELF file SHA256: 0000000000000000

Backtrace: 0x401290a7:0x3ffe0aa0 0x40121413:0x3ffe0ac0 0x4011af10:0x3ffe0b20 0x4011af71:0x3ffe0b50 0x400ef88e:0x3ffe0b90 0x4009177a:0x3ffe0be0

Rebooting...

ets Jun 8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)

configsip: 0, SPIWP:0xee

clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00

mode:DOUT, clock div:2

load:0x3fff0018,len:4

load:0x3fff001c,len:1044

load:0x40078000,len:8896

load:0x40080400,len:5828

entry 0x400806ac

00:00:00 CFG: Loaded, Count 14

00:00:00 QPC: Count 1

00:00:00 Project tasmota Tasmota Version 9.1.0.2(sensors)-1_0_4_2(2020-12-21T17:29:32)

00:00:00 BLE: registerForAdvertismentCallbacks EQ3:400e7214

00:00:00 EQ3: init: request callbacks

00:00:00 BLE: registerForAdvertismentCallbacks MI32:400f7434

00:00:00 BLE: registerForScnCallbacks MI32:400e6ee0

00:00:00 MI32: init: request callbacks

Brownout detector was triggered

ets Jun 8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)

configsip: 0, SPIWP:0xee

clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00

mode:DOUT, clock div:2

load:0x3fff0018,len:4

load:0x3fff001c,len:1044

load:0x40078000,len:8896

load:0x40080400,len:5828

entry 0x400806ac

00:00:00 CFG: Loaded, Count 14

00:00:00 FRC: Some settings have been reset (2)

00:00:00 Project tasmota Tasmota Version 9.1.0.2(sensors)-1_0_4_2(2020-12-21T17:29:32)

I will send you the log in a separate email,

YB

To view this discussion on the web, visit https://groups.google.com/d/msgid/sonoffusers/4710f7c0-7281-4971-85cd-2f60044ad745n%40googlegroups.com.

Philip Knowles

unread,

Jan 13, 2021, 12:26:32 PM1/13/21

to Simon H, TasmotaUsers

Hi Simon, I’ve been running the ESP32 and it’s seeing both the MiFlora and my nut BLE beacons.

However, if the beacon moves out of range for over 100 minutes (6000+ count) the ESP32 stops monitoring the beacons and I have to resend the beacon rules. If this is an issue perhaps sending the timestamp when the beacon was last seen may be better.

Regards

Phil K

Sent from Mail for Windows 10

From: 'Simon H' via TasmotaUsers
Sent: 21 December 2020 12:32
To: TasmotaUsers
Subject: Re: Anyone playing with BLE on ESP32?

and more adjustments in BLE regarding start/stop of scanning.

To view this discussion on the web, visit https://groups.google.com/d/msgid/sonoffusers/4710f7c0-7281-4971-85cd-2f60044ad745n%40googlegroups.com.

Reply all

Reply to author

Forward