How to reconnect to adjust config?

[andreaskoerber]

I seem not to be able to reconnect and open the config (e.g. for adjusting an offset) after having successfully flashed and used one of these. The flasher does connect, but just gives:
07:41:58: Searching for devices
07:42:01: Connecting to: ATC
07:42:01: Detected custom Firmware
07:42:01: Detected alternative Firmware? Use: https://pvvx.github.io/ATC_MiThermometer/TelinkOTA.html
07:43:13: Settings 55 was send successful

Using the OTA flasher, I can also connect, but still cannot enter the config. The OTA-flasher misses the button for "Get config".

Is there a wa to re-connect for adjusting w/o to re-flash?

Thx in advance

[pvvx]

Settings for thermometers only work with firmware from this repository.
The settings menu opens automatically for known thermometer models and some sensors.
Thermometers with proprietary firmware are not serviced.
To configure the ATC1441 firmware, use the TelinkMiFlasher.htm from ATC1441

[andreaskoerber]

Thanks!

@atc1441 is referring to the re-worked flasher by @pvvx on the very same site you referred to,
I flashed the ATC_v38.bin from there.
I CAN open and save settings by it, after only after flashing it new, not based on an already installed.
My problem ist how to re-open the config w/o re-flashing.
Yours

[andreaskoerber]

... However: @pvvx seems to have updated their flasher recently - it looks like it supports much more variants of the sensors. BUT. I can now connect w/o re-flashing, but the transmission of new settings into the sensor does not seem to work ...

[NerdyProjects]

Same problem: Chrome on linux with lenovo t480 bluetooth does not work - the service is not discovered. Chrome on android worked immediately.

Any amount of reconnects did not help, battery is full, short circuit current 400 mA. I did not solder capacitors yet, but as it worked on android, I blame my bluetooth adapter...

[NerdyProjects]

I "fixed" this by patching the devIdEnabled = true; in line 1320. Everything else works flawlessly on the computer.

[kviktor]

I'm having the same issue, I was using https://github.com/pvvx/ATC_MiThermometer/raw/master/ATC_v39.bin to update the firmware, at https://pvvx.github.io/ATC_MiThermometer/TelinkMiFlasher.html I see no config options on desktop (t490s laptop) but connecting via my Android phone I see the possible config options.

[pvvx]

For the test, I use a desktop computer and BT to USB plug-in adapters. Of the various USB-BT adapters available (Intel, Realtek, CSR, ...) all work. Of the cheap BT adapters, the old BT4.0 version with the CSR8510 chip works best with Windows (Windows automatic install drivers). Has USB2.0 HiSpeed but does not support BT5+.
With Linux, this adapter receives the most BLE advertisements from all my dozens of devices...
Other low cost adapters that have USB2.0 FullSpeed lose a lot of packets. From this, it takes a very long time and badly to connect to BLE devices with a large advertising interval.

[oiesauvage]

@NerdyProjects I tried your suggestion devIdEnabled = true; arround line 1320 of the webapp pvvx.github.io-master/ATC_MiThermometer/TelinkOTA.html (in local) and I confirm it works (no idea why however).
Chromium on Linux, for flashing a LYWSD03MMC, no config options where visible after flashing before the fix.
However I still can't see any temperature graph, and a change of advertising interval made my devices inaccessible again.

This issue seems a duplicate of #242

[pvvx]

change of advertising interval made my devices inaccessible again.

If the interval is set to more than 4+ seconds, not all adapters and OS versions will be able to connect.

[matthijskooijman]

I'm also seeing the same problem on Linux (Ubuntu 22.04), I used https://pvvx.github.io/ATC_MiThermometer/TelinkMiFlasher.html to flash ATC_v39.bin (suggested by the webpage) onto my LYWSD03MMC module, and using that same page to connect and do "get config", I see the same messages as the original post (though sometimes it needs a couple of tries to succesfully connect as well). In particular, it says "Detected alternative Firmware?", but I do not think I uploaded an alternative firmware (though I am quite new and confused).

@NerdyProjects I tried your suggestion devIdEnabled = true; arround line 1320 of the webapp pvvx.github.io-master/ATC_MiThermometer/TelinkOTA.html (in local) and I confirm it works (no idea why however).

