[Support] Unbind gateway from HomeAssistant integration (spike)

[0rsa]

Hello, Thank you for this firmware. My ESP32 is connected to the wifi and to the mqtt broker, I can see it in the mosquitto log files with a successful status. Playing with my M531, I cannot see any message on the topic set during the configuration. I guess I have an issue between the ESP32 and the M531 smartlock. What is the best way to investiguate on this current issue? I can see some Serial.println() in the source code, is there a solution to view those in real time? Thank you

[formatBCE]

Hi! You may see printlns, if you connect to ESP with serial monitor (e.g. from Platformio). Unfortunately, there's no way to check it wirelessly.

I'm working on moving 5his code to ESPHome, so users could be able to see logs in ESPHome console (together with all other advantages of this approach).

You should see topic "airbnk_lock" with subtopics "availability" and "tele". That would mean, that gateway itself is up and scanning. If so, but you don't see subtopic "adv" there - then lock is not found, or there's some error parsing payload...

You may check lock visibility with program nRFConnect from your phone.

[0rsa]

Thank you!

I will set up a dev environment this week-end using VS code & Platformio and try to get more info on my issue.

I have paired my smartlock to the WeHere app and I can see an option called "transfer" which is here in case where you have to transfer the smartlock to an other account.

Has the smartlock to be reseted or something else to get successful paired with the ESP32?

Considering we "just" need MAC Address of the device to take control of it, I'm a bit affraid that anybody can open my door with a bluetooth sniffer (I used Android bluetooth scanner to find MAC address and you can simply identify this smartlock with his name "M531") and an ESP32 so I'm probably missing an init step.

[formatBCE]

If you're able to open/close lock from WeHere app - you should be good to go.

You don't just need to have MAC. You will also have to authenticate yourself in HomeAssistant integration. This is the nutshell - all payloads to lock are ciphered with key, received from WeHere by integration on auth step. So don't be scared, it's easier to open your lock with picking tool, than with Bluetooth sniffer.

P.S. don't miss the step of assigning (NOT transferring!) lock to separate user, used for integration - otherwise your account will be logging out each time you use official app.

[formatBCE]

To be clear: ESP32 has nothing to do with open/close commands. It just transfers BLE data from lock to integration and back. So all sensitive info is on HA side.

[0rsa]

Hum, annoying. I do not use HA at all, I use node-red which is listening on the MQTT topic.

Do you think I can do the first setup using HA one time and then use the lock only via MQTT or will I need absolutely HA to exchange with the smartlock?

[formatBCE]

Oh.

Sorry to say, but you won't be able to do this. As I said, generated payload is received from integration itself. If you're good at programming, you may try to translate integration code from Python to C/C++, and get it working. I was thinking about it, but with my basic knowledge on both languages it seems to be hard and time consuming. This gateway was intended for using with HA only... Sorry again.

[0rsa]

My bad, I felt confident reading the README step 5 (and start sending telemetry and lock advertisements/commands to MQTT) but I should have read the HA part where I can see the "authentication" process, which is an obvious step to avoid security issue I mentionned above.

I will try to extract what I need from HA integration, this is something I already did in the past to get a xiaomi vacuum map in my personnal app, thank you for your suggestion.

I close this thread now, my ESP32 with your firmware is probably working well and is just waiting now for the next step with HA integration.

Again, thank you for your kindly and quicly messages!

[formatBCE]

No problem, and sorry for not being able to help!

If you by any chance will have time and mood to check HA integration, feel free to share your work - maybe, we will narrow this down to 1 device with ultimate software. :)

[formatBCE]

Hi @0rsa !

I was crawling around Airbnk HA integration, and found this: https://github.com/rospogrigio/airbnk_mqtt/tree/master/tools

Looks like the logic of payload generation is carefully pulled into separate file. It might be simpler than I thought... I'll check what I can do. If ESP32 will survive my level of programming, probably, we can achieve whole logic in one place, with pure MQTT integration.

[0rsa]

Great news. I started yesterday rewriting HA integration to nodeJS. I can currently get an access code, a token, the list of devices and the voltageCfg of the lock (based on model and firmware).

I understand now why there is no MQTT message on the topic set because it uses in fact some subtopics based on the topic name BLEOpTopic = "cmnd/%s/BLEOp" BLERule1Topic = "cmnd/%s/Rule1" BLEDetailsTopic = "cmnd/%s/BLEDetails2" BLEDetailsAllTopic = "cmnd/%s/BLEDetails3" BLEStateTopic = "tele/%s/BLE" Where %s is the custom name

