Wireless remote door lock - HW choices

[idanronen]

Hi, i'm new to mysensors and most of my experience is with esp8266 in wired setups, so please bare with me.
I want to make DIY wireless door locks for my interior doors which can be operated remotely (just a motor ,arduino controller, and an endstop, to turn the key to set positions). An always on 433mhz RF receiver is not an option as they consume way too much current (~4ma). I did a test with nrf24 and saw that i can reliably get the signal in my wireless unit even with 10ms of receiving time out of every second, and with a wired gateway simply repeating the signal for about a second. The problem is that now i'm kinda lost in the sea of possible HW combinations.

I know these things rarely have a straightforward answer, but what would be "best" in terms of power consumption ?:
Controller: Arduino pro mini, STM8 based board, or STM32 based board (recommendations are welcome)?
Receiver: NRF24 /+, RFM69, something else?
Power: lithium-ion used directly, lithium-ion used with a buck converter to 3.3V / 3V, 2 AA batteries used directly, 2 AA batteries used with a boost to 3.3V, 3 AA batteries with a buck converter ? something else?

Thanks in advance!

side note: is mysensors suitable for this purpose in terms of power consumption, or should i just use my own 10ms receive, 1 second sleep code?

[nagelc]

MySensors smartsleep would be a good way to implement your receive/sleep code. It handles any waiting messages when the node wakes up and before it goes to sleep. Look it up in the API page.

Some thoughts on your other questions. Others may have better answers than me:

Your simplest node would be a 3v3 pro-mini running on 2AA batteries. Check out the low power node discussions on the MySensors web site. This would be the most straight forward if your motor supports it. A 5V pro mini with an NRF24 is also a straight forward option if you have more than 5v available (but consumes more power). The trade off on power source and complexity is a real one, and depends a lot on what you are trying to do. There are lots of discussions in the forums about how to handle mixed 3v3 and 5v components and lithium vs alkaline batteries -- a very common problem.

RFM69 will normally give you better range than NRF24, also at very low power. But they cost a little bit more and are not 5V tolerant. The NRF24 is easier to make work with a 5V pro-mini or nano since only the power needs to be dropped to 3.3v. Again, lots of discussion can be found in the forums. You need a gateway with a compatible radio, so there is a bit of commitment in your radio choice.

[idanronen]

@nagelc From what i've read on the forums, it seems pretty clear that if a pro mini was my choice i should go for the 3.3v variant, as the power draw is lower, its just that i then came up on the STM8/32 options and got thrown off. since i can enable the boost converter to 5V for the motor just when i need the motor, i think that offsets the benefits of using just 1 regulator to 5V for both the pro mini (5v variant) and the motor.
What im trying to do is mainly get it to work with the lowest possible current draw and most efficient power source so i dont have to replace/charge it every month. for example lithium is more energy dense than alkaline, but if the power conversion takes a lot more that kinda negates the benefits.

[skywatch]

I am quite worried about this. You will need a very stable gateway/controller to do this in the first place. Unless there are local overrides for the locks on each door (both sides).

What concerns me is if there is a power outage, how will you open the doors?
If the power is taken out by something catching fire, how will people exit?
Don't forget security either. Message signing is the minimum requirement for this type of setup.

[idanronen]

@skywatch Those are very good points, but i think i can address them quite well:

1. Locking someone in - these interior doors have a standard universal locking mechanism (zero/flat key) which wont allow a key being inserted from both sides simultaneously, so i cant allow a manual override from the inside. I was thinking i may be able to custom make a double length key with a handle on just one side, insert it all the way to the other side, and then epoxy a handle on the side without the handle after it is in. In any case, the lock "shouldnt" engage when someone is inside anyway, since i plan to only enable locking through an actionable alert to my phone from HomeAssistant which is sent for manual approval only when the house door is opened, and no device tracker has entered the house in the last 5 minutes (i.e. the door is opened because someone is leaving and not entering)
2. Locking someone out - in case the door is locked and the mechanism fails, i plan to have a manual handle on the outside to turn the key from outside the mechanism, im just worried about reverse voltage from the motor being manually turned, but i have no solution for this. worst case the board is fried from this and i just rip off the mechanism which will be glued with double-sided tape
3. Hacking - Like i said, it will be operated from home assistant, and I'm not worried about that being hacked. The device can be hacked directly by someone sending random messages with a compatible NRF24 or other device somewhere nearby. I'm not really sure how to handle that one, as this sort of communication is broadcast and a verified message would have to change content every time to be secure, sort of like a rolling code.

[nagelc]

@idanronen said in Wireless remote door lock - HW choices:

Hacking - Like i said, it will be operated from home assistant, and I'm not worried about that being hacked. The device can be hacked directly by someone sending random messages with a compatible NRF24 or other device somewhere nearby. I'm not really sure how to handle that one, as this sort of communication is broadcast and a verified message would have to change content every time to be secure, sort of like a rolling code.

So . .. . above, I said that ProMini with batteries was the simplest, but you may want to move to a 32 bit controller for this one.
MySensors provides a security framework to address the hacking aspect above. Using signing on a complicated node, I started running out of memory on the ProMini. I have moved to the NRF5 series, mostly to get more memory. There is a lot of additional features and power also, but it is a harder learning curve to get the tool chain working.

[monte]

@idanronen some time ago I've built myself a "smart lock" using mysensors node with a servo. I was also worried about hacking potential so I just encrypted the message sent via mysensors network with AES cypher. I was happy to find out that it's pretty easy and doesn't require anything special. You can find my code here: https://forum.mysensors.org/topic/9204/secure-node-encrypted-communication-aes-128 maybe it will help you somehow with your project.

[idanronen]

@nagelc i just read the post here about implementing mysensors on NRF5, and it seems out of my comfort zone, at least for now. The chips are 5-10 times the prices of stm32 and the whole process seems complicated and support is limited.
Would stm32 fit the bill for this sort of use-case? how should i go about security?

@monte said in Wireless remote door lock - HW choices:

@idanronen some time ago I've built myself a "smart lock" using mysensors node with a servo. I was also worried about hacking potential so I just encrypted the message sent via mysensors network with AES cypher. I was happy to find out that it's pretty easy and doesn't require anything special. You can find my code here: https://forum.mysensors.org/topic/9204/secure-node-encrypted-communication-aes-128 maybe it will help you somehow with your project.

It sounds interesting, and i would definitely want to hear more about your project if you can share some info. However, I'm not sure how encryption would help me in this case. Encryption is good for hiding what is being sent, but in this case an attacker could just record and repeat the traffic on the network without knowing the code and it would still open/close the lock, unless i missed something

[Anticimex]

@idanronen you need signing to ensure the authentencitity of the messages. Encryption only adds obfuscation.

[monte]

@idanronen said in Wireless remote door lock - HW choices:

attacker could just record and repeat the traffic on the network without knowing the code

That exactly what I was afraid of. I will quote myself here: "When 4 bits are collected it adds 6 random bits before it and 6 random bits after, so the string is 16 bit long. Then it encrypts it as a single AES block and then encodes in base64, which makes 24 bit long message to be sent to a gateway like this 1;1;1;0;47;uKvGG7z440r/1pln4IJbNQ=="
So basically, you end up with different message every time you send it, though the access code is every time the same. And receiver node decodes the message and looks only at the part that is meant to be the code itself, ignoring random salt around it.

@idanronen said in Wireless remote door lock - HW choices:

The chips are 5-10 times the prices of stm32 and the whole process seems complicated and support is limited

You can buy nrf52840 modules from EBYTE for around 3.5$ on ongoing sale, nrf52832 are sold for about 4-5$ even without sale. They require your own pcb, to make it all clean and neat, but result is more compact and power efficient. As for support, you don't need to worry about it, everything that should work works, and with Arduino releasing it's new Nano BLE board based on nrf52840, we can expect support to become even wider.

[idanronen]

@monte
Thats exactly the section i was referring to. I understand the importance of randomizing the start and end of the transmission, i've used that principal before in adding salt/pepper to encryption, what i dont understand is how this helps in this instance. Yes, you've created a unique message every time, but does your receiver store all the messages and checks to see this message hasn't been received in the past? otherwise what stops an attacker from recording the "1;1;1;0;47;uKvGG7z440r/1pln4IJbNQ==" you've sent, and then repeating it? the receiver will still decrypt it as a viable code.

The nrf52840 look really nice, but might be a bit challenging for my soldering skills. If all i want is a low power wireless lock, i can call it a day with just either of these units (1, 2) for both processing and transmission, 2 AA batteries without a regulator, and the motor?

[monte]

@idanronen yes, good point, but as @Anticimex mentioned, signing has to solve this issue.