This confused me, because TelinkOTA.html only has 300-ish lines. However, https://pvvx.github.io/ATC_MiThermometer/TelinkMiFlasher.html does have the line mentioned (at line 1329). Making the change there indeed shows me config options directly after connecting (no need to press get config):

No luck with BTHome in Home Assistent yet, but at least this seems to work around the problem reported in this issue.

For a proper solution, I suspect this block of code should be modified somehow, to automatically set devIdEnabled (or maybe not set customEnabled) based on the uuids detected:

                for (var i = 0; i < services.length; i++) {
                        addClog("Services: " + services[i].uuid);
                        if (services[i].uuid == "00010203-0405-0607-0809-0a0b0c0d1912") otaEnabled = true;
                        else if (services[i].uuid == "22210000-554a-4546-5542-46534450464d") EnabledQinping = true;
                        else if (services[i].uuid == "ebe0ccb0-7a0a-4b0c-8a1a-6ff2997da3a6") miEnabled = true;
                        else if (services[i].uuid == "00001f10-0000-1000-8000-00805f9b34fb") customEnabled = true;
                        else if (services[i].uuid == "0000181a-0000-1000-8000-00805f9b34fb") devIdEnabled = true;
                        else if (services[i].uuid == "0000ffe0-0000-1000-8000-00805f9b34fb") devTest = true;
                        else if (services[i].uuid == "0000180a-0000-1000-8000-00805f9b34fb") devInfEnabled = true; // Device Information Service
                }

Looking in the browser console, these are the uuids detected:

Services: 00010203-0405-0607-0809-0a0b0c0d1912
Services: 00001f10-0000-1000-8000-00805f9b34fb
Services: 0000180a-0000-1000-8000-00805f9b34fb

I wanted to link to the github version of these HTML files, but I couldn't find them in the repository anywhere...

[netixx]

I had a similar issue, I couldn't get to the settings after flashing.

The "Get Config" button was only getting me these logs:

8:56:20 AM: Searching for devices
8:56:33 AM: Connecting to: ATC_5136A1
8:56:38 AM: Hardware Revision String: B1.6
8:56:38 AM: Detected custom Firmware
8:56:38 AM: Detected alternative Firmware? Use: https://pvvx.github.io/ATC_MiThermometer/TelinkOTA.html
8:56:48 AM: Settings 55 was send successful
8:57:12 AM: Disconnected.

I edited the doConnect function around line 1329 to set devIdEnabled=true and pasted it back in the console.

I could then see the settings immediately after connect.

9:04:10 AM: Searching for devices
9:04:19 AM: Connecting to: ATC_362550
9:04:23 AM: Hardware Revision String: B1.6
9:04:23 AM: Detected custom Firmware
9:04:23 AM: Hardware Version: LYWSD03MMC B1.6, Software Version: 4.0, Sensor: SHT4x
9:04:23 AM: Custom config HEX string: 55852000002804a97c3104b4000000
9:04:37 AM: Disconnected.

[pvvx]

This is most likely not a Linux issue.
Without capacitance, the SoC supply voltage drops strongly and sharply during transmission, which disrupts the operation of the microcircuit.

For reliable connection and refirmware on LYWSD03MMC, the battery level must be more than 40%. This is a design feature - a cheaper version of the hardware from Xiaomi:

.

On devices with missing power capacities, do not set 'Connect latency' to more than 1000 ms!

Shown how the first request-response after the connection worked, but then it fails and multiple attempts to re-establish the connection, ending with a timeout disconnect.
The reason is that Xiaomi did not put the recommended capacitors on the board and the voltage from the CR2032 jumps more than 20% on a still incompletely discharged battery.
If you install a capacitor of a few microfarads, then these phenomena disappear and the stability of work increases many times over, and the battery life also increases by at least 20%.

Software fix is not possible. To slightly increase the stability of the connection is obtained by reducing the interval (connect latency). In version 4.1, this value is now limited, which leads to some increase in connection consumption.
But such a solution is better than breaking the connection with frequent "retransmitions", which causes even more consumption...

[NerdyProjects]

