Determine current lock state from BLE advertisement payload

[formatBCE]

Hi all!
Target device: M300.

Current integration state doesn't allow to track lock state, if it was operated manually or through official app/cloud integration.
On any operation(manual/remote), though, lock adv is changing for me.

Maybe, it's just M300, but could you please check on other device?

Opened adv:
0201061BFFBABA030301040036303030353938000001240000003A8A000000
Closed adv:
0201061BFFBABA030301040036303030353938000001240000003A9A000000

Byte 55 is changing from 8 to 9. I noticed that a while ago.

Would be super useful to know exactly lock state, even if operated by person. It would help to get integration more robust and responsive, i believe.

[nourmehdi]

@formatBCE i have M531 lock the adv changes with lock opening and closing but as i said , when i was reversing i found that there's two kinds of lock payload format so the lock code should take this into consideration

[rospogrigio]

I tested on my device and I confirm that the adv does not change on manual operation.
@formatBCE , in your case I see that it changes from opened to closed (8A to 9A) but the lockEvent does not increase (3A=3A). Since I was relying on this value to change for updating the status (see line 571), I have to change that check (still need an "if" there because I want to keep the lock in Failed status when we get a FAILCONNECT).
Will do it soon.

[rospogrigio]

Can you please try this Pull Request and let me know if it fixes the issue? #3

[formatBCE]

Can we maybe have state and status in different fields?
Like, integration-related state will contain fail/success/whatever outcome there was, and lock status - showing current locked/unlocked? I can do custom sensor for that, but it would be great to have it as part of device...
@rospogrigio what do you think?

For sure, this is not useful in your case, but for those like me it would be really desired...

[formatBCE]

Can you please try this Pull Request and let me know if it fixes the issue? #3

Sorry for being dumb - I have your integration installed from HACS. Should I replace it with pulled down version with this pull-request in custom_components to give it a try?

[rospogrigio]

Yes, you have to replace the sources.
I personally prefer to have a single sensor but I'll think about it. Let me know how it goes...

[nourmehdi]

I tested on my device and I confirm that the adv does not change on manual operation. @formatBCE , in your case I see that it changes from opened to closed (8A to 9A) but the lockEvent does not increase (3A=3A). Since I was relying on this value to change for updating the status (see line 571), I have to change that check (still need an "if" there because I want to keep the lock in Failed status when we get a FAILCONNECT). Will do it soon.

Yep that the issue i said i encountered few months ago the lockevent in the adv is not 100% reliable , it happens that it's different from fff3 prop when lock is operated manually . I think the lock events can be 100% correct by using it's value from fff3 instead of adv , however the lock status( locked or open) should always be parsed from adv payload and can be done without counting on lock event . The failed state can be pulled from ble mqtt response . This procedure will however increase lock operation time so we need to work on improving firmware speed , i will start working on this and try remove all uncessary drivers .

[nourmehdi]

Another thing , i tested my esp32 via console , 3 times read command , 3 successfull doneread result , no failure , could you confirm wich tasmota version you guys are using ?

[rospogrigio]

I'm on 10.0.0.3 development, built on 2021-11-24. You are using release or development?

[nourmehdi]

I'm on 9.5.0 release and is veeeery stable , one tasmota golden rule if your current version works well dont update because it can causes a lot of trouble , it will be very cool if you can downgrade to 9.5.0 after a full esp32 erase and see if you still got the failconnect issue

[rospogrigio]

OK I'll try it and see how it goes...

[nourmehdi]

OK I'll try it and see how it goes...

Perfect i will wait for your feedback

[formatBCE]

I'm on 9.5.0 release and is veeeery stable , one tasmota golden rule if your current version works well dont update because it can causes a lot of trouble , it will be very cool if you can downgrade to 9.5.0 after a full esp32 erase and see if you still got the failconnect issue

I also have 10 version - this is default version, loaded via Tasmota Web Installer...
Esptool didn't work for me for some reason, and tasmotizer doesn't support ESP32, at least on Mac.
I will have my Windows PC running today, so I will check, what can I do there to downgrade :)

[formatBCE]

Ok, what i did so far:

• checked the pull request. New code works. There's "Jammed" status shown sometimes, when i slowly open lock manually, and it does go off only on operation from integration. A bit strange, but i believe manageable.
• when i open/close quickly, everything works and app shows correct status.
• downgraded tasmota to 9.5.0. I'd not say, that i feel improved stability, although signal strength went up a bit (from approx -75 to approx -70).

[nourmehdi]

@formatBCE good , with 9.5.0 still got the connectfail issue ?

[rospogrigio]

I do still have issues with 9.5.0, approx. 50% of failures. Will try to put it closer but it is already at 1 m from the lock... Is there a way to add an antenna maybe?

[nourmehdi]

@rospogrigio weird very weird mine is working veery good , wich tasmota firmware have you installed on your esp32 because there are many variants ?

[rospogrigio]

9.5.0 release, tasmota32-bluetooth.bin from here: http://ota.tasmota.com/tasmota32/release-9.5.0/

[rospogrigio]

So, I tried putting it closer and changing the power adapter and it went 100% successful, so now I have to understand whether it's a matter of adapter or distance... will make more tests.

@formatBCE :

• checked the pull request. New code works. There's "Jammed" status shown sometimes, when i slowly open lock manually, and it does go off only on operation from integration. A bit strange, but i believe manageable.

Yes, my fault. I fixed this, try to download again PR #3 , now you should have Jammed status go away also with manual operation... let me know.

[nourmehdi]

@rospogrigio perfect i'm pretty sure is a more a matter of power adapter than distance , mine is at 1.5m not direct sight (separated by concrete pylon) , and it works good , the power source is important as the current used by esp32 can vary very fast .

[omersh82]

@rospogrigio per your recommendation i also put it closer to the lock and it is working fine now on HA.
the current issue is that it reports wrong open or close (might be related to the lock close \ open side?).
is there a way just to revert this via HA? (except of creating a template entity).
thanks

[rospogrigio]

@omersh82 that issue should be fixed, have you tried PR #3 ?

[formatBCE]

@rospogrigio ok, I'm glad to report, that everything works correctly now.
Great job!!

[omersh82]

i just tried and for me it still show the opposite i managed to overcome this by creating a lock entity and send the default (off) to unlocked.
i am still getting failed on the status from time to time, i will test another ESP might be this is a faulty one.

thanks :)

[rospogrigio]

It's really strange, can you post the advert you get when it is locked and unlocked?

[rospogrigio]

@rospogrigio ok, I'm glad to report, that everything works correctly now. Great job!!

Good, I have published it in a new release then 😉

[gorzynsk]

My setup finally works. I could suggest some remarks in the instruction to mention wemo-airbnk app (because the is also smart lock app) and setting language of the phone to english if someone have trouble getting verification code from e-mail (there were no code visible in e-mail at all when app reported Polish language during the request).

My lock however reports opposite status "unlocked" when it is locked... The opening direction in the app is set to "Right" and I had to change it from default "Left" if I remember correctly.

[sgrzys]

@gorzynsk Thx for your remark - with Polish language I still have email without verification code (reported to WeHere), and the translation is hopeless - English work perfect.
@rospogrigio I'm using M521 with reversed to "Right" direction and the status in HA is wrong too.