The next step is the hardest with the encryption/decryption of the payload sent to the ESP32.

I will stop my work for now since you plan to make the ESP32 working as standalone with MQTT.

Let me know if you need some help, especially for testing.

[formatBCE]

Thanks for getting into it! :) Don't stop, your work is awesome! Actually, payload building is not so hard - just pay attention to details, and move from one function to another. I already got through that code, it's not hard. Didn't implement anything though yet - was optimizing BLE and memory usage on ESP. In case my work won't succeed (which may happen because of ESP32 limitations), you will have your own solution. That's so freaking cool! :) About topics: pay attention, that cmnd/... topics are related to Tasmota gateway (you may find description on main HA integration page, it can use Tasmota for sending payloads). My gateway has custom root topic, with subtopics "availability", "adv", "command" and "command_result".

[0rsa]

I saw your last message about the "issue" using Wifi & BLE simultaneous, that's a sad news, which maybe explain why I found Nuki solution a bit unreliable using their bridge. That's why I'm here in fact, I gave a try to Danalock zigbee (firmware issue for months ago, the smartlock is dropped out from the zigbee network after hours when it is not connected directly to the coordinator without jump, long story on deconz forum) , Danalock bluetooth or Nuki and I'm still not convinced by their reliability.

So I keep going on my own JS solution, thanks for the tip about topics, I missed it yesterday.

[formatBCE]

I mitigated the problem. Just sent ~20 commands on/off, and all of them succeeded, no failures. That was part of my today's refactoring. ESPHome is losing connection to gateway for couple seconds time to time, but MQTT payload goes through always.

What I worry about is that ESP32 has not much performance and storage to use, so all this API calls etc. can be too big for it. But I won't know it till I compile it.

Now I have 2 versions of firmware - custom and ESPHome-based. They differ a lot(by both code base and used space), so I will have to choose, which to play with. For HA users ESPHome seems to be much more convenient, but requires additional configuration for device autodiscovery.

[0rsa]

I did some progress today. I'm able to retrieve a payload on roottopic/adv with a state which updates well when I open/close the doorlock (ESP32 is close to spam the channel, is it expected ? I got many many messages by minutes) I retrieved the commands packets using generate_payloads.py with proper information in order to send a command via mqtt It was the beginning of problems

When I send a command, I get a response from the ESP32 listening on roottopic/command_result which is successful but with a bad lockStatus hex.

{"success":true,"error":"","sign":0,"mac":"XX:XX:XX:XX:XX:XX","lockStatus":"AA00040000060600000000000000000000000000"}

This lockstatus hex does not pass the first test in the parse_new_lockStatus function if bArr[0] != 0xAA or bArr[3] != 0x02 or bArr[4] != 0x04: self.logger.error("Wrong lockStatus msg: %s" % lockStatus)

All my tries finish by this payload and the ESP32 becomes unresponsive after some tries. I cannot reach WebUI anymore, even after 10 minutes. I need to restart it to get it working again.

[formatBCE]

It's interesting. Internal logic does try to get correct payload from lock after operation for 10 times with period of 700 ms between. So if you're receiving incorrect lock status, that means lock doesn't respond correctly. It does happen, if incorrect payload was sent. So basically check your commands.

On unresponsive behavior and hanging - this might be the result of thet retries I mentioned above - WiFi stack just folds down and probably never comes back. I believe you're testing on custom firmware. Can you buy any chance test on new ESPHome version? It should be way better.

I will try to bring latest logic changes to custom firmware ASAP.

On spamming: well, we tried to make it as fast as it can do - now right after finding the lock, it restarts the scan, so yes, it's basically spamming. It's ok to MQTT I guess. Case is, that in event of manual operation you'd want to know new status as fast as you can. That's why we introduced these changes instead of fixed scan period (that way you might have had deprecated open/close status for up to 10 seconds).

[0rsa]

Thank you for explanations, it's more clear now. I'm sending this object: { command1: "FF00...", command2: "FF01...", sign: Math.round((new Date()).getTime()) } where command1 and command2 are respectively PACKET 1 and PACKET 2 I obtained from the generator tool. Do you see something wrong with this payload?

[0rsa]

I'm now with ESPHome version and I can share with you some logs when I send the command:

[20:32:39][D][airbnk_mqtt:237]: Got command [20:32:39][D][airbnk_mqtt:171]: Sending to:

[20:32:41]lld_pdu_get_tx_flush_nb HCI packet count mismatch (1, 2) [20:32:41][D][airbnk_mqtt:225]: Failed to connect to lock. [20:32:41][D][airbnk_mqtt:178]: Retrying sending [20:32:44]E (77606) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time: [20:32:44]E (77606) task_wdt: - async_tcp (CPU 0/1) [20:32:44]E (77606) task_wdt: Tasks currently running: [20:32:44]E (77606) task_wdt: CPU 0: IDLE0 [20:32:44]E (77606) task_wdt: CPU 1: IDLE1 [20:32:44]E (77606) task_wdt: Aborting. [20:32:44]abort() was called at PC 0x4016a7ec on core 0 [20:32:44] [20:32:44]ELF file SHA256: 0000000000000000 [20:32:44] [20:32:44]Backtrace: 0x4008f6a0:0x3ffbfc80 0x4008f91d:0x3ffbfca0 0x4016a7ec:0x3ffbfcc0 0x4008dd49:0x3ffbfce0 0x40193773:0x3ffbc160 0x4016c103:0x3ffbc180 0x4009210d:0x3ffbc1a0 0x4009095e:0x3ffbc1c0 WARNING Found stack trace! Trying to decode it WARNING Decoded 0x4008f6a0: invoke_abort at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/panic.c:715 WARNING Decoded 0x4008f91d: abort at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/panic.c:715 WARNING Decoded 0x4016a7ec: task_wdt_isr at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/task_wdt.c:252 WARNING Decoded 0x4008dd49: _xt_lowint1 at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/xtensa_vectors.S:1154 WARNING Decoded 0x40193773: esp_pm_impl_waiti at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/pm_esp32.c:492 WARNING Decoded 0x4016c103: esp_vApplicationIdleHook at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/freertos_hooks.c:108 WARNING Decoded 0x4009210d: prvIdleTask at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/tasks.c:4813 WARNING Decoded 0x4009095e: vPortTaskWrapper at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/port.c:355 (discriminator 1) [20:32:45] [20:32:45]Rebooting...

[formatBCE]

I saw similar thing, when my ESP was far away from the lock. These locks are pretty weak in connection, so for stable work I hold my gateway like 1.5 meters from lock (as close as possible).

[0rsa]

It connects with the ESP32 closer but still rebooting after the connection

[20:49:47][D][airbnk_mqtt:171]: Sending to:

[20:49:50][D][airbnk_mqtt:181]: Connected to lock. [20:49:52]E (22053) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time: [20:49:52]E (22053) task_wdt: - async_tcp (CPU 0/1) [20:49:53]E (22053) task_wdt: Tasks currently running: [20:49:53]E (22053) task_wdt: CPU 0: IDLE0 [20:49:53]E (22053) task_wdt: CPU 1: IDLE1 [20:49:53]E (22053) task_wdt: Aborting. [20:49:53]abort() was called at PC 0x4016a7ec on core 0 [20:49:53] [20:49:53]ELF file SHA256: 0000000000000000 [20:49:53] [20:49:53]Backtrace: 0x4008f6a0:0x3ffbfc80 0x4008f91d:0x3ffbfca0 0x4016a7ec:0x3ffbfcc0 0x4008dd49:0x3ffbfce0 0x40193773:0x3ffbc160 0x4016c103:0x3ffbc180 0x4009210d:0x3ffbc1a0 0x4009095e:0x3ffbc1c0 WARNING Found stack trace! Trying to decode it WARNING Decoded 0x4008f6a0: invoke_abort at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/panic.c:715 WARNING Decoded 0x4008f91d: abort at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/panic.c:715 WARNING Decoded 0x4016a7ec: task_wdt_isr at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/task_wdt.c:252 WARNING Decoded 0x4008dd49: _xt_lowint1 at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/xtensa_vectors.S:1154 WARNING Decoded 0x40193773: esp_pm_impl_waiti at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/pm_esp32.c:492 WARNING Decoded 0x4016c103: esp_vApplicationIdleHook at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/freertos_hooks.c:108 WARNING Decoded 0x4009210d: prvIdleTask at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/tasks.c:4813 WARNING Decoded 0x4009095e: vPortTaskWrapper at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/port.c:355 (discriminator 1) [20:49:53] [20:49:53]Rebooting...

[formatBCE]

