General questions & inquiries

[rednblkx]

You can leave your questions and inquiries here.

[011V32]

The POC requirements state that only UART (and not SPI or I2C) is supported.
However, only SPI is listed as compatible in your project. Why is that?
thx

[rednblkx]

That's because kormax's repo and mine have two different codebases. The Homekey functionality was written based on their work but was otherwise written from scratch in C++ to run on the ESP32.

Reason why kormax's POC requires UART is because the project is using the Python library nfcpy which afaik only accepts USB or UART while this repo uses a slightly modified version of the Arduino library PN532 from Seeed-Studio and for reasons i chose to go with SPI.

[jenslam]

I just found this solution today and got this to work - at least somehow.

Auth is published successfully with RFID or HomeKey data on my MQTT.
Changes through the home app are also visible in the terminal log of the ESP, but only the NewLockState is changed (lock = 1 and unlocked = 0) - the Current LockState does not change.

(1788818) LockMechanism: update > New LockState=0, Current LockState=0
(1793951) LockMechanism: update > New LockState=1, Current LockState=0

When the homekey is presented the state is always switched to 1 on MQTT.
In the HomeApp the state is not updated.

Any ideas what's going on there?

[thorsten-gehrig]

According to my understanding the process is like that:
the HomeKey says "key found/authorized" and send this via MQTT to your Home-automation.
You can then e.g. open the motor lock (on your Homeautomatio) and send
MQTT homekey/set_target_state => 0 which does result in "opening"
then
MQTT homekey/set_current_state => 0 which does result in "open"

When you close the lock it´s the other direction
MQTT homekey/set_target_state => 1 which does result in "locking"
and when completed
MQTT homekey/set_current_state => 1 which does result in "locking"

You can skip "opening" and "locking" - just using "set_state" set to 1 (locked) or 0 (unlocked)
This might be reasonable if you have a falling latch ("Schlossfalle") with electric-door-release/electric strike (https://youtu.be/UFGQP2n7DCg) - just put "set_state" to 0 for the 3-5 seconds while the electric strike does allow the door to opened - then switch back to "1".
Keep in mind that the HK Lock ist build for an motorised lock - which usually takes time to open or close - and then stays locked or unlocked.

Does that make sense & help?

Best
Thorsten

[jenslam]

it took me 3 or 4 times to read it and try it, but i guess I got it - thanks!
I'll let you know once it's really working in productive usage :-)

[electric-m]

Works good for me. I am extracting either the issuerId or the uid from the MQTT payload and check them against my authorized tags in NodeRed before actuating my motorized lock.

[011V32]

Would it be possible to also implement a UART connection to the PN532?
M5Stack has an ESP32 Ethernet Unit with PoE that has only a UART connection...
(A small PoE module would help hide the reader in flush-mounted boxes.)

[rednblkx]

Well, the PN532 library does have UART implemented but it lacks the Software variant as i had to remove it to due to some strange compiling errors i was having and that would be needed for this particular board as it only has one UART connection which would be used by HomeSpan. I'll think about it, maybe will be part of the next release. Hopefully Ethernet is added to HomeSpan by then as that will be absolutely required for this board since it doesn't have wifi.

[pilot1981]

If I integrate it in HomeKit, then I can use HomeKit automation to control NUKI lock already joined to HomeKit?