Seemingly correct installation, but lock entities are all unavailable.

[TheDescender]

Do you have any Idea about what could be the general cause of something like this?

I'm using the Tasmota FW and have an M531. ESP32 device correctly configured, repository imported through HACS. BLE enabled on ESP32. MAC address entered as: DC:23:4D:XX:XX:XX with semicolons. MQTT Topic 'ESP32ble' inputted correctly.

Perhaps I have the wrong MAC address after all? How do you go about checking this? I just looked at it in my Tuya hub and this seems consistent with what I'm reading when I scan the area with the ESP32. I'll try it with the custom firmware tomorrow, but would really love a nudge in the right direction. If you need logs, lemme know how to provide them plz, I will provide any info necessary.

https://i.imgur.com/ZGLpyqk.png https://i.imgur.com/Ihp114C.png

[formatBCE]

Hi! Could you install MQTT monitor and check if described topics are receiving messages from gateway? Also in Tasmita you can check the console logs to see, if it's searching for correct MAC. IDK if it's the issue, but maybe upper/lowercase in MAC could affect too.

[TheDescender]

It seems to be doing a whole load of pings https://i.imgur.com/bojuqkG.png , judging from the tasmota console. But I'm not sure if the MAC address is even correct. Or at least if it went wrong anywhere I would think it there, what is a reliable way to getting the MAC address for the lock?

And this is what I see when listening to all topics within the MQTT log. https://i.imgur.com/ngOTocu.png

I tried looking for MQTT Monitor, but couldn't find anything other than MQTT explorer and MQTT lens, both of which I have 0 clue how to establish a connection with or use, so i'd need some pointers.

PS: When adding the configuration, it does see the correct lock information, although I assume this might have to do with the account being tied to the lock being synced correctly. But I have 0 clue as to why it won't interface with the lock properly.

[TheDescender]

@formatBCE Hi there, so after a couple of days I had time to sit down and install the custom firmware. But i've run into another issue. It seems the device is being detected now, but I get the following error output in HA at about a 30 second interval:

Logger: homeassistant.util.logging Source: util/logging.py:114 First occurred: 5:05:22 AM (5 occurrences) Last logged: 5:05:55 AM

Exception in adv_received when handling msg on 'airbnk_lock/adv': '{"mac":"DC:23:4D:71:9F:4F","rssi":-70,"data":""}' Traceback (most recent call last): File "/config/custom_components/airbnk_mqtt/custom_device.py", line 151, in adv_received self.parse_adv_message(_p0.payload) File "/config/custom_components/airbnk_mqtt/custom_device.py", line 197, in parse_adv_message self.parse_MQTT_advert(mqtt_advert.upper()) File "/config/custom_components/airbnk_mqtt/custom_device.py", line 302, in parse_MQTT_advert if bArr[0] != 0xBA or bArr[1] != 0xBA: IndexError: bytearray index out of range Exception in adv_received when handling msg on 'airbnk_lock/adv': '{"mac":"DC:23:4D:71:9F:4F","rssi":-69,"data":""}' Traceback (most recent call last): File "/config/custom_components/airbnk_mqtt/custom_device.py", line 151, in adv_received self.parse_adv_message(_p0.payload) File "/config/custom_components/airbnk_mqtt/custom_device.py", line 197, in parse_adv_message self.parse_MQTT_advert(mqtt_advert.upper()) File "/config/custom_components/airbnk_mqtt/custom_device.py", line 302, in parse_MQTT_advert if bArr[0] != 0xBA or bArr[1] != 0xBA: IndexError: bytearray index out of range

Additionally the sensors are still reading as unknown, with the only difference being that the controls are clickable but run into the aforementioned error in the HA log, as can be seen here https://i.imgur.com/Lpt9xEg.png. Kinda at a loss on how to proceed, if you have any ideas i'd much appreciate it.

[formatBCE]

@TheDescender this actually looks like the lock doesn't transmit required data over MQTT.

Can't say anything remotely - you will have to debug it with nRFConnect app or other similar way.

The error is in integration itself, but it is caused by empty payload, sent from gateway. The gateway reads that from BLE characteristic of lock. Maybe, @rospogrigio could know something more on that - but as for me, looks unsupported, at least for now.

[TheDescender]

@formatBCE Thanks for the quick reply. You are correct that the lock isn't transmitting the data over MQTT, when listening to Topic: "airbnk_lock/adv" I get the following payloads, without any data:

{
    "mac": "DC:23:4D:71:9F:4F",
    "rssi": -73,
    "data": ""
}