And this is pretty weird. I will check, what's wrong with that.

[formatBCE]

Could you please clarify, that lock is opening on your commands?

Checked previous messages, and looks like you didn't mention that, although ESP reported on write success (that's where it should have opened).

There might be a problem: if payload is incorrect, not only lock won't open, but it blocks further requests via BLE, until it's opened/closed manually. In this case gateway won't be able to connect to lock for sending command.

Meanwhile, to speed up gateway, you may delete code, related to status characteristic connection and status sending from sendBLEPayload function in .h file. It isn't needed for your case, and hardly needed for HA (I did it already, and tests are promising).

[0rsa]

The command still does not work, I never succeed to open and lock the door. This is "worst" with ESPHome because I do not receive any answer on /command_result because, I guess, the ESP32 is rebooting before sending the result of the command (but so far better to see logs file in real time) Currently, I don't know what to do, my payload seems good from what I've read from the source code. EDIT About my payload, I have to regenerate PACKET 1 & PACKET 2 each time from the adv payload if I understand well. I'm using the same codes since yesterday. I will adapt my work to get new ones each time.

[formatBCE]

Well, first thing is to try to delete that code i suggested. Find this in airbnk-gateway.h and comment out strings like i did (it's chunk from ESPHome version):

} else if ( pRemoteCharacteristic->writeValue(command1, len1, true) && pRemoteCharacteristic->writeValue(command2, len2, true) ) { // NimBLERemoteCharacteristic* pStatusCharacteristic = pRemoteService->getCharacteristic(NimBLEUUID(statusCharactUuid)); // if (pStatusCharacteristic == nullptr) { // ESP_LOGD("airbnk_mqtt", "Failed to get status characteristic."); // error = "FAILED TO GET STATUS CHARACTERISTIC"; // } else { // time_t timestamp = (time_t) 0; // int tries = 10; // while (tries > 0 && (status.empty() || (0 == status.compare(status.length() - 2, 2, "00")))) { // if (tries < 10) { // delay(700); // } // std::string readStatus = pStatusCharacteristic->readValue(&timestamp); // if (readStatus.empty()) { // tries = 0; // error = "FAILED TO READ STATUS"; // ESP_LOGD("airbnk_mqtt", "Failed to read status characteristic."); // } else { error = ""; result = true; // status = toHex(readStatus); // } // tries--; // } // } } else { error = "FAILED TO WRITE"; ESP_LOGD("airbnk_mqtt", "Failed to write characteristic."); }

Then try to reflash gateway.

Also, check code generator here: https://github.com/rospogrigio/airbnk_mqtt/tree/master/tools

It's just to check if you didn't miss anything in payload generation. Once you have API keys, you can use that script to generate payload, that was tested already.

If lock never did open, but at first try you did receive "success" from gateway - then at least that time payload was incorrect. If ESPHome doesn't work for you, please revert back to custom firmware - that was at least giving you answer.

[0rsa]

Ok so:

1. I removed your lines from the script mounted on the ESP32 (reliability seems better without)
2. When I receive a new adv message, I generate new PACKET 1 and new PACKET 2 from it using the python generator

The ESP32 logs [06:50:59][D][airbnk_mqtt:206]: Got command [06:50:59][D][airbnk_mqtt:171]: Sending to:

[06:51:01][D][airbnk_mqtt:181]: Connected to lock. [06:51:02][D][airbnk_mqtt:178]: Retrying sending [06:51:02][D][airbnk_mqtt:194]: Failed to connect to lock. [06:51:02][D][airbnk_mqtt:178]: Retrying sending [06:51:02][D][airbnk_mqtt:194]: Failed to connect to lock. [06:51:03][D][airbnk_mqtt:178]: Retrying sending [06:51:03][D][airbnk_mqtt:194]: Failed to connect to lock. [06:51:03][D][airbnk_mqtt:150]: FAILED TO CONNECT

Are we sure the payload is still the issue in this case? Thanks!

[formatBCE]

I guess there's two things.

1. You may have deleted too much. Pay attention to line "result = true", it should be there, don't delete it.
2. I guess, BLE client can't connect twice, that's why next 4 tries give you "cannot connect". It's my fault, I will fix it.

If you get that line back, it should work now without my fix for (2).

[0rsa]

Good catch about a mistake in commenting the code. Now I got [07:56:33][D][airbnk_mqtt:148]: Operation successful But the doorlock is still not opening/closing

command_status payload: payload: "{"success":true,"error":"","sign":0,"mac":"XX:XX:XX:XX:XX:XX","lockStatus":""}"

[0rsa]

I did a new update to use the sign value generated by the generator tool Now the return payload of the ESP322 includes a sign value but still not working

payload: "{"success":true,"error":"","sign":1662790220,"mac":"XX:XX:XX:XX:XX:XX","lockStatus":""}"

[formatBCE]

Well, at least we're somewhere

The two facts are noticable:

1. Payload is written, but lock doesn't respond.
2. Gateway cannot connect to status characteristic.

My guess is, maybe, your lock is using some other characteristic addresses for communication. Just a guess. That would explain both facts.

I'd ask you to connect to lock with nRFConnect, and check service I'd and characteristics, exposed by this service. Also would be nice to take example messages from that characteristics (also can be done with nRFConnect).

Compare characteristics UUID with one in my code for reference.

[0rsa]

I put that here and I go try to compare that.

Basically the same

define serviceUUID "0xFFF0"

define characteristicUUID "0xFFF2"

define statusCharacteristicUUID "0xFFF3"

[0rsa]

Ok it works

[formatBCE]

Yeah, but.

1. FFF3 characteristic has bad value (this value is set there, when something wrong happened with open/close. Try re-insert batteries, or at least open/close lock manually, and check, if last bytes won't be 00. Then lock is ready to receive remote commands.
2. FFF2 value is the last value written to it. It looks weird to me (but i'm not sure) because of bunch of zeroes in the end. Check it please.

Once lock will be operable (you may check it from official app, open/close), check these two values - maybe, they will give you some hint. Also, try to go through README of that link i posted, and send commands you generated with nRFConnect, to see, if lock is operable.

[formatBCE]

Oh, cool. Tell me more :)

[0rsa]

The error comes from the adv payload I pass to the generator.

Paste here the log advertisement value you can get from nRF Connect:

lockAdv =

The data payload I got from the mqtt channel roottopic/adv is not the same I can get from Nrf connect in the log files.

I extracted a new fresh adv payload from Nrf connect log file and the command has been successfully executed by the smartlock.

How can I get this adv payload refreshed automatically when needed and from where?

Example of Nrf connect log:

2022-09-09 13:19:51.054, -66 dBm, 0x0201061BFFBABA160D010200313230303938370000036D000000B90A0000000302ABAB0D094D3533312D3XXXXXXXXXXXX 2022-09-09 13:19:49.953, -67 dBm, 0x0201061BFFBABA160D010200313230303938370000036D000000B90A0000000302ABAB0D094D3533312D3XXXXXXXXXXXX

Example of what I got from roottopic/adv "BABA160D010200313230303938370000036D000000XXXXXXXX"

I'm looking for the first one of course.

[formatBCE]

Huh. Interesting. HA integration works with this exact adv message, read from advertisement. Just checked it for my lock - they're same.

The only difference is, that adv from gateway is string, representing bytes, and doesn't have 0x at the start. Could it be your problem?

EDIT: I guess, that script does work with full payload from nRFConnect, and it's set up to do it like this. Integration does use short format of advertisement (without unneeded vendor info, added by nRFConnect - basically, this is what lock gives to ESP32: baba03030104003630303035393800000147000008ad9a000000 26 bytes.

[0rsa]

I put some examples in my message above. The payloads are clearly different and I have the feeling that prefix and suffix are missing (I mean, a part seems to be identical)

Prefix: 0201061BFF Suffix: 000302ABAB0D094D3533312D3XXXXXXXXXXX

[formatBCE]

So that prefix and suffix aren't actually needed for command generation. You may try logic from HA integration, instead of that tools script. Check this file for reference: https://github.com/rospogrigio/airbnk_mqtt/blob/master/custom_components/airbnk_mqtt/custom_device.py

[0rsa]

Can this part be static along the time if we are talking about vendor and so on? I will try to add these parts manually and see if it can work

[formatBCE]

I'm not sure actually. It might happen, that tools script does use some bytes from prefix/suffix instead of main payload chunk. But you can try, it won't hurt. Or check the code, if those bytes (by index) are used at all.

[0rsa]

Seems to be working with 2 successful attemps in a loop I prefixed the data received from roottopic/adv with: 0201061BFF And suffixed with 0302ABAB0D094D3533312D31323030393837

[formatBCE]

Here's the line, where this 26 bytes are extracted from big payload: https://github.com/rospogrigio/airbnk_mqtt/blob/7324cf9d2f54c812ecdd7beb7e36a9be61574871/tools/generate_payloads.py#L241

So just use full message from gateway instead of that "lockEventsStr" variable - and it will work.

[0rsa]

Yeah ok, these bits are in fact not considered so you can put what you want or you can change code portion you mentionned. It's a good news, thank you very very much for your time and your support, I would never have succeeded alone. Next step is to install the module at his final location, crossing the fingers that the signal strengh is enough :)

[0rsa]

I did 4 tests: 2 / 4 successfull The main problem is that the ESP32 reboots and does not send a state return in case of failures. From my side, what I can do is to wait for a return message in a fixed time and consider that the command is lost if not. It's not really ideal.

[formatBCE]

Congrats! You did everything by yourself, i just shared a bit of knowledge :)

Yes, HA integration does that. Or waits for next adv message and reads info from there. This is caveats of BLE on ESP32 - it's super unreliable together. I will try to improve it though.

I will leave this open, to track my desire of moving everything to gateway.

P.S. if you eager to share your code, it would really help me - i know JS much better than Python, so it'd be easier to translate to C++.

[0rsa]

At the end, node-red is doing all the magic

For now, I just coded the script which make some calls to the wehere API to retrieve information about the smartlock (mainly newSnInfo and appKey to feed the python generator) Once you get that, you can see on my flow that :

• I use mqtt node to get adv info from the ESP32 and I store it to a flow variable
• The commands flow are reading this flow variable to feed the python generator lockAdv to prepare the payload which be sent to the ESP32

It's a beginning, to have quickly a working solution and to test it in real life since I just need to add some common input/output nodes to monitor and control remotely.

[formatBCE]

Oh, got you. NodeRED is amazing instrument, and i actually use it myself for automation in HA, since included automations are too basic for me :)

Ok then i will go step by step and see what it takes. Actually, i will need to get that API working first...

[formatBCE]

So while checking API requests for this integration, I realised, that there's no good way to create config flow via ESPHome. So HA integration is still needed for correct work - other way users would be forced to get all required data manually, which is pretty high level operations for majority.

So I will just try to optimize current solution as far as I can, leaving authorization on HA side.

The payload generation logic can be done in ESP side, I believe, with receiving required data from HA upon request. There's one risk here: sensitive data will be transferred via MQTT, which might be not secure depending on user installation. While generated payload is one-time key, auth parameters can be used by intruder to generate payloads on the go.

So most probably, simple refactoring to HA integration will be enough to make integration more reliable, unfortunately, leaving non-HA users behind :(

[0rsa]

Can we imagine a kind of "how to" to clean the HA integration code from the firmware in order to use third party solution like mine in the README? It lets an open door for non HA users to benefit of your latest improvements.

About bluetooth range, did you try to play with the esp_ble_tx_power in ESPHome? It seems that the default value can be increased from ESP_PWR_LVL_P3 to ESP_PWR_LVL_P9

[formatBCE]

I guess it would be nice to do. If you describe your findings, I will include them into README - or you can create your own repo, and I will mention it as non-HA way to use this firmware.

[0rsa]

A small follow up. My current setup seems to be reliable in real life, since the ESP32 is really close to the doorlock (1meter without obstacle). I close and open door using a beacon and it works in a daily use.

About low range bluetooth:

• Do you have the ability to increase ESP32 BLE power as mentionned in one my previous post (esp_ble_tx_power)?
• Are you aware of an ESP32 which has a better bluetooth range than others?

I am following your thread directly on the HA integration plugin github and I saw that you did some improvments. Do you think that is it relevant to have a look now on your code tring to integrate the changes in my current solution or is it better to wait a small time to ensure this is reliable?

Thank you!

[formatBCE]

Hi!

Well, in general, the rule of thumb is "if it's working - don't touch it" :) I never follow it, and always update right away. Which gives me a lot of fun resolving troubles. :)

My current code is stable. I'm sure, as I use latest version for more than a week, and there was no lags/reboots/unavailability.

So it's up to you, good sir, to decide, if you want to have latest, or good enough. :)

On TX power - I'm pretty sure, that I'm setting highest power possible somewhere in the code. Just can't remember where, need to search for that line. There are ESPs with external antenna - they are great range-wise. But the problem might be in the lock itself - signal from it is pretty weak.

Cheers!