I had the "config missing" problem also with devices that had the capacitor (have some devices with 47uf and some with 100uf) added. My fix, and that is what I have to use, is to add the mentioned line, so this is definitively an issue with my bluetooth chipset or something.

[matthijskooijman]

I'm pretty sure that this issue (edit: the issue as I have observed it at least) is a software issue in the HTML file, not a hardware issue (but maybe the capacitor issue mentioned has the same symptoms, that could very well be). IIRC, while investigating it earlier, I saw some signs that there have been changes to the HTML to refactor the affected code, so that probably broke things for specific devices (end devices, not bluetooth controllers) - though I can't quite recall where I saw this, since I think I could not find the git repository that contains the HTML file...

[pvvx]

To display files as from the web in github used "user.github.io"
https://github.com/pvvx/pvvx.github.io/tree/master/ATC_MiThermometer

Looking in the browser console, these are the uuids detected:

Services: 00010203-0405-0607-0809-0a0b0c0d1912
Services: 00001f10-0000-1000-8000-00805f9b34fb
Services: 0000180a-0000-1000-8000-00805f9b34fb

The js code is primitive, and the Chrome API does not display the full service UUID table for your device.

[pvvx]

The "Get Config" button was only getting me these logs:

8:56:48 AM: Settings 55 was send successful
8:57:12 AM: Disconnected.

I edited the doConnect function around line 1329 to set devIdEnabled=true and pasted it back in the console.

I could then see the settings immediately after connect.

9:04:23 AM: Custom config HEX string: 55852000002804a97c3104b4000000
9:04:37 AM: Disconnected.

If there is a connection break, then this means that the connection timings have gone astray.
Very often this occurs due to the instability of the supply voltage.
According to your log, it can be seen that the sequence of commands is interrupted. And after a "connection timeout" of 10 seconds, the connection is closed.
Reducing connection intervals partially solves this problem. As described above.
In BLE, the timing is very critical, and when the power is twitching on the SoC, the stability of the timing is broken. And the longer the interval, the greater the clock drift.

[NerdyProjects]

Why did you close this? It is not fixed.

[pvvx]

Version 4.1 introduced a limitation on connection intervals (up to 1000 ms).
The audit showed that this is the maximum that can be done on the software side. It is verified that the performance becomes more stable.

This is stated in the README repository.

I can't solder a capacitor into your thermometers.
The rest refers to the Web Bluetooth API, Linux kernel and utilitу versions, and the BT adapter used.
These parts are beyond my control.

Entering "devIdEnabled = true;" disrupts all other options. Without determining which device is connected, users experience even more errors with random firmware until the devices are completely inoperable.

Linux has only recently fixed some of the bugs and made additions to work with BLE. But there is still no support for Bluetooth 5.0, released in 2016, and most of the utilities are still unpatched.
The number of errors in previous versions of BLE programs on Linux is extremely critical, so it is better to assume that Linux does not support BLE.

[NerdyProjects]

As discussed this is NOT about a capacitor on my device but the issue that not all services are returned in the bluetooth implementation (whatever the reason it).

Hmm, I would suggest adding a button/checkbox "force recognition of custom firmware" or something, as otherwise I always have to use a patched version of the web flasher...

[bcc]

I was seeing the same issue using Chromium on Linux (ubuntu 22.10 currently) - what worked for me was to flash them, then remove the pairing for the devices in bluetooth manager, then from a terminal, run sudo systemctl restart bluetooth - I was then able to re-pair with them and configure as normal. I assume something in the linux BT stack is unhappy about the device name change.

[NerdyProjects]

@bcc thank you! That also works for me. So
a) pair, flash
b) remove pairing
c) repair, configure

[pvvx]

These are standard actions for most OS (operating system).
You should always update OS caches if any device has changed functionality but the MAC/IP hasn't changed.

Pairing is required for BLE devices using security. For example, a pin code. In other cases, this is not required.

There is an indication in README.md:

• Supports Cannot connect after flash firmware and setting PIN (LYWSD03MMC) #174 (comment) and encrypted bindkey beacon

The described is not a solution to the issue, since it refers to another incorrect work of Linux.
And you need to send questions to Chrome's Web bluetooth API and the framework that makes BLE work on Linux.

[evlo]

This is most likely not a Linux issue. Without capacitance, the SoC supply voltage drops strongly and sharply during transmission, which disrupts the operation of the microcircuit.

For reliable connection and refirmware on LYWSD03MMC, the battery level must be more than 40%. This is a design feature - a cheaper version of the hardware from Xiaomi:

.

On devices with missing power capacities, do not set 'Connect latency' to more than 1000 ms!

Shown how the first request-response after the connection worked, but then it fails and multiple attempts to re-establish the connection, ending with a timeout disconnect. The reason is that Xiaomi did not put the recommended capacitors on the board and the voltage from the CR2032 jumps more than 20% on a still incompletely discharged battery. If you install a capacitor of a few microfarads, then these phenomena disappear and the stability of work increases many times over, and the battery life also increases by at least 20%.

Software fix is not possible. To slightly increase the stability of the connection is obtained by reducing the interval (connect latency). In version 4.1, this value is now limited, which leads to some increase in connection consumption. But such a solution is better than breaking the connection with frequent "retransmitions", which causes even more consumption...

Which one of these telink + sth4 would you recommend to be most stable even in extreme temperatures?
Would the one without display work with firmware for LYWSD03MMC) ?

If you would be so kind, cand you please send me example of correct capacitors (ideally smd that would fit into casing) to use and which way to orient them (what is is "-")?

[pvvx]

Disabling the display is in the new firmware.
LYWSD03MMC is only available in the latest HW versions. This is usually B1.9. Turning off the display on the LYWSD03MMC B1.9 reduces consumption by about 2 times from the default settings.
This software shutdown is the display chip in sleep mode. After installing the LCD shutdown, it is advisable to remove and insert the battery, because not all chips have documentation.
CR2032 batteries are not designed to operate at low temperatures. But there are special versions of such batteries and they have a different marking

[evlo]

Sorry, I meant the other device in the picture, officially unsupported, that does not have any display at all :)

[pvvx]

Any thermometers with CR2032 have the same problems - they do not tolerate negative temperatures and high humidity.

[evlo]

I do understand that, however I liked the no display version for aesthetic purposes, bout would not like it if it is not possible to run with your firmware.

Regarding running in negative temperatures - I think with soldered capacitors in c26 and c25 it might be ok for some time, i obviously do not expect it to run for a year in that case.

[pvvx]

СR2016...CR2450... discharges rapidly in the temperature range above +25°C and below 0°C. And at negative temperatures, the output voltage drops significantly.

[evlo]

I meant these capacitors that are missing would help

also now I see that the one on the picture without display is aqara

[pvvx]

Regarding running in negative temperatures - I think with soldered capacitors in c26 and c25 it might be ok for some time, i obviously do not expect it to run for a year in that case.

Depends a lot on the battery manufacturer.

A ceramic capacitor is used. They have no polarity.
And the larger the capacity, the greater the leakage on the capacitor. It is necessary to look at the documentation and choose the right type, since cheap ones, with capacities of more than 20 UF, have a leak comparable to the consumption of the thermometer itself.
Therefore, the optimal capacity is about 10 UF.

[pvvx]

The graph on the main page shows the results of the work of two CR2032 in the LYWSD03MMC thermometer version B1.9 on the street with default settings, no capacitors were soldered, thermometer well protected from precipitation. Firmware versions were updated as they were released. At the end, the thermometer itself deteriorated - the consumption current abruptly became huge - something sprouted on the printed circuit board under the chips. Flushing did not give anything. Warming up with a blow dryer eliminated this, but I threw out this thermometer, because there is no guarantee in its normal subsequent operation.

[MatiasFernandez]

@pvvx would it make any difference to use a film capacitor instead of a ceramic one for low leakage current?

[pvvx]

See "MAX. DCL" in the documentation for capacitors.
Or "Insulation resistance"...
Sample:
https://www.vishay.com/docs/40154/tl3.pdf

ECW-U1105KCV 1uF 100V Plastic Film Capacitor
https://datasheet.lcsc.com/lcsc/1811071030_PANASONIC-ECWU1105KCV_C264044.pdf
Insulation resistance (IR): 100 V : IR ≧ 1000 MΩ∙μF (20 °C, 100 V, 60 s)

[MatiasFernandez]

That's useful. Thanks!