Secure 5-button keyfob with enclosure (was: 8-button keyfob)

[elcaron]

@Anticimex Ok, I see my misunderstanding. But that would mean that a lost node (to obtain the ATSHA) and an accessible node (to extract a whitelisted ID but then left in place) combined would give access, wouldn't it?

[Anticimex]

@elcaron yes, until you remove that nodes entry in the whitelist on the receiving side

[elcaron]

@Anticimex The idea is to let one accessible node alone. Just get the id out and leave it where it is. So there would be no reason to take that node's id off the whitelist.

[Anticimex]

@elcaron I don't understand. Why would the attacker leave your node alone?

[elcaron]

This post is deleted!

[elcaron]

@Anticimex Oh, forget what I said. I thought that the whitelisting was on network access basis. But the doorlock has to trust the id via whitelisting, and of course it wouldn't trust a patio motion sensor.

[Anticimex]

@elcaron then we are on the same page :)

[Anticimex]

@elcaron whitelisting is on a per-node basis.

[elcaron]

So apparently it it will be a while until I can do active testing. Right now I am struggling to get my network running at all.

I'll quickly post it here in case someone has an idea, else I'll open a thread next week when I actually have time to react to suggestions.

I have flashed the GatewayESP8266MQTT sketch to my gateway (Wemos D1 Mini + RFM69HCW). This is the output:

0;255;3;0;9;TSF:LRT:OK
0;255;3;0;9;TSM:INIT
0;255;3;0;9;TSF:WUR:MS=0
0;255;3;0;9;TSM:INIT:TSP OK
0;255;3;0;9;TSM:INIT:GW MODE
0;255;3;0;9;TSM:READY:ID=0,PAR=0,DIS=0
0;255;3;0;9;MCO:REG:NOT NEEDED
scandone
f 0, scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 3
cnt 

connected with MySSID, channel 1
dhcp client start...
...ip:192.168.2.127,mask:255.255.255.0,gw:192.168.2.1
.IP: 192.168.2.127
0;255;3;0;9;MCO:BGN:STP
0;255;3;0;9;MCO:BGN:INIT OK,TSP=1
IP: 192.168.2.127
0;255;3;0;9;Attempting MQTT connection...
0;255;3;0;9;MQTT connected
0;255;3;0;9;Sending message on topic: home-le/mysensors/868/in/0/255/0/0/18
pm open,type:2 0

The message is successfully published on the MQTT server.

I flashed the LightSensor sketch on another breadboard node (Arduino Pro Mini + RFM69HCW). This outputs

0 MCO:BGN:INIT NODE,CP=RRNNA--,VER=2.1.1
4 TSM:INIT
4 TSF:WUR:MS=0
8 TSM:INIT:TSP OK
10 TSM:FPAR
141 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
2148 !TSM:FPAR:NO REPLY
2150 TSM:FPAR
2281 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
4290 !TSM:FPAR:NO REPLY
4292 TSM:FPAR
4423 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
6432 !TSM:FPAR:NO REPLY
6434 TSM:FPAR
6565 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
8574 !TSM:FPAR:FAIL
8577 TSM:FAIL:CNT=1
8579 TSM:FAIL:PDT

Which apparently indicated that no parent could be found. The gateway doesn't output anything.

I did not make any changes to the gateway sketch except for password and name stuff (especially no inclusion mode). Devices are a meter apart, one with a spring antenna, the other with a big screw-on antenna.

[elcaron]

@MiKa Version with pullup is pushed to Github

[MiKa]

@elcaron Perfect, THX! :+1:

[elcaron]

@MiKa If you happen to have time, could you test the range with

1. a stable 2.7V supply and
2. a 1mF cap in parallel to the battery?

I am really not happy with the HT7333 solution, since the shelf life of the keyfob will be limited and the quite expensive LIR2032 can easily be damaged by undervoltage.
If the second test works, I could fit 4 220uF 6.3V tantalums next to the LED.
Else I would give the step-up thing another go. There are low profile inductors, but I didn't find any for cheap (shipping) at Aliexpress.