Is it possible this could be caused by me having the lock paired through a tuya bluetooth gateway simultaniously with the ESP32? Or by me Simply having the wrong MAC Adress?

I'd find it weird if it's unsupported since it's an M531 with the extra powerful motor, which @rospogrigio claims is tested. I'll have a look at nRFConnect. I assume this is what i'm looking for: https://www.nordicsemi.com/Products/Development-tools/nRF-Connect-for-mobile

[formatBCE]

@TheDescender yes, nRF allows you to connect to BLE device and check it's endpoints. What is sending payload to MQTT is not the lock itself, but ESP32 (gateway) If you have Tuya bridge (not the Airbnk one), it might be, that lock characteristics are different - so gateway can't read them.

[TheDescender]

@formatBCE @rospogrigio Well I feel like an absolute monkey now. Scanning with nRFConnect turned out I did indeed have the wrong MAC address this whole time, even since the Tasmota setup. It's working fully now, can't believe I messed that up considering Tasmota was reading the same MAC address in the vicinity of the lock during scanning, so I assume it was correct.

Feel like such a clown, thanks for the help. https://i.imgur.com/X7KFYrF.png

One last thing in case you know something about it. The lock is fully working now but the lock status seems to be inverted, saying Unlocked when its Locked and Vice versa. Do you know if there's a native way to swap this status around in HA through the integration? Otherwise i'll just make a custom sensor that inverts the status.

[formatBCE]

@TheDescender congratulations on working device! :) On lock direction: there is some setup in integration for this - I don't remember actually, but search in how-to.

[TheDescender]

@formatBCE Great, thanks i'll have a look and worst case like I said I can just make a template sensor for LoveLace and invert it, no problem.

While I still have your attention though, I assume you have experience with the lock itself, do you have any recommendations on batteries to buy for it? I bought some 16340 cells, but I think the ones I bought were trash. What rechargable Li-Ion cells do you recommend or is the battery life good enough with normal CR123's?

Regardless thanks again

[formatBCE]

Don't buy rechargeable ones - they actually have lower voltage, than alkaline batteries, so:

1. Connection stability will be poor.
2. Battery sensor in HA will lie.

I use AA batteries on my M300, so can't tell, what to buy - will tell though, that my lock sits on one Duracell set (4 pack) for about a year now, and doesn't report voltage drop as of now.

[TheDescender]

@formatBCE Yeah Makes sense, I figured as much, since Li-Ion batteries usually experience heavy voltage drop at lower capacitance. Guess I'll bite the bullet on the normal CR123's. Wasn't able to find the how-to you mentioned btw or at least not any info on changing the lock state. If you have a link to any documentation would appreciate it, but no rush.

If I can't find it today/tomorrow I'll close this issue and figure something out. thanks again for helping out!

[rospogrigio]

Mmm, I actually had contacted the seller for a suggestion on which recheargable batteries I could use, and they said 16340 should be used. I bought some of these, and I started using them last month (when my Duracell batteries depleted). So far, they seem pretty good, the voltage is higher (the sensor is measuring 10.95V, instead of 9.3V I was measuring with the Duracell), and it seems to be working pretty fine, the motor looks stronger. Connection stability seems good as well. I don't know if you've been unlucky or I have been lucky, or if they may fail any time soon, I'll give you some more feedback in the future. Hope this helps, bye

[formatBCE]

@rospogrigio could you advise on lock direction please? I forgot, where to set this up, but clearly remember, that we were speaking about it and you added support. @TheDescender has this problem.

[rospogrigio]

Well, the direction should be already handled correctly, since its setting is contained in the data coming from the characteristics. If some devices are not following the rule correctly, we might consider adding an option to force to reverse it. Let me know...

[TheDescender]

@rospogrigio Thats interesting, guess my 16340 must've just been poor quality, since I get state reports of 7V and they don't hold a charge well at all. What Brand 16340's did you end up buying in case it was brandname?

In regards to the Lock direction. I'm using an M531. I assume it's some issue in the WeHere app and data being pushed from the lock itself. My lock opens by turning counterclockwise (left), but in the WeHere app changing the "Open Direction" in the app only changes the slide command, but the naming convention on the lock screen stays the same, so you end up opening by swiping to the word "lock" and vice versa.

I wanted to test what happens in HA when I invert the turning direction in WeHere, since that seemed to mess up unlatching. But then my lock cylinder decided to break, so i'm not having a good day xD.

I'll post here when I diagnose where the issues lies. at the very least currently I do know that the STATUS sensor in HA is displaying an inverted status, locked when open and open